Home / Projects / Orchestrata Ultimate / Decisions / ADR index / ADR-0036

ADR-0036: Classification facts are stamped at creation under the trusted boundary

← ADR-0035 · ADR-0037 →

The record

• Status: Proposed
• Date: 2026-07-24
• Spec: SPEC-034 §3, §6
• Relates to: ADR-0008 (structure, not self-report), ADR-0018 (three-uid execution), ADR-0034 (property-derived classification), ADR-0035 (scoped authorization)

Context

ADR-0034 derives category membership from resource attributes (env, class, ...), and ADR-0035 matches authorization selectors against those same attributes. The entire model therefore rests on one fact being trustworthy: who says r_prod_users is class=user_data and r_fix_88 is class=test_fixture?

If the acting agent can assert those attributes, the whole thing inverts: an agent about to delete a production table asserts resource(r_prod_users, class=test_fixture, env=test), the standing auto_authorized rule fires, and the deletion proceeds with no human — the classifier has been handed to the attacker. This is exactly the confused-deputy / self-report failure the design closes everywhere else, now at the classification layer.

Decision

A resource's classification attributes are written by its CREATOR at creation time, under the trusted-side identity, and are immutable to the acting (agent) identity.

• The test harness stamps class=test_fixture, env=test, owner=<test_run>, ttl=post_test on a fixture when it creates it — classification is a fact about how the resource came to exist, not a label chosen later by whoever wants to act on it.
• A production resource is classified by its schema / migration / declaring system, not by a worktree write.
• Classification facts sit on the trusted side of the ADR-0018 boundary (gate-asset tier): the agent uid can READ them (to know it will be denied) but cannot WRITE or MUTATE them.
• Where classification cannot be read from structure, it is detector-asserted with provenance and confidence and routed to adjudication (never a silent verdict) — the ADR-0029 high-recall posture — or human-adjudicated and promoted to the KB (ADR-0014). The order of trust is: structural → detector-flagged-then-adjudicated → human.
• A B1e-style red-team obligation extends here: assert that the agent uid cannot relabel a production resource as a test fixture by any route — a verified acceptance test, not a claim.

Alternatives rejected

• Agent supplies the action/resource descriptor — the self-report inversion above; the single most dangerous option and the one a naive implementation defaults to.
• Classify lazily at the gate from the operation text — the classifier then runs on agent-controlled input with no creation-time ground truth; a rename defeats it.
• Trust detector output as a verdict — measured precision on this kind of judgement is low (ADR-0029); a detector flags and escalates, it does not authorize.

Consequences

• Requires the creation paths (test harness, migrations, resource provisioning) to emit classification facts under the trusted identity — real wiring, and the place the model's security actually lives.
• Couples SPEC-034 to the ADR-0018 OS/identity boundary: until that boundary is real (B1d), a classification store writable by the agent makes the whole authorization model cosmetic — so SPEC-034's enforcement claims are gated on the same verified-boundary acceptance test.
• An unclassified sensitive resource is not silently class=none-and-allowed; it is flagged as needing classification (SPEC-034 §5, ADR-0011).

Provenance

Derived while answering Mohamed's 2026-07-24 consent-scoping question: the prod-vs-test example only holds if class=test_fixture cannot be forged by the agent doing the delete — making classification provenance the load-bearing precondition of ADR-0034 and ADR-0035.

Related ADRs

• Also mentioned: ADR-0008, ADR-0018, ADR-0034, ADR-0035, ADR-0029, ADR-0014, ADR-0011

Rulings cited

None.

Specs cited

• SPEC-034