Code → Graph → Commits

Git gives us shared text. What shares the system?

Git gives collaborators canonical file history and a commit head. That agreement stops at the text. Beyond it, an ORM describes runtime objects, an API describes transport, a client describes its view, SQL describes queryable state, and documentation describes intent.

Each copy can be locally correct while the system drifts globally. Humans review the differences. Agents infer the missing conventions. Both spend time synchronizing representations instead of evolving one explicit world.

The Object Config Graph is Aware's answer: a canonical contract for what can exist, how it relates, how it is identified, and which operations are valid.

Author meaning once

Aware starts with semantic source in .aware. Home is a small example, but the point scales: identity, relationships, state, and valid operations are authored directly instead of recovered from downstream code.

class Home {
    doors Door[]
    tvs Tv[]
    name String = "My Home"

    fn add_door (
        label String,
        is_locked Bool = true,
        is_open Bool = false,
    ) -> Door {
        let created = construct doors.create(
            label = label,
            is_locked = is_locked,
            is_open = is_open,
        )
    }
}

This source says more than “generate a class.” It says that Home exists, has state and relationships, and owns a valid way to add a Door. That semantic contract is what downstream surfaces must preserve.

One lifecycle, three graph views

Configuration, Projection, and Instance are not competing graph products. They keep one system continuous from contract, through a declared lens, into live state. The useful idea is the lifecycle, not the acronyms.

The foundation arrow

Meta is Aware's graph-commit protocol. It interprets semantic source as typed graph operations, validates them against current state, and records accepted evolution as durable commit lineage.

The commit answers more than “which lines changed?” It can preserve the prior head, graph and projection identity, FunctionCall, operation provenance, resulting head, and exact failure evidence when a move is rejected.

Because history is replayable, consumers do not have to trust an unexplained latest snapshot. Humans and agents can inspect which system meaning moved and reconstruct how it got there.

The same truth defines capabilities

Ontology is not an island. API capabilities bind typed request boundaries to functions on the same semantic world.

api home_devices {
    capability lock_door {
        endpoint lock_door aware_home_api.door.LockDoor {}
    }

    graph aware_home {
        capability lock_door {
            function lock aware_home.home.Door.lock
        }
    }
}

DTOs carry the service contract. Runtime models own mutation. An agent, CLI, service, and interface can call the same named capability without inventing separate Door semantics—and the call can retain causality into the graph commit and receipt.

Committed truth becomes materialized software

A graph contract still needs software surfaces. Providers derive API clients, DTOs, SDKs, runtime models, handlers, service protocols, storage projections, interface packages, manifests, and artifacts.

Those outputs have different operational jobs. They do not become independent authorities. Python, Dart, SQL, APIs, SDKs, services, and interfaces are reproducible materializations of committed meaning.

Workspace makes it a product

Workspace owns the acceptance lifecycle around materialization. It selects an owned package, plans the semantic change, executes the provider, applies returned deltas, verifies artifacts and tests, records receipts, and—on the persistent rail—seals accepted truth into a WorkspaceRevision.

A Workspace revision is not merely a build number or Git SHA. It pins accepted package and artifact truth after the canonical lifecycle has run. That makes it the useful coordinate for clean continuation, dependency selection, publication, installation, deployment, and collaboration.

Claims travel with proof

Aware's Product-to-Proof catalogues connect product promises to executable evidence. The current active catalogues support the foundation: semantic source, typed operations, FunctionCall commits, replay, fail-closed mutation, one-model-many-surfaces, deterministic materialization, API/SDK consumption, provenance receipts, and foundational Workspace package materialization and currentness.

This distinction matters now that the Kernel and Network are open source. Because the Kernel and Network source is available, the mechanism itself can be inspected. Proof says which product claims it currently supports. The first stable public Workspace revision will join exact source, materializations, and evidence under one accepted coordinate.

From revision to entrance

An accepted revision becomes useful when a person or agent can enter it through an exact public boundary. aware-app is the intended human Interface and Experience door. aware-dev is the intended operator and external agent door.

The official aware-app has already crossed candidate-scoped, revision-pinned publication and bounded installation proofs. That is real evidence—not a claim that stable public activation and the complete shared DevSession are finished.

Runtime is the second loop

The foundation arrow builds and accepts the software world. Runtime evolves the live world.

Shared attention is the king outcome: humans and AI looking at the same thing, acting on the same thing, and understanding what happened next. It comes last in the arrow because it depends on something trustworthy to share.