Create the supplyThe framework tools are built onWhere apps are built

Frame

The substrate the supply is built on.

StatusBuild
FIG · Apps stand on one shared datum plane, aligned by construction.

Frame is the DAAC-native application framework: the substrate that apps run on. It shares most of its DNA with DAF, the framework a decade of live deployments runs on; what sets it apart is that it is configuration-driven, so an app is declared rather than hand-coded and a spec change is a low-cost realignment rather than a rebuild. It extends DAF for the DAAC era, it does not replace it.

What makes Frame load-bearing for DAAC is that compatibility is not a feature you add. Every app built on Frame implements the shared conventions (identity, schema, provenance, sharing rules) from the inside. The data it captures is exchangeable across the ecosystem from the moment it exists, with no later integration step.

Apps are built on Frame by humans writing configuration directly, or by agents in Forge. Frame is the substrate; it does not build apps itself.

Where it sits. Stands on the shared conventions at within-app scope. Forge treats it as its DAAC-native reference substrate; the data Frame apps capture is the supply.

01What it does
01
Configuration-driven
Apps are declared, not hand-coded, so a spec change is a configuration change, not a rebuild.
02
Tradable by construction
The shared conventions are implemented from within, so captured data is a tradable asset the instant it is recorded.
03
Sovereign by default
Custody, permissions, and channels are part of the substrate, so data stays under its owner’s control at the point of capture.
02How it works
FIG · How an app is built on Frame, declared, not hand-coded
  1. 01Declare
    Configuration

    An app is a set of config fills, navigation, roles, subjects, views, that never escape into bespoke code.

  2. 02Inherit
    Shared conventions

    Identity, the schema envelope, lineage and sharing settings come from the substrate, implemented from within.

  3. 03Operate
    Store · Query · Channels

    The three modules run sharing within the app; multi-stakeholder flows are first-class, no Spine required.

  4. 04Compatible
    By construction

    Every captured subject is Spine-compatible the moment it’s recorded, exchangeable with no later integration step.

03How it connects
FIG · The substrate everything else stands on, Forge builds on it, Spine extends its modules, Scribe writes into its shape
Feeds inHands onConsoleobservesbuilds onwrite configForgetoolDevelopersexternalrun onextends modules →appscapture the fieldSpinetoolFrameThe framework tools are built onWhere apps are builtStands onShared conventions, identity · schema envelope · lineage · sharing settings
Frame, the subject hereCopper edges, what it hands on to the marketDashed leads, tooling that watches, never steers
04What it’s for
FIG · What you can build on it
FrameMulti-stakeholder appsrun on FrameData tradable at captureSpine-compatible by constructionLow cost-to-realignthe target metricIntelligencethe demand-side payoffpriced access →· Risk management· Impact measurement· Due diligence· Opportunity assessment
05What it reports
Indicative telemetry
No app on it yet, here’s what it will report once one ships
Born wired · awaiting first run
Cost-to-realignindicative

the defining Frame KPI, measured in the DAF-vs-Frame bake-off

Apps on Frameindicative

and apps behind Frame, a first-class, reported drift signal

Component coverageindicative

the library grows build-pull, not speculatively

Convention coverageindicative

identity · schema · lineage · sharing, implemented from within

Frame’s headline is cost-to-realign after a spec change, not delivery speed. Counts are spec-surface, not runtime. Reports through Console once its first app ships.

06Where it does the work
Follow the thread
ForgeThe agentic build environmentCrawlCrawls the public webScribeRenders any source into schema-conforming recordsSpineThe cross-system protocol
← The whole suiteContact Us →