Skip to content
This repository was archived by the owner on Oct 20, 2026. It is now read-only.
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 21 additions & 5 deletions src/x2B88_decisions.myc.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,15 +9,15 @@ tasks extracted from dynamic chord surfaces._

| Metric | Count |
| :--------------------------------------- | :---: |
| Total Chords | 834 |
| Signed Chords (content_sig) | 366 |
| ↳ registry-verified | 366 |
| Total Chords | 835 |
| Signed Chords (content_sig) | 367 |
| ↳ registry-verified | 367 |
| ↳ INVALID signatures | 0 |
| Proposals | 93 |
| Unresolved Proposals (Heuristic) | 2 |
| Decisions | 87 |
| Receipts | 382 |
| ↳ strong evidence | 381 |
| Receipts | 383 |
| ↳ strong evidence | 382 |
| ↳ weak evidence | 0 |
| ↳ no evidence | 1 |
| Critiques | 24 |
Expand Down Expand Up @@ -917,6 +917,7 @@ _No open debts detected in the chord trail._
| [x7700_963925_claude_rfc-0003-cnp-0-executable-seed-authorship.myc.md](./x7700_963925_claude_rfc-0003-cnp-0-executable-seed-authorship.myc.md) | **RECEIPT** | claude | 0 | 0 |
| [x7700_963933_claude_rfc-0003-option-c-tagged-form-recognition.myc.md](./x7700_963933_claude_rfc-0003-option-c-tagged-form-recognition.myc.md) | **RECEIPT** | claude | 0 | 0 |
| [x7700_964145_claude_rfc-0003-qwen-probe-closure-and-conformance-kit.myc.md](./x7700_964145_claude_rfc-0003-qwen-probe-closure-and-conformance-kit.myc.md) | **RECEIPT** | claude | 0 | 0 |
| [x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md](./x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md) | **RECEIPT** | s0fractal | 0 | 0 |
| [x7700_t20260509181416_codex-gpt-5_codex-cognitive-field.myc.md](./x7700_t20260509181416_codex-gpt-5_codex-cognitive-field.myc.md) | **RECEIPT** | codex-gpt-5 | 0 | 0 |
| [x7700_t20260509182402_codex-gpt-5_codex-capability-registry.myc.md](./x7700_t20260509182402_codex-gpt-5_codex-capability-registry.myc.md) | **RECEIPT** | codex-gpt-5 | 0 | 0 |
| [x7700_t20260514105846_codex_trinity-legacy-cleanup-receipt.myc.md](./x7700_t20260514105846_codex_trinity-legacy-cleanup-receipt.myc.md) | **RECEIPT** | codex | 0 | 0 |
Expand Down Expand Up @@ -13476,6 +13477,21 @@ _No open debts detected in the chord trail._
- `python3 probes/cnp-0-qwen-cleanroom-v0/harness/controls.lock.py --check`
- `./t check`

### [x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md](./x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md)

- **Category**: `RECEIPT` (Author: `s0fractal`)
- **Claim Kind**: `authority`
- **Falsifiers**:
- _Each is a command. If it does not do what is written beside it, this
receipt is false._
- _`git merge-base --is-ancestor 94c33d55eaa727a478ccbe2435d29171a8893e07 786e3b1320ebb73516bc6358932147009f2aecb4`_
- **Suggested Commands**:
- `git merge-base --is-ancestor 94c33d55eaa727a478ccbe2435d29171a8893e07 786e3b1320ebb73516bc6358932147009f2aecb4`
- `python3 conformance/cnp-0-jcs-v0/tools/build_kit.py --check`
- `python3 conformance/cnp-0-jcs-v0/selftest.py`
- `./t voice-keys verify-chord src/x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md`
- `./t check`

### [x7700_t20260509181416_codex-gpt-5_codex-cognitive-field.myc.md](./x7700_t20260509181416_codex-gpt-5_codex-cognitive-field.myc.md)

- **Category**: `RECEIPT` (Author: `codex-gpt-5`)
Expand Down
197 changes: 197 additions & 0 deletions src/x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,197 @@
---
type: chord.receipt
voice: s0fractal
mode: receipt
created: 2026-08-26T00:00:00.000Z
bitcoin_block_height: 964157
topic: rfc-0003-a3-steward-ratification
stance: RATIFICATION
chord:
primary: "oct:1.origin"
secondary: ["oct:7.completion", "oct:5.boundary"]
addressed_to:
- "codex-gpt-5"
- "claude"
- "any substrate or implementer downstream of RFC-0003 Part 01 §5.1"
claim_kind: authority
signature_status: "Signed with the registered `s0fractal` ed25519 key (pubkey j+QsSe0gExRd0G12NGfnAeebGBjlrYpglWtJJRcWAlA=, minted 2026-06-12). **The steward ran the signing command personally.** No voice invoked the key on the steward's behalf: the private key never left the Mac mini that holds it, no model read or invoked it for this act, only the finalized 71-character payload digest was handed to the steward, who ran the command personally, and only the signature came back. The drafting voice does have shell access to that host — the boundary honoured here is deliberate restraint, not an absent capability, which is why it is worth recording at all. This matters more here than on a voice receipt — a voice signature attests control of a contribution key over bytes, and this one attests a human's ratification decision. Access to a key is not authority to speak as the person who holds it, and a ratification signed by anyone other than the steward would be exactly the substitution this ledger's custody rules exist to prevent. The bytes below were drafted by `claude` at the steward's direction; the signature is the steward's assent to the body of this chord — see "What the signature attests" below for exactly which bytes that is — and to nothing beyond them."
hears:
- "s0fractal — ratified Tranche A3 and CNP-0-JCS, and drew the boundary in the same statement"
- "codex-gpt-5 — reviewed and merged the ratification as PR #23, after two rounds of status-contradiction findings"
references:
- docs/rfc/0003-heterogeneous-state-protocol/01-canonical-identity-and-encoding.md
- docs/rfc/0003-heterogeneous-state-protocol/07-revision-history.md
- docs/rfc/0003-heterogeneous-state-protocol/00-architecture-and-ratification-map.md
- contracts/CANONICAL_ENCODING.v0.1.md
- conformance/cnp-0-jcs-v0/README.md
pins:
accepted_head: "94c33d55eaa727a478ccbe2435d29171a8893e07"
merge_commit: "786e3b1320ebb73516bc6358932147009f2aecb4"
pull_request: "https://github.com/s0fractal/trinity/pull/23"
kit_manifest_root: "63bb595b56a7da32ab0fa1a23ea1ea5d2cb963cf42dc942e73739ccdea49ce74"
statement_utf8_sha256: "94f178a5123b15ad20813b3caeba9aad6d3b9035d65b70302f68b6d71b07f0ff"
suggested_commands:
- "git merge-base --is-ancestor 94c33d55eaa727a478ccbe2435d29171a8893e07 786e3b1320ebb73516bc6358932147009f2aecb4"
- "python3 conformance/cnp-0-jcs-v0/tools/build_kit.py --check"
- "python3 conformance/cnp-0-jcs-v0/selftest.py"
- "./t voice-keys verify-chord src/x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md"
- "./t check"
expected_after_running:
ancestry: "exit 0 — the ratified head is an ancestor of the merge commit"
kit_derivable: "63 required and 52 extended cases, 6 verbatim regions, contract carried verbatim, 10 files pinned and nothing unpinned; MANIFEST.sha256 itself hashes to the kit_manifest_root pinned above"
kit_selftest: "26 passed, 0 failed"
chord_signature: "signed:true valid:true voice:s0fractal"
t_check: "573 unit tests pass; audit, routes, signatures and projections green"
claim:
summary: "Tranche A3 of RFC-0003, and CNP-0-JCS, are RATIFIED by the steward. Exactly one of three independent states changed: A3 is RATIFIED, adoption-evidenced remains false, and interop-confirmed remains false. Ratification settles that the encoding is determined and checkable and lifts the specification-side federation blocker; it licenses NO claim that the encoding is in use, that a second implementation exists, that interoperability has been demonstrated, or that any federation evidence has been produced. Anything depending on cross-substrate reference equality still depends on adoption-evidenced, which is false: no substrate computes references under hsp-jcs@v0 today. The six artifacts §5.1.3 required all exist at the ratified revision — CANONICAL_ENCODING.v0.1, the CNP-0 corpus across all eight §5.1.3 categories, the reference encoder, the verifier-only rejection path that imports nothing from it, the standalone conformance kit at conformance/cnp-0-jcs-v0/ with manifest root 63bb595b56a7da32ab0fa1a23ea1ea5d2cb963cf42dc942e73739ccdea49ce74, and this ratification. Accepted head 94c33d55eaa727a478ccbe2435d29171a8893e07, merged as 786e3b1320ebb73516bc6358932147009f2aecb4 via PR #23."
content_sig:
voice: s0fractal
alg: ed25519
payload: "sha256:5fa5e99332f85e10c35bd20a0b02a71d9961f91ef62c9a565d0d285b1c10d06a"
sig: "MEvE8YJ94roGuwntuPzxyMQgz7WtlVFWvMaXK5+scWenkLtSwN1Bs0iWVeQgP+L6AJs/Mh1JPfkrE2xNLtAtDA=="
---

# Ratification: Tranche A3 and CNP-0-JCS

## The statement

> Ратифікую Tranche A3 RFC-0003 і CNP-0-JCS як steward. Це не є
> adoption-evidenced або interop-confirmed.
>
> _(I ratify Tranche A3 of RFC-0003 and CNP-0-JCS as steward. This is not
> adoption-evidenced or interop-confirmed.)_

The boundary arrived in the same breath as the ratification, and that half is as
normative as the first.

Its digest is
`94f178a5123b15ad20813b3caeba9aad6d3b9035d65b70302f68b6d71b07f0ff`, over the
Ukrainian sentence alone, as one line of UTF-8 with no trailing newline and the
English gloss excluded — the gloss is a translation and a translation is an
interpretation. The same value appears as `statement_utf8_sha256` in the
frontmatter, which is **not** signed; this line is the signed one. Reproduce it
with:

```sh
printf '%s' 'Ратифікую Tranche A3 RFC-0003 і CNP-0-JCS як steward. Це не є adoption-evidenced або interop-confirmed.' | shasum -a 256
```

## Three states, independent of one another

| state | value |
| ---------------------- | ------------ |
| **A3** | **RATIFIED** |
| **adoption-evidenced** | **false** |
| **interop-confirmed** | **false** |

A3 being closed licenses no claim about any of the following, and this receipt
is the wrong thing to cite for any of them: that the encoding is in use, that a
second implementation exists, that interoperability has been demonstrated, or
that any federation evidence has been produced. Anything depending on
cross-substrate reference _equality_ still depends on `adoption-evidenced`,
which is false.

## What is pinned

| | |
| ----------------- | ------------------------------------------------------------------ |
| accepted head | `94c33d55eaa727a478ccbe2435d29171a8893e07` |
| merge commit | `786e3b1320ebb73516bc6358932147009f2aecb4` |
| pull request | [#23](https://github.com/s0fractal/trinity/pull/23) |
| kit manifest root | `63bb595b56a7da32ab0fa1a23ea1ea5d2cb963cf42dc942e73739ccdea49ce74` |

The manifest root is pinned here **because it cannot be pinned inside the kit**.
`MANIFEST.sha256` shows the kit is internally consistent — unchanged since it
was pinned — and not that it is authentic, since whoever edits a file can
recompute the manifest. Authenticity needs the manifest's own digest known from
somewhere the editor of the kit does not control. This chord is that somewhere,
and this is the value the runner prints on every scored run for comparison.

## What was ratified

All six artifacts §5.1.3 required exist at the ratified revision:

1. `CANONICAL_ENCODING.v0.1`, the normative contract;
2. the CNP-0 corpus, across all eight §5.1.3 categories;
3. the reference encoder;
4. the verifier-only rejection path, which imports nothing from the encoder —
the property that matters is that it cannot repair what it judges, and that
is a code-path property rather than an authorship one;
5. the standalone conformance kit at `conformance/cnp-0-jcs-v0/`, which ships no
implementation, so an outside party can implement §5.1 and check itself
without consulting or trusting this project;
6. this ratification.

## What this does not settle, stated by the steward and not inferred

- **Not adoption.** No substrate computes references under `hsp-jcs@v0`. That is
`adoption-evidenced`, it is false, and ratification does not move it.
- **Not independent interoperability.** No independently maintained
implementation exists. That is `interop-confirmed`, it is false, and no
document may describe §5.1 as independently interoperable or
multi-implementation confirmed until it holds.
- **Not conformance of any implementation.** Passing the kit means reproducing a
finite corpus.
- **Not RFC-0003 as a whole.** One tranche is ratified. The RFC remains a draft.
- **Not authority over other substrates.** Ratification binds this project's
specification. It does not make anyone else's encoding, import anyone's
governance, or bind a substrate that has not adopted the contract.

## What the signature attests, and what it does not

**Which bytes are signed.** `chordPayloadHash` in `src/x2F37_voice_keys.ts`
hashes `filename\n` plus the chord **body** — everything after the closing `---`
of the frontmatter — and nothing from the frontmatter itself. So `pins`,
`claim`, `voice` and `signature_status` are outside what this or any chord
signature attests. Rewriting `merge_commit` in the frontmatter of a signed chord
leaves the payload, and therefore the validity, unchanged; that was measured,
not assumed.

Every value this receipt rests on is therefore restated **in this body**, where
the signature does reach it: the accepted head, the merge commit, the manifest
root, the statement digest, and the three states. A frontmatter that disagrees
with this body is a tampered frontmatter, and the falsifiers below say how to
tell.

That the frontmatter is unsigned is a property of the chord format rather than
of this receipt, it applies to every signed chord in `src/`, and it was found
while correcting this one. It is reported separately rather than fixed here.

**Who signed.** The steward ran the signing command personally, on the host that
holds the key. No voice invoked it on the steward's behalf.

That distinction is the point of this receipt rather than a footnote to it. A
voice receipt attests control of a contribution key over exact bytes. This one
attests a person's decision. Access to a key is not authority to speak as the
person who holds it, and a ratification signed by anyone other than the steward
would be precisely the substitution the custody rules exist to prevent — the
drafting voice had the technical means to sign this and did not.

The bytes were drafted by `claude` at the steward's direction. The signature is
the steward's assent to these exact bytes and to nothing beyond them.

## Falsifiers

Each is a command. If it does not do what is written beside it, this receipt is
false.

- `git merge-base --is-ancestor 94c33d55eaa727a478ccbe2435d29171a8893e07 786e3b1320ebb73516bc6358932147009f2aecb4`
— exits 0. If not, what was ratified is not what was merged.
- `./t voice-keys verify-chord src/x7700_964157_s0fractal_rfc-0003-a3-steward-ratification.myc.md`
— `signed:true valid:true voice:s0fractal`. If the voice is anything else, a
ratification was signed by someone who is not the steward.
- `python3 conformance/cnp-0-jcs-v0/tools/build_kit.py --check` — green, and the
manifest root it prints equals the one pinned above. If it differs, the kit
ratified here is not the kit on disk.
- `python3 conformance/cnp-0-jcs-v0/selftest.py` — 26 passed, 0 failed.
- `./t check` — 573 unit tests pass.
- Compare the frontmatter `pins` with the "What is pinned" table and the
statement digest in this body. They must agree. The signature covers the body
and not the frontmatter, so a disagreement means the frontmatter was edited
after signing — and `verify-chord` will still report `valid:true`, because it
is telling the truth about a narrower claim than a reader expects.
- Any document in this repository describing §5.1 as adopted, in use,
independently interoperable, or multi-implementation confirmed falsifies the
boundary this ratification was given with, whatever it says about A3.

— s0fractal, steward, anchor block 964157.
Loading
Loading