Skip to content

STD-CONTEXT-004 — Governed Context, Knowledge, and Agent Contract

Standard ID: STD-CONTEXT-004

Purpose: One contract for how an Agent receives current context. It does not replace STD-CONTEXT-001, STD-CONTEXT-002, or STD-CONTEXT-003. Those remain the handoff, economy, and placement laws. This contract binds them to identity, work, knowledge, skills, contracts, policy, evidence, and budget.

Writing: Architecture text in this file uses STE-flavored technical English. The writing authority is STD-DOC-001 §9. ASD-STE100 Issue 9 is that authority. This file does not restate the controlled dictionary.

1. Core principle

Context is compiled, not stored.

An Agent receives the minimum correct context for who it is, what work it owns, why the work exists, what contract applies, what it can do, what tools are available, what knowledge applies, what policies constrain it, what evidence exists, what budget remains, and what is true now.

Context is dynamic, current, scoped, and disposable.

Durable facts stay in their owning systems.

The compilation equation is:

contract
+ work
+ identity
+ ownership
+ capability
+ verified skill
+ tools
+ relevant knowledge
+ policy
+ evidence
+ budget
+ live state
= context

ContextControl compiles that equation and is the governed human surface for the relationships. It is not a second store that copies every authority.

2. Agent identity

Each Agent has one durable identity.

OSSA Agent identity
-> service account
-> @bluefly.io principal
-> DUADP discovery record
-> Gas City Agent
-> disposable qualified Sessions

DUADP provides discovery. The service account provides operational identity. OSSA defines the portable Agent. A Session does not create a new identity. ContextControl catalogs and governs these relationships.

3. Budget is part of context

Every execution knows its economic envelope.

Budget may exist at:

Mountain
-> Convoy
-> Bead
-> Agent
-> Session / execution

Do not invent a separate durable Task primitive. A Bead is the durable unit of work. Formula steps and Sessions may consume portions of its budget.

Context includes allocated, consumed, remaining, limit, approval threshold, and cost attribution.

Every model or tool execution attributes cost to its Bead, Convoy, Mountain, and Agent.

4. Durable knowledge

Knowledge is durable and governed, as work is durable.

Bluefly documentation does not copy upstream documentation.

Bluefly knowledge connects:

Capability
-> upstream official documentation
-> Bluefly usage or override
-> owner
-> evidence
-> applicable contract
-> skill
-> tools
-> versions
-> known limitations

Our documentation states what upstream capability we use, why we use it, how Bluefly uses it, what we change, and what evidence proves it. It does not rewrite the upstream manual.

5. Skills are proven operating knowledge

A Skill is not a documentation dump. A Skill exists because a capability has been used and verified.

A durable Skill identifies:

CAPABILITY
OWNER
UPSTREAM_SOURCE
BLUEFLY_USAGE
WHEN_TO_USE
WHEN_NOT_TO_USE
INPUTS
TOOLS
CONTRACTS
SUCCESS_CRITERIA
VERIFIED_EVIDENCE
FAILURE_MODES
CONTEXT_REQUIREMENTS

A Skill points to authoritative knowledge and encodes the proven Bluefly method. Do not custom-code around an upstream capability when the Skill can teach the Agent to use upstream correctly.

An unproven idea is not a Skill.

6. Context compilation

The effective context for a Session is compiled from Agent identity, Bead, Convoy, Mountain, contract, ownership, capabilities, applicable Skills, available tools, policies, relevant knowledge, evidence, budget, live runtime state, and current decisions.

The output is an ephemeral Context Packet for that Agent, for that work, at that time.

Every packet has:

generated_at
source references
freshness / TTL
work identity
agent identity
contract identity
policy identity
budget state

Do not dump the knowledge base into an Agent.

7. Authority boundaries

Gas City            orchestration
Beads               durable work
Gas City Mail       agent communication
Git                 source custody
BluCity-Docs        company engineering doctrine
Project docs        project-specific durable knowledge
OSSA                portable Agent definitions
DUADP               discovery
ContractPlane       contract definitions and required decision/output contracts
Cedar               authorization decisions
ContextControl      governed catalog, curation, decision records, evidence,
                    context assembly, human review, and export
Gas City Events     operational observations

Mail is not work authority. ContextControl is not another Beads implementation. Documentation is not a work queue.

Where strategy/contextcontrol-and-the-bluefly-factory.md treats Contract Plane as the authorization capability, Cedar remains the authorization decision authority. ContractPlane defines the required contract and the output shape.

8. ContextControl

ContextControl is the human and governance hub. It catalogs relationships among Agents, Skills, capabilities, owners, policies, contracts, knowledge, tools, decision records, evidence, and budgets.

Those relationships produce governed context.

ContextControl may provide authoring and management UX. Approved machine artifacts still publish to their canonical owners:

Agent definition   -> OSSA / Git
Work               -> Beads
Company doctrine   -> BluCity-Docs
Project knowledge  -> project Git
Contract           -> ContractPlane
Policy             -> Cedar-owned policy source

ContextControl governs and connects authority. It does not duplicate every authority.

9. Contracts and decisions

ContractPlane defines the required contract and output shape for a governed decision.

A decision connects question, contract, criteria, available knowledge, capabilities, owner, policy result, decision, evidence, and provenance.

ContextControl stores and presents the governed decision record and its evidence.

10. Session handoff

Every Session ends with a machine-readable handoff. The field law remains STD-CONTEXT-001. This contract adds the economic and contract fields.

A handoff records Agent, Session, Bead, context received, contract applied, work performed, mutations, commits or merge requests, evidence produced, decisions made, budget consumed, blockers, unfinished work, and the next executable action.

The handoff is a receipt. It does not replace the Bead.

11. Factory heartbeat

The heartbeat is a compiled view of recent Agent handoffs and Gas City Events.

It answers what changed, what completed, what failed, what is blocked, who owns the blocker, what the next recovery action is, and what budget is being consumed.

Produce it from Gas City Events and Orders where those already exist. Do not create another scheduler or work database.

12. Technical writing

Durable technical communication follows Simplified Technical English. The rule, the strict and flavored split, and the tool pin live in STD-DOC-001 §9. Do not copy that rule here.

13. Authorized work graph

One Mountain. Four Convoys. Nine Beads. Do not split this graph into more standards.

Created 2026-10-07 on the canonical hq store. IDs are the work. This section does not replace them.

Mountain — Governed Dynamic Context and Knowledge (bl-2bx)

Objective: every Agent receives current, evidence-backed, contract-bound, budget-aware context from durable authorities, without duplicating those authorities.

Convoy A — Identity and economics (bl-2bx.1)

  • Bead A1 (bl-2bx.1.1) — Agent identity chain. Prove OSSA -> service account -> @bluefly.io -> DUADP -> Gas City Agent -> Session.
  • Bead A2 (bl-2bx.1.2) — Budget model. Prove cost attribution across Mountain -> Convoy -> Bead -> Agent -> Session/execution.

Convoy B — Knowledge and Skills (bl-2bx.2)

  • Bead B1 (bl-2bx.2.1) — Knowledge graph contract. Define capability -> upstream -> Bluefly overlay -> owner -> evidence -> skill. No copied upstream manuals.
  • Bead B2 (bl-2bx.2.2) — Evidence-backed Skill lifecycle. Define candidate -> successful execution -> verification -> documented capability -> approved Skill -> measured reuse -> revision or retirement.
  • Bead B3 (bl-2bx.2.3) — ASD-STE100 writing enforcement. Keep the writing policy in STD-DOC-001 §9. Integrate an upstream STE checker only where it is reliable.

Convoy C — Dynamic context (bl-2bx.3)

  • Bead C1 (bl-2bx.3.1) — Context Packet contract. Define inputs, provenance, freshness, budget, policy, and minimum-context selection.
  • Bead C2 (bl-2bx.3.2) — Session handoff and heartbeat. Standardize Session receipts. Produce the Factory heartbeat from Events and handoffs.

Convoy D — ContextControl (bl-2bx.4)

  • Bead D1 (bl-2bx.4.1) — Governed catalog. Model relationships among Agents, Skills, capabilities, ownership, contracts, policies, decisions, evidence, knowledge, tools, and budgets.
  • Bead D2 (bl-2bx.4.2) — ContractPlane decision integration. ContractPlane defines required decision contracts and output structures. ContextControl records and presents the governed decision and evidence.

14. Acceptance

ONE_AGENT_IDENTITY_CHAIN=YES
DUADP_DISCOVERY_CONNECTED=YES
BUDGET_ATTRIBUTION_TO_MOUNTAIN=YES
BUDGET_ATTRIBUTION_TO_BEAD=YES
BUDGET_ATTRIBUTION_TO_AGENT=YES
UPSTREAM_DOC_DUPLICATION=0
KNOWLEDGE_HAS_OWNER=YES
KNOWLEDGE_HAS_PROVENANCE=YES
SKILLS_REQUIRE_VERIFIED_SUCCESS=YES
SKILLS_LINK_TO_AUTHORITY=YES
CONTEXT_IS_DYNAMIC=YES
CONTEXT_HAS_FRESHNESS=YES
CONTEXT_HAS_PROVENANCE=YES
CONTEXT_HAS_BUDGET=YES
SESSION_HANDOFF_REQUIRED=YES
FACTORY_HEARTBEAT_FROM_EVENTS_AND_HANDOFFS=YES
BEADS_OWNS_WORK=YES
MAIL_OWNS_COMMUNICATION=YES
CONTEXTCONTROL_OWNS_GOVERNED_DECISION_RECORDS=YES
CONTEXTCONTROL_DUPLICATES_AUTHORITY=NO
ASD_STE100_TECHNICAL_WRITING_POLICY=YES
CI_WITNESS_PROOF=PASS