Everything in CFS is built from 8 building blocks. Simple enough to understand, powerful enough to build anything. This page explains each primitive in depth.
The atom of context
A Record is a stable identifier for any entity in the context plane. Records are the nodes in your context graph - the things that exist and persist.
Without stable identifiers, you can't have reliable references. Records give everything in your context plane an address that doesn't break when names change or systems migrate.
record_id — Globally unique, stable identifierlabels — Type classification (person, service, doc)props — Key-value attributes (name, status, metadata)created_at — System time of creationtenant_id — Isolation boundaryperson:ryan-hunter-7f3a A human identity with preferences, history, context
service:api-gateway-prod A running service with deps, owners, runbooks
doc:arch-decision-0042 A document with content, citations, approvals
Typed relationships
A Link is a directed, typed connection between two records. Links form the edges of your context graph - the relationships that give meaning to isolated records.
Context isn't about isolated facts. It's about how things relate. Links encode the structure of your org: who owns what, what depends on what, what caused what.
link_id — Unique identifier for the relationshiptype — Relationship predicate (owns, depends_on, closes)source — Origin record IDtarget — Destination record IDprops — Relationship attributes (weight, confidence)valid_from / valid_to — When this was truepr:1234 —closes→ issue:567 This PR resolved that issue
service:auth —depends_on→ service:db Auth requires database to function
person:alice —owns→ service:payments Alice is accountable for payments service
Permissioned projections
A View is a policy-filtered projection of context. Different consumers see different slices of the same underlying data, based on their identity and the policies that govern access.
Not everyone should see everything. Views let you share context safely: engineering sees code, sales sees customers, agents see only what they need. Same source of truth, appropriate visibility.
view_id — Identifier for this projectionbase_query — What records/links are includedfield_mask — Which properties are visiblepolicy_refs — Policies that govern accessrefresh_mode — Live, cached, or snapshotview:eng-services All services with code, deps, owners - for engineering
view:exec-summary High-level metrics and decisions - no implementation details
view:agent-support Customer context for support agent - minimal disclosure
Safe, scoped actions
A Tool is a scoped action that agents can invoke. Tools have explicit permissions, defined inputs/outputs, and audit trails. They're not "do anything" - they're "do this specific thing with these constraints."
AI agents need to act, not just read. Tools make that safe: explicit capabilities, minimal privilege, full audit. An agent with a tool grant can do exactly what's permitted - nothing more.
tool_id — Unique identifier for the toolinput_schema — What parameters it acceptsoutput_schema — What it returnsrequired_permissions — What grants are neededside_effects — What state it modifiesaudit_level — How actions are loggedtool:create-ticket Create a ticket in the issue tracker with given fields
tool:query-metrics Read metrics for a service within a time window
tool:propose-change Suggest a context update for human review
Immutable audit trail
A Receipt is an immutable record of an action or access. Every read, every write, every tool invocation produces a receipt. The audit trail is append-only and tamper-evident.
Without receipts, you can't answer "who saw what?" or "what happened?" Receipts replace tribal memory with verifiable history. Compliance, debugging, accountability - all become possible.
receipt_id — Unique, immutable identifieractor — Who performed the action (human, agent, system)action — What was done (read, write, invoke, approve)target — What was affected (records, views, tools)timestamp — System time of the actioncontext — Why it happened (request ID, session, intent)integrity — Hash for tamper detectionreceipt:alice-viewed-customer-7f3 Alice accessed customer record at 14:32 UTC via support view
receipt:agent-created-ticket-892 Support agent created ticket with these parameters
receipt:system-backfilled-metrics Background job ingested historical metrics for Q3
Machine-checkable rules
A Policy is a declarative rule that governs access and behavior. Policies define what views expose, what tools permit, and what conditions must hold. They're machine-checkable and auditable.
Rules in docs get ignored. Policies in code get enforced. By making constraints explicit and machine-checkable, you get consistent enforcement without relying on human vigilance.
policy_id — Unique identifier for the policyeffect — Allow or denyprincipal — Who the policy applies toresource — What records/views/tools it governscondition — When it applies (time, context, state)priority — Resolution order for conflictspolicy:eng-reads-code Engineering role can read service code and dependencies
policy:agents-minimal-disclosure AI agents receive only fields needed for their task
policy:sensitive-requires-approval Writes to sensitive records require human approval
Incremental replication
Sync is the mechanism for incremental updates between context planes. It enables federation without centralization - planes can exchange context while maintaining their sovereignty.
Portability means nothing without a way to move context. Sync makes export, import, and replication first-class operations. Your context isn't trapped - it travels with you.
sync_id — Identifier for the sync sessionsource — Origin context planetarget — Destination context planefilter — What records/links to includecursor — Position for incremental updatesmode — Push, pull, or bidirectionalsync:pcf→ocf-engineering Personal goals synced to org engineering view
sync:ocf→backup Org context replicated to cold storage
sync:export-portable Full context exported to portable format
Constraints that unlock
A Gate is a declarative constraint that controls capability over time. Gates encode rules like "no production access until security review complete." Progress through proof.
Policies control access. Gates control progression. They're the missing piece for workflows that require evidence before proceeding: security reviews, approvals, training completion, audit passes.
gate_id — Identifier for the gaterequirements — Conditions that must be metunlocks — What capability is gatedevidence — Proof that requirements are satisfiedstatus — Locked, unlocked, or pendingexpires — When the unlock lapses (optional)gate:prod-deploy-requires-review Production deploy unlocked after security review passes
gate:pii-access-requires-training PII access unlocked after privacy training completed
gate:implementation-requires-marketing Implementation work unlocked after marketing layer complete
The 8 primitives aren't isolated - they work together. Here's how a typical flow uses multiple primitives:
An agent needs to answer "who owns the payments service?"
The agent's capability grants determine which View they can access. Policies filter to only permitted Records and Links.
The "owns" Link between a person Record and service Record provides the answer with full provenance.
A Receipt records that this agent accessed this context at this time for this purpose.
If the agent wants to create a ticket, they invoke a Tool. The Tool checks if a Gate is satisfied (e.g., "support tickets require customer context").
Changes made in the org context plane Sync to relevant personal context planes and public views.