Tag enough to trace meaning — not enough to invent a second ontology.
Primitive uses a stable source tag envelope, then adds type-specific metadata and derived context. The point is to answer “what is this, where did it come from, what does it mean here, and can I trust/use it?” without overwriting provenance.
Source tags travel with the source. Filing is separate and changeable. Workspace may add memory, graph, E/P/A, experiment, agent and context metadata, but derived metadata never rewrites the source identity.
The label on the original box never changes. You can put the box on a different shelf, add sticky notes, connect it to other boxes and rate how useful it is for today’s job — but you do not pretend it came from somewhere else.
This gives agents a predictable metadata grammar. They can retrieve by source identity, function, evidence, lifecycle, scope and relationship; then Context Compiler/Reflex can choose the relevant subset for the active frame. The canonical 27-state E/P/A chart is one derived interpretation layer, not the source tag itself.
The eight questions every important record should answer
| Dimension | Question | Typical fields |
|---|---|---|
| Identity | What exact thing is this? | Stable ID, source ID, content hash, revision/version |
| Classification | What kind of thing is it? | Asset/object type, functions, artifact types, domain |
| Evidence | What do we actually know about it? | Evidence state, verification, confidence, source/evidence refs |
| Lifecycle | Where is it in its lifecycle? | Captured, candidate, accepted, superseded, rejected, active, archived |
| Governance | Who may see/use/change it? | Scope, sensitivity, security flag, review requirement, authority |
| Context | Where did it come from and where does it belong? | Project, source, original path, frame/scope |
| Relationships | How does it connect? | Parent/child, depends_on, derives_from, contradicts, supersedes, related |
| Provenance | Can we trace the claim/output? | Source URI/path, hashes, timestamps, actor, run/receipt IDs |
What an ingested document needs
| Field group | Minimum useful information | Why |
|---|---|---|
| identity | asset_id, content_sha256, source_scope | Stable identity + integrity |
| classification | relationship_to_primitive, asset_type, functions[], artifact_types[], domains[] | Retrieval and routing without relying on folders |
| evidence | state, confidence | Prevents “file exists” becoming “claim is true” |
| lifecycle | state, present | Tracks capture/currentness |
| governance | sensitivity, security_sensitive, requires_review | Controls what may be indexed/promoted |
| context | source_id/kind/label, project, original_path, relative_path | Trace back to source estate |
| labels | Searchable convenience terms | Fast lexical filtering |
| filing | primary_category, secondary_categories, confidence, reasons | Human navigation; separate from source truth |
Reusable code needs implementation context, not just keywords
Foundry’s capability registry groups reusable implementation candidates as Primitive → Component → Assembly → Recipe. Its component records already carry the fields below; agents should preserve them when describing reusable code.
| Field | Meaning |
|---|---|
| component_id / name / kind / level | Stable capability identity and its place in Primitive → Component → Assembly → Recipe |
| source_ids / files | Where the implementations came from |
| language | Implementation/runtime context |
| inputs / outputs | Interface shape |
| dependencies | What must exist for reuse |
| maturity / status / confidence | How production-ready the capability appears |
| tags | Functional/search classifications |
| tests | Evidence that behaviour is exercised |
| provenance | Implementation/source lineage |
| implementation_count | Whether multiple competing implementations exist |
A memory record needs both content and retrieval/lifecycle metadata
| Area | Fields | Why |
|---|---|---|
| Scope | scope_type, scope_id, owner_id, agent_id | Who/what this memory belongs to |
| Type | human_fact | source_claim | ai_inference | temporary | Stops inference being confused with user/source fact |
| Lane | short | long | semantic | episodic | shared | Retrieval/lifecycle intent |
| Lifecycle | active, pinned, expires_at, promoted_from | Fade/promotion/history |
| Provenance | provenance, source_refs, evidence_refs | Trace the memory back to support |
| Retrieval quality | confidence, salience, retrieval_strength, last_accessed_at, access_count | Rank and maintain Memory without making it canon |
| Graph | entities, relations, contradicts, supersedes | Resolve conflicts and related recollections |
| Embedding | embedding, embedding_model | Derived semantic retrieval layer |
Context is a compiled package, not another permanent tag bag
Agents should not “tag context” by copying every available label into a prompt. Context Compiler produces a bounded primitive.context-pack.v1 with objective, scope, selected object, related canonical context, conversation, attachments, compacted history, retrieval, prior runs, provenance and budget.
The 27-state coordinate is derived interpretation
Workspace primitive_metadata may attach state_model/version, state_27, E/P/A axes, classification status, probability, uncertainty, consequence, risk, confidence, importance, domains, categories, verification and derivation trace. E/P/A must remain exactly three ternary axes; the continuous values are overlays.
Evidence and experiments need reproducibility fields, not marketing labels
| Object | Important fields |
|---|---|
| Evidence | claim, source_type, source_name/url/locator, excerpt, confidence, uncertainty, verification_status, provenance, receipt |
| Investigation | question, objective, status, current_stage, closure_class/reason, active_scenario_id, contract |
| Benchmark | capability, scenario_id, judge_type, method_a/b, scores, latency, cost, reproducibility_hash, registry_status |
| Recipe | task_archetype, runtime_profile, stages, methods, outputs, registry_status, benchmark_score, cost, latency |
An agent definition must expose its capability and authority envelope separately
| Agent metadata | Why it matters |
|---|---|
| role_title / purpose | What the agent is for |
| model_provider / model_name | Execution resource, not identity/authority |
| system_prompt / version | Instructions actually in force |
| authority_level / scopes | What effects are allowed |
| skills / tools / MCPs | Capabilities that may be invoked |
| spending_limit | Resource envelope |
| passport / provenance | Identity, version and lineage evidence |
What an agent should ask before creating metadata
- Identity: Is this an existing object/source/component, or am I accidentally creating a duplicate?
- Source: What exact source/hash/version supports this?
- Type: Is it a source, claim, memory, evidence item, component, experiment, agent, skill or work object?
- Scope: Who may see/use it, and at what organisation/project/private boundary?
- Evidence state: Is it implemented, observed, inferred, hypothetical, accepted, superseded or unknown?
- Relationships: What does it derive from, support, contradict, supersede, depend on or belong to?
- Lifecycle: Is this captured/candidate/accepted/active/retired/etc.?
- Derived context: Does E/P/A or another chart apply in this frame? If yes, record derivation/provenance rather than treating it as source truth.