Core Concepts — Vocabulary as Mechanisms (Developer Concept Doc)

Status: 2026-11-09. Audience: engineers who must use the platform without re-deriving its vocabulary. Contract: each concept below is a mechanism stated as PROBLEM → MECHANISM → INTERFACES → INVARIANTS. No schema, field, or storage detail is listed; the goal is to make correct use unavoidable and incorrect use obviously wrong. (Source: operational memory core subsystem, truth graph, proof, and scope governance sections.)

1. CNS naming — one grammar for every typed thing

PROBLEM — names diverge by domain. Without one grammar, a construction type, a proof type, and an interface path cannot be compared, inherited, or routed consistently, and every new domain invents a parallel naming scheme. One name system exists so that lineage, routing, and proof share a single addressable vocabulary. (Source: naming directory design.)

MECHANISM — a single canonical name system gives every claim type, interface, and canonical entry one path grammar with inheritance. A canonical path uses a mandatory scheme followed by slash-separated segments, with a depth floor of two segments and a ceiling of sixteen segments; an empty body and a wrong scheme are rejected distinctly. Ancestors are resolved nearest-first, and traits plus capability references are inherited from ancestor paths, so a child type gains the governance and tracking properties of its parent without restatement. Interfaces carry a versioned category of the form path-at-version, where the major version is the part before the first dot, and resolve to a single interface definition. (Source: naming directory path and version rules.)

INTERFACES — parse, resolve, declaratively register. Callers parse a path into segments, resolve an interface by category, resolve ancestry and inherited traits, and register new interfaces, types, and entries through idempotent create-or-update operations. A construction family illustrates inheritance in canonical form: the parent at cns://claim/type/kujenga carries construction, governed, payments-enabled, and tracked traits, while children specialise into budgeting, escrow linkage, inspectability, sequential funding, assignability, time-boundedness, pass-fail certification, and disputability. A validation callback caches compiled schemas and maps canonical paths to event subjects at runtime. (Source: naming directory and declarative update design.)

INVARIANTS — never invent a name outside the grammar. To type a new entity, register a canonical type with traits and capability references and address it by that path. A typed graph relationship requires a canonical name with at least two path segments. Names are never free strings. (Source: operational memory naming rule.)

2. Claim — the system-of-record primitive

PROBLEM — durable facts need a single representation that survives lifecycle, proof, and federation. Facts, assets, contracts, orders, and incidents otherwise live in incompatible ledgers, and lineage versus payload versus proof become indistinguishable. (Source: claim primitive mandate.)

MECHANISM — the claim is the fundamental primitive: a typed durable fact with fenced payload channels and explicit linkage to the truth fabric. Typed payload lives only in the data channel; lifecycle state lives only in the state channel; cryptographic evidence lives only in the proof channel; miscellaneous annotations never substitute for typed payload. An explicit pointer names the thing being claimed about. Voyage is carried by a trace plus hop counters, a workflow reference, and a previous-claim chain, while cross-hop correlation lives in the delivery anchor's causation envelope rather than in ad-hoc claim attributes. Cross-scope references use pointer or hybrid mode with a declared resolution protocol — proxied traversal, direct query, or predicate check — and a required lease purpose, never by duplicating the remote payload. (Source: claim core and unified-claims design; delivery anchor causation rule.)

INTERFACES — create, serialise with lineage, synchronise, prove. Producers create claims by choosing a canonical claim type, serialise a claim together with its graph edges and attestations as one reference reader, keep the semantic index synchronised, and mint proof receipts as claims of a dedicated governance type. The claim type itself is the discriminator: callers and contracts must supply a canonical claim-type path, never a free-form label. (Source: unified claims reader; proof mint design.)

INVARIANTS — put the right content in the right channel and always dual-map. Typed payload never goes in annotations; state never carries proof; cross-scope pointers never copy remote payload. Every claim-eligible entity is both a claim row and a graph link, and the two typings must agree. (Source: operational memory claim-first and dual-map mandates.)

3. Truth fabric — directed graph traversed under gates

PROBLEM — provenance must be navigable, not merely stored. Lineage, hierarchy, and attestation need a traversable structure with strength, evaluation, expiry, and health semantics, so consumers can ask what connects to what under what authority. (Source: truth fabric design.)

MECHANISM — the fabric is a directed graph: a node is a named, typed entity with provenance metadata and optional geo position, and an edge is a typed, steered relationship from one node to another carrying strength, evaluation mode, conditions, expiry, and health. Evaluation modes distinguish static facts, formula-driven strengths, state-machine-driven activation, and bond-backed activation. Tokens attest edges and claims. A reactive layer maps edge and node type pairs to a small action vocabulary — start a state machine, emit an event, run a function, transition an edge — and graph mutations are fenced by a durable-reactivity rule: structural events write only a delivery anchor; the forwarder and index synchroniser make the change visible afterwards. Traversal walks from a start reference in an explicit direction — outgoing, incoming, or both — up to a bounded depth with a strength floor and an explicit relation filter; an empty filter matches nothing. A vault guard overlays traversal: the caller must hold the start node's scope or an active lease, leases are pre-resolved direct plus chained up to three levels with depth capped, and every scope crossing is annotated on the path with the source, target, and a summary count. Geo position is set by direct update outside transactional functions, and geo search uses lat-long plus a haversine calculation rather than geometry-function distance. (Source: truth core, reactive edge, graph events, traversal guard, and geo rules.)

INTERFACES — node and edge lifecycle, traversal, search, index, vault checks. Callers create, update, and retire nodes; create edges with ten explicit steering arguments including canonical name and health; traverse with direction and filters; search semantically; index nodes and claims; and check scope access and grant leases. DDE-style routes expose traversal and index operations to HTTP clients while the edge service proxies onward. (Source: truth graph functions and BFF routes.)

INVARIANTS — gates precede traversal, anchors precede visibility. Never set geo tuples inside transactional functions. Never dispatch effects from structural event bodies. Never traverse past an unleased scope boundary, and never treat an empty relation filter as "match all". (Source: operational memory traversal and reactivity constraints.)

4. Scope governance — delegation chain as permission model in words

PROBLEM — scoped authority must be explainable as a chain, not as scattered checks. Presentation code that hand-rolls scope tests cannot prove who delegated to whom, how deep the chain runs, or whether a revoked link still matters. (Source: scope governance specification.)

MECHANISM — authority is a formal delegation chain: a root scope owns a maximum delegation depth, a join policy, and a recovery quorum; each delegation is an immutable, hash-linked grant from issuer to subject for a scope and a set of claim types, with its own depth, parent hash, validity window, signature, and lifecycle state. Hierarchy adds a directed acyclic relation of containment, management, or observation between scopes. A claim-type registry states which types are valid in which scopes and whether they require a public anchor or trusted-execution attestation. Companion concepts cover membership, root-transfer requests, and approvals. Verification walks the chain with a bounded ten-hop unroll to establish root authorisation and hierarchy authorisation; sweep operations reap orphans and expired delegations. Fifteen invariants guard monotonicity, cycles, root binding, membership, join policy, orphanhood, transfer quorum, temporality, scope consistency, stale signatures, expiry, depth overflow, duplicate hashes, and sealing. (Source: scope governance authority program and invariants.)

INTERFACES — verify, delegate, join, transfer, sweep. Callers verify a chain, check hierarchy authorisation, delegate within depth, cascade-revoke a subtree, join a scope under its join policy, register quorum members, request and approve root transfers, and sweep orphans or expired delegations. Visibility and sealing helpers answer whether a type or operation is sealed and what a caller may see. (Source: scope governance operations.)

INVARIANTS — verify through the chain, never around it. Authority is established only by chain verification; presentation code never hand-rolls scope checks. Depth is capped at ten on both the scope and the delegation. Delegations are immutable except for lifecycle state. (Source: scope governance developer rule.)

5. Proof of correct execution (PoCE) — a verification machine

PROBLEM — governed execution needs evidence that deserves trust. A transition log proves something happened, not that the authorised path, stage order, and result binding were honoured. PoCE is that verification machine. (Source: proof definition.)

MECHANISM — proof is a hash-chained, append-only receipt trail proving a governed request followed an authorised path: evidence of correct execution along a declared route, not proof of work. The machine has four parts. A path specification is a versioned declaration of required stages plus optional rules, stage authority bindings, transitions, schemas, deadlines, and event triggers, scoped to a catalogue identifier or wildcard. A session is one execution per governed request, tracking its specification and version, scope, status, step count, chain head starting from genesis, root hash, result claim and result hash, and context. A step receipt is one append-only row per stage, hash-linked to its predecessor with per-step input and output hashes and the rules applied. A final receipt binds the root hash to the result claim and result hash at finalisation: each step hash is the hash of session, index, stage, specification version, predecessor, inputs, outputs, and rules; the root binds specification, version, chain head, result claim, and result hash. Enforcement requires specified events, checks that a session satisfies them, lists required events, revokes stale requirements, and sweeps orphaned sessions. (Source: proof-of-correct-execution design and hash formulas.)

INTERFACES — register, start, append, verify, finalise, export. Callers register and fetch path specifications, start sessions, append stage steps, fetch traces, verify sessions, and finalise into receipts. Finalisation creates a pending governance receipt claim, registers it as tokenisable, enqueues tokenisation plus a delivery anchor on the tokenise subject, and returns pending; minting proceeds asynchronously over the event fabric and the claim moves to attested only after the mint completes. Signed envelope material can be fetched and linked, and graph paths can be bound to sessions. (Source: proof operations and async mint sequence.)

INVARIANTS — append-only, version-pinned, asynchronous. Steps cannot be mutated or reordered; finalisation binds the root to exactly one result. The specification version at execution time is part of every hash. Minting is event-driven, never polled. (Source: proof definition and finalisation design.)

6. Dual-map contract — claim plus graph as one fact

PROBLEM — a claim without graph linkage is isolated; a graph without a claim record is unaccountable. Lineage and record must be the same fact viewed two ways. (Source: dual-map mandate.)

MECHANISM — every claim-eligible entity is both a claim record typed by a canonical claim-type path and a graph participant linked by a typed edge, where the entity itself is a graph node. Claim typing and graph typing carry the canonical name and must agree. The reference reader returns the claim together with its incident edges, its attestations, and its index state as one object. Propagation is fenced in both directions: structural events write only delivery anchors, and index synchronisation follows as a consequence. Federation metadata — whether a record is federated, its federation scope, mode, and policy — exists equally on claims, nodes, and edges so federation decisions are uniform across the dual representation. (Source: dual-map contract; unified claims reader; federation extension.)

INTERFACES — write both, read the reader, prove the session. Producers create the claim and the node and edge as one act; readers traverse and search through the graph; provers verify and finalise proof sessions. (Source: dual-map write and read paths.)

INVARIANTS — typing agreement is mandatory. Never create a claim without its graph link and never expose a graph object whose typing disagrees with its claim typing. (Source: operational memory key decisions.)

7. Entity lifelong plane plus quorum — linkage and threshold in words

PROBLEM — entities live longer than any single operation, and high-stakes actions need more than one actor. Lifecycle without a bridge to proof loses early events; single-actor approval cannot express recovery or transfer thresholds. The lifelong plane is the entity-to-claim linkage as a join model: it joins the enduring entity to its claim history through the reference pointer. (Source: lifelong and quorum designs.)

MECHANISM — the lifelong plane links an entity to its claim and to its history, and bridges governed lifecycle events into proof sessions; quorum expresses threshold agreement in words. A lifecycle event names an entity type, entity identifier, event type, actor, prior and next states, scope, optional governed-execution flags with a path specification reference, and the resulting proof session reference. It is deprecated as a standalone store: new lifecycle signals go directly to the delivery anchor for event consumption, while the entity reference pointer remains the lifelong identity with an index for range and paging lookups by entity and time. The bridge auto-starts a proof session when a governed flag and specification are present, recording the session reference back on the event; triggers include agent dispatch, emergency solicitation, affiliation approval, and standing-order firing. Minting helpers go through the delivery anchor rather than direct creation. Quorum is a named threshold group with a default threshold of two signers, a signer array, an open status, and an expiry, with one signature record per signer, small list and lookup operations, and no separate storage beyond the companion design. (Source: lifelong events and indexes; quorum plane; proof bridge triggers.)

INTERFACES — lifecycle proof endpoints and entity history. Clients use lifecycle proof start, step, and finalise operations, dispatch-step operations, lifecycle event reads, and standing-order triggering. Entity history reads resolve through the entity reference pointer and its paging indexes. (Source: lifecycle bridge routes.)

INVARIANTS — no new tables for lifelong history, no silent single-actor escalation. Lifelong history reuses the pointer plus indexes rather than introducing new structures; governed lifecycle signals publish to the anchor rather than persisting as a private stream. Quorum thresholds are declarative and versioned; exceeding a threshold is established by collected signatures, never by a solo flag. (Source: lifelong no-new-tables rule; quorum threshold semantics.)

Cross-cutting invariants

Zero-bespoke structures are forbidden: every domain entity maps to the canonical claim, graph nodes and edges, resource catalog, or universal integration ledger, and an unmappable entity stops the design. Claim-first thinking applies: choose a canonical type and traits plus a graph link. Lookups, thresholds, scenarios, and templates are declarative in key-value planes and engine routes, never hardcoded in transactional logic. Infrastructure failures close with typed errors; synthetic success objects, invented coordinates, suppliers, and organisation identifiers are forbidden and surface as client errors. Background work is event-driven through anchors; sweep endpoints are recovery only. Orchestration lives in the workflow and protocol engines backed by declarative configuration, not in the durable store alone. (Source: operational memory mandates on zero-bespoke, declarative-first, fail-closed, no synthetic payloads, events-not-polling, and no durable-store state machines.)

Explicit unknowns preserved: precedence between canonical-name resolution and the directory service is not stated in sources read; quorum signing beyond threshold-group shape is not specified; the full lifelong HTTP inventory beyond lifecycle and paging reads is not enumerated; and token-mint grant policy beyond the cited mint call is not specified. (Source: prior concept inventory unknowns.)

Interface summary