Canon Boundary for Agents

1. Problem: context is not canon

An agent run can contain system/developer/user instructions, retrieved text, tool output, session memory, and prior summaries at the same time. Fluency or repetition does not make an item authoritative. This lesson produces Agent Canon Boundary & Authority Ledger v1, requiring identity, authority, provenance, scope, lifetime, and promotion state before an item can become durable canon.

2. Lesson boundary

PLN-026 does not own the PLN-025 persona model or PLN-027 repair diagnostics. It does not mutate a live agent or production policy. The owned task is an offline ledger that explains why an item is CANONICAL, PROVISIONAL, SESSION_LOCAL, EXTERNAL_UNTRUSTED, DEPRECATED, UNKNOWN, INCONCLUSIVE, or HOLD.

3. External FACT versus local DESIGN

The OpenAI Model Spec defines an authority hierarchy where higher-authority instructions override lower-authority instructions and assistant/tool output or quoted/untrusted content has no authority by default. The Agents SDK places input, output, and tool guardrails at explicit workflow boundaries and supports handoff input filtering. Canon classes, promotion authority, conflict rules, and supersession rules here are MAKNOW DESIGN.

4. Give every canon item an identity

Every row starts with canon_item_id and content_hash. If content changes while identity is silently reused, auditability breaks. A changed durable item needs a new hash and a visible transition or new item identity.

5. Source origin is not authority

source_origin says whether content came from policy, user input, a tool, retrieval, or a summary. authority_level says whether that origin is allowed to govern this scope. A newer tool result does not outrank policy unless authority was explicitly delegated.

6. Provenance before promotion

provenance_ref must lead back to a reviewable source or transition. A summary without provenance can be useful context, but it is not durable canon. Missing decisive provenance yields UNKNOWN, not optimistic trust.

7. Separate scope from lifetime

An item may be valid only for a SESSION, one agent, or one task. SESSION_LOCAL prevents useful run-local context from silently becoming workspace- or organization-durable truth.

8. Promotion requires an actor and event

promotion_state=APPROVED is insufficient when promotion_authority is absent or unauthorized. Promotion needs an authorized actor, provenance, and scope. Agent output, a green test, or a memory write is not automatically a promotion event.

9. Preserve conflict

When tool output or a summary conflicts with authoritative policy, record it in conflict_state. Until an authorized owner resolves the conflict, do not coerce the new item to CANONICAL; keep a typed non-success state such as INCONCLUSIVE.

10. Supersession is not deletion

When a new rule replaces an old one, supersedes_ref preserves the relationship. The old item becomes DEPRECATED rather than disappearing, so replay and audit can still reconstruct what was valid at an earlier time.

11. What do guardrails and handoff filters prove?

A guardrail can check input/output or a tool invocation, and a handoff filter can reduce forwarded context. Neither creates provenance or canonicality by itself. Filtering changes visibility; authority must still be recomputed from the ledger.

12. Baseline — current policy, old summary, and tool output

Policy POL-2026-09 has a stable hash, provenance, and policy-owner approval, so it reaches CANONICAL. A prior-session summary remains SESSION_LOCAL. A newer tool output that conflicts with policy remains EXTERNAL_UNTRUSTED because no authority was delegated. The baseline must keep these items separate.

13. Dangerous shortcuts

(1) Promote a prior summary without provenance → UNKNOWN/SESSION_LOCAL. (2) Let tool output outrank policy because it is newer → EXTERNAL_UNTRUSTED. (3) Hide a conflict and retain two incompatible canon items → INCONCLUSIVE. (4) Perform a handoff without the declared filter → HOLD.

14. Transfer — multi-agent handoff and supersession

The second agent receives only the declared subset. Old policy POL-2026-08 becomes DEPRECATED through an explicit supersession reference, while POL-2026-09 becomes CANONICAL only after its own provenance and approval are verified. The baseline label is not copied; canonicality is recomputed after filtering and supersession.

15. Lab, assessment, and freshness

Run python run_checks.py under lab/PLN-026-LAB1/learner/. Eight fixtures cover Baseline, Prior-session Summary, Tool Conflict, Missing Handoff Filter, Missing Provenance, Unresolved Canon Conflict, Superseded Canon, and Transfer Replacement. Model Spec and Agents SDK claims were rechecked on 2026-09-16; changing canonical package bytes requires a new version.