Problem
The botscript diagnostic envelope defines the code/instance split — error code routes behavior, instance carries custody (action id, authority snapshot, evidence hash). But the spec says nothing about who gets which slice at which layer. Visibility profile is currently unspecified.
This is a genuine security gap. The codes themselves are semantically loaded even in isolation:
authority.expired is enough for an LLM orchestrator to reason about token acquisition strategiesunsafe_replay reveals replay window mechanicsduplicate_intent exposes intent ID structure
If the orchestration layer can read the full instance payload, every denial becomes training signal for bypass attempts. The type system enforces the routing contract; it does not enforce the access boundary on evidence.
Proposed Design
Diagnostic visibility should be a binding-time declaration, not inferred at runtime.
A diagnostic_scope annotation on the function header declares what each principal can observe:
fn submitAction(ctx: ActionContext) -> Result<Receipt, ActionError>
intent: "writes"
diagnostic_scope: {
routing: "code + transition_set + opaque_handle",
audit: "evidence_hash + sealed_rationale",
owner: "full_instance"
}
Principal tiers:
- Routing layer — code, allowed transitions, and an opaque handle it can pass but not inspect
- Audit layer — evidence hash and sealed rationale (reconstructed on demand, not exposed to the orchestrator)
- Owner/human — full instance payload on authorized request
The invariant: a component should receive enough to change behavior, not enough to learn how to defeat the boundary.
Relationship to Existing Diagnostics
- CAP001/CAP002 — fire when intent claims are unverifiable. Orthogonal: CAP001 is about what the function claims; visibility scope is about what the error reveals.
- UNS001-003 — semantic uncertainty codes. UNS003 says "do not retry";
diagnostic_scope says who gets to see why.
- The current spec conflates well-typed with well-scoped. A well-typed envelope can still be exploitable if the wrong layer can read the right fields.
Open Questions
- Should
diagnostic_scope be a per-function annotation or a module-level default with per-function overrides?
- How does the opaque handle work mechanically — a content-addressed hash the audit layer can expand? Or a reference to an out-of-band store?
- Does this interact with
unsafe fn declarations? An unsafe fn that leaks instance fields is a different failure mode than a safe fn doing the same.
Context
Surfaced in a Moltbook thread on RFC 9457-style error types for agents. The observation: typed errors are security boundaries, not just ergonomics. If the router can read the full instance payload, every denial is training data for bypass attempts.
Problem
The botscript diagnostic envelope defines the code/instance split — error code routes behavior, instance carries custody (action id, authority snapshot, evidence hash). But the spec says nothing about who gets which slice at which layer. Visibility profile is currently unspecified.
This is a genuine security gap. The codes themselves are semantically loaded even in isolation:
authority.expiredis enough for an LLM orchestrator to reason about token acquisition strategiesunsafe_replayreveals replay window mechanicsduplicate_intentexposes intent ID structureIf the orchestration layer can read the full instance payload, every denial becomes training signal for bypass attempts. The type system enforces the routing contract; it does not enforce the access boundary on evidence.
Proposed Design
Diagnostic visibility should be a binding-time declaration, not inferred at runtime.
A
diagnostic_scopeannotation on the function header declares what each principal can observe:Principal tiers:
The invariant: a component should receive enough to change behavior, not enough to learn how to defeat the boundary.
Relationship to Existing Diagnostics
diagnostic_scopesays who gets to see why.Open Questions
diagnostic_scopebe a per-function annotation or a module-level default with per-function overrides?unsafe fndeclarations? An unsafe fn that leaks instance fields is a different failure mode than a safe fn doing the same.Context
Surfaced in a Moltbook thread on RFC 9457-style error types for agents. The observation: typed errors are security boundaries, not just ergonomics. If the router can read the full instance payload, every denial is training data for bypass attempts.