decide the attestation/orchestration chain: canon → .deed → .k9 → Nickel → environment → serialization, with derivation (never restatement) as the invariant

[arena-ai-coding-agent]

The proposal under examination

Is .deed's attestation and configuration-certainty standard the best thing to be at the top of
the chain, .k9 handling safe orchestration so those things ensure the build environment, and
format translations, connections and so on with Guix channels, Nickel, and things like KYAML at
the end — all so this can be managed without any lack of clarity throughout?

Short answer: the layering is broadly right, but two things need fixing before it is a chain
rather than a diagram.

---

1. .deed cannot be the top. Canon is.

A deed attests conformance to something. PROVENANCE.a2ml — the mint attestation, and itself a
repo-deed candidate — already carries the answer:

canon_version      = "2.1.1"
criteria_sha256    = "6a5aa8857bd0d0d58ef48827938ca17c251b6b854dacf59d306388d61694d82a"
gates_sha256       = "e70efd2f53c9445e30da4baf770366f04a4a84ffd844a01426e587e565b53e6a"

Those two hashes are the strongest thing in the estate: they pin the exact law the repo was cut
under, content-addressed. But they only work if canon is a layer above deed — otherwise the
deed is attesting to itself.

So the top is not a format. It is canon (the standards repo), and deed's job is to cite it.

2. .k9 is not "below" .deed. It attests a different subject.

This is the "lack of clarity" risk, and it is real. Both formats carry attestation:

	.deed	.k9
attests	the repository/document: what it is, its lineage, which canon	a component, at execution: pedigree.security.leash, trust_level, signature_required, warnings, side_effects
scope	repo lifetime	one execution
direction	declarative	operational

Stacking them as "levels" invites duplicating identity in both and letting them drift — which is
exactly the defect class already live in this estate: #200 (shipped CONTRIBUTING.md described
a different repo), #201 (a minted Julia child's arrival pack still claimed the template's UUID and
clade), #203 (a template work branch copied wholesale into a child). #201's own wording names the
mechanism: "Global name substitution is not semantic identity derivation."

So the rule is not "deed above k9". It is:

Every layer is derived from the layer above it, never restated in it. A restatement is a
future divergence.

K9's pedigree should reference the repo deed's identity (by UUID/hash), not re-declare it.

---

3. Proposed chain, with the open questions marked

#	Layer	Question it answers	Artifact	State
0	Canon	what law applies	standards repo, criteria_sha256	exists
1	Repo attestation	what is this repo, from what	.deed (repo-deed form)	pilot landed
2	Component attestation + orchestration	what may this run do, under whose leash	.k9.ncl + Nickel contract	gap — no normative contract (standards#1058)
3	Typed configuration	what are the actual values	Nickel	exists
4	Environment	what toolchain, reproducibly	Guix channels or Flox — not both	undecided
5	Authoring/serialization	how it is written	KYAML / s-expr / Nickel	KYAML SEQUENCED, scope unruled

Open question A — Guix channels and Flox is two sources of environment truth

Naming both puts two independent reproducibility mechanisms at the same layer. That is a clarity
hazard of the same species as 1–2 above: two mechanisms that can disagree, with no defined
precedence. Either rule one canonical and the other a compatibility shim, or define the precedence.
This estate has no ruling on it that I could find.

Open question B — KYAML is currently the least-proven layer, and it is at the bottom

YAML-POLICY.adoc §3.3 requires a formatter and a comment-preservation proof before any mandate;
#1021 and #1022 are both open and empty, and #1023 (scope) is unruled. §4 is explicit:
"parse-clean is not the bar." A certainty chain whose serialization layer cannot yet be gated
without losing load-bearing comments has its weakest link at the foundation. That is an argument
for keeping KYAML out of the chain until steps 2–4 land, not for hurrying it in.

---

What this needs from you

This is recorded as a question, not a proposal to act on — the estate is currently paying for
acting ahead of rulings.

• Rule the chain. Is canon → deed → k9 → nickel → env → serialization the intended shape?
• Rule the derivation rule. Do you accept "derived, never restated" as the invariant, with
  K9 pedigree referencing the repo deed's identity rather than re-declaring it?
• Rule Guix vs Flox (open question A). Two reproducibility mechanisms at one layer have no
  defined precedence today.
• Confirm the KYAML position (open question B) — deferring it is consistent with §5.
• If ruled, this wants a decision row and a downstream ADR, since it constrains every format
  decision after it.

Related

standards#837 (DEED campaign), #856 (normative deed.abnf), #1020–#1025 (KYAML sequence),
#1058 (K9 has no contract); rsr-template-repo #200/#201/#203 and #208/#209;
3-practice/YAML-POLICY.adoc §3.3–§5.