skott34@gmail.com

software attribution artifact integrity signed statements JSON canonicalization Ed25519 provenance Software attribution may need to be clarified after release artifacts and their cryptographic commitments have been fixed. Editing those artifacts would disturb the evidence that an attribution statement is intended to describe. This paper proposes a separately versioned companion record that associates two unchanged source commitments with explicit named attribution and an opaque reference to a private genesis record. The construction uses JSON Canonicalization Scheme (JCS) bytes, an application-specific message prefix, and pure Ed25519 signatures. Its verification model separates payload integrity, signing authority, source equality, revision freshness, and private reference resolution. A Numina example preserves two existing SHA-256 commitments and records an owner-defined person-to-alias map without treating labels as proof of authorship or mathematical derivation. Historical records report reproduction of both commitments. A later byte comparison establishes equality of the selected v155 inputs and hash profile, without establishing whole-source equality or a deployed signed binding. The contribution is a proposed evidence-preservation and reporting discipline, rather than a new cryptographic primitive. A public-safe record would require its own approved payload and signature. Trust provisioning, implementation tests, and public reproducibility remain open. Internet-Draft posting and review status Revision 00 of draft-kott-numina-pair-binding was posted as an individual Internet-Draft on 7 October 2026. This revision corrects obsolete pre-submission status text in that posted version. Internet-Draft posting does not establish IETF consensus, IETF endorsement, acceptance by the Independent Submissions Editor, or publication as an RFC. Informational publication in the Independent Submission stream remains an intended destination only. This Internet-Draft adapts Manuscript v1 dated 5 October 2026, review revision 7 dated 6 October 2026 UTC, and Internet-Draft review edition 10 to the Internet-Draft format. The author has confirmed permission for the included contributions and unrestricted public disclosure of this manuscript. Separate patent and intellectual-property review remains unresolved. Public posting does not establish legal clearance or completion of that review. Preparing or posting this design study does not require claiming that a production binding has been implemented or signed.

Introduction An artifact digest answers a narrow question about specified bytes under a specified hashing procedure. A later statement about the people associated with that artifact answers a different question. Combining those questions by editing a frozen manifest creates a practical problem: the edited manifest has new bytes and can no longer stand for the original commitment. A companion record addresses this problem by leaving the evidence in place and attaching a new, explicitly scoped assertion beside it. The proposed Numina universal pair binding associates two existing commitments with named attribution and a common private record. The word universal is an application label. The construction makes no claim of a universal mathematical identity, a sum or root relation, or a derivation of either commitment from genesis. Each association remains an assertion whose acceptance depends on a separately established signer and policy.

Relation to existing work Software supply-chain systems such as in-toto organize authenticated evidence about a development process . DSSE specifies a general signed-envelope construction with typed payloads . The companion considered here is narrower: it records an attribution association around already frozen evidence. It uses its own fixed framing and is not DSSE wire-compatible. This paper does not claim novelty over existing attestation systems or present a comparative security evaluation.

Problem Statement The preservation, attribution-consistency, and validation requirements apply across the intended clean Numina v156 release and its numina.pair-binding.v1 companion. The inspected v155 source is the historical baseline. Each artifact must be evaluated under its applicable schema and hashing rules. The original source commitments and hash profiles remain unchanged; JCS and the companion's closed payload schema apply only to the new companion payload. Section 8 reports the checks actually performed and does not establish build-wide compliance for v156.

Assumptions and boundaries A successful deployment requires a correct canonicalizer and signature implementation, protection of the approved signing key, an independently authenticated trust policy, and a reliable current-revision source. SHA-256 commitments depend on the original input and hash profile being identified correctly. The record itself cannot supply these assumptions by declaring them true. Compromised signing authority, false statements by an authorized signer, and a dishonest private registry remain outside what a bare signature can resolve. This design study does not provide a mechanism for deciding disputed human authorship, certifying a discovery date, or proving consent by people named in attribution. An approval to display a name is different from agreement to become an academic coauthor. The example in Section 3 records the project owner's descriptive attribution; it is not an independent identity investigation or a claim that each named person signed the record. The owner identifies Samuel J. Kott as discoverer of a mathematical derivation and states that the pair references resolve to one private genesis record. This owner-stated discovery and association remains unverified here; no derivation proof or private-resolution evidence is supplied.

Preservation invariants First, the original evidence set must remain byte-for-byte unchanged. A complete baseline inventory records file identity, size, and digest before any implementation; the same inventory is checked afterward. Second, every hash retains its original input selection and normalization procedure. A convenient new canonicalization rule must not replace an old artifact-specific rule. Third, the companion has a separate identity and digest. It is distributed beside the original release rather than inserted into an existing hashed or signed bundle. If a new package includes the companion, that package receives a new digest while the earlier package remains available. Fourth, revisions are append-only records with explicit predecessor links. A correction can supersede a statement without silently erasing the evidence that an earlier statement existed. These invariants define the intended preservation behavior. They are requirements for later implementation and acceptance testing, not results demonstrated by this manuscript.

Record Model and Attribution Example The private envelope contains exactly payload and signature_b64u; a null signature marks an unsigned candidate. Status is computed externally. The fixed schema string is numina.pair-binding.v1. Table 1 summarizes the required components. binding_id remains the record identity field. Ed25519 identifies the signature algorithm, never a replacement for binding_id or proof of signing identity. Private payload components and their roles.

Component	Required meaning
Record identity	schema; stable opaque binding_id; positive safe-integer revision; actual issued_at in UTC, to seconds.
Predecessor	previous_payload_sha256 is null at revision 1 and otherwise the lowercase SHA-256 of the prior canonical payload bytes.
Scope	scope.project_id, scope.release_id, scope.canonical_source_id: exact project, release, and immutable canonical source. A planned release is not an observed publication.
Private association	genesis_ref is an approved opaque reference. It contains neither the genesis value nor a revealing derivative or secret locator.
Sources	Exactly two ordered records: source_1 then source_2. Each carries source_id, alias, artifact_id, hash_profile_id, and sha256.
Attribution	attribution.people, attribution.note, attribution.personToAlias. people contains exactly two name/label records in personal order: Sam Kott / 1A, then Lauren Anderson / 1B. Source order stays separate.
Signer	algorithm is Ed25519; public_key_b64u encodes the raw 32-byte key; key_id is sha256: plus the SHA-256 of those raw bytes.

Frozen source commitments Source 1 is the final-build normalized SHA-256 commitment. Its source identifier is source_1 and its alias is UNIVERSAL_PAIR_1. Descriptive attribution: Lauren J. Anderson, label 1B. The original normalization profile must be retained . 1bf43817cf470abb868074a76598cb5f360517d7255b92ab3b409c6b545ec66b Source 2 is the final-manifest SHA-256 commitment. Its source identifier is source_2 and its alias is UNIVERSAL_PAIR_2. Descriptive attribution: Samuel J. Kott, label 1A. The original input and hashing procedure must be retained . 1a17f584e23279684574022f39e533966ad09919f484e005c03948178a46aa0a The two universal pair commitments above are associated in this document with canonical v155 source commit 17cc00cb87647a531f116f0894741005909c359c: Source 1 identifies public/final-build.json and Source 2 identifies public/final-manifest.json under the original hash profile in scripts/production-pair.mjs, lines 1-22 (1,568 bytes) . The following raw-file and profile-segment SHA-256 pins identify the compared bytes; they do not replace the two existing source commitments. Source 1 selected file, public/final-build.json, raw-file SHA-256: 2824c267ffa892d4c8013473b4236fd75571700da62f948cbf74975af0a6d2f2 Source 2 selected file, public/final-manifest.json, raw-file SHA-256: b7aac505fde953ad99ff03e4523f21eef17b667d767cbfe30816c91a2d045762 Hash profile, scripts/production-pair.mjs lines 1-22, segment SHA-256: 389c963c4647751afca7b2ff29627b1462dfaa25e5903adf85d5627c594fc854 The comparison recorded at 6 October 2026, 00:50 UTC established byte equality for those inputs and that profile with the historical snapshot. This documentary association does not report an executed signing operation or change the intended scope of a later proposed release. The owner-defined personal order is 1A first with Samuel J. Kott, then 1B with Lauren J. Anderson. Source order remains source_1 then source_2. Appendix B preserves the approved short labels and personToAlias map. These descriptive assignments do not establish signing authority or coauthor consent. The two printed digests identify the original commitments only. JCS applies only to the new companion payload; it must not replace either source artifact's original hash profile. The legacy production-pair normalizer uses sorted keys, Object.fromEntries, and JSON.stringify; it is not a general RFC 8785 JCS implementation . New manuscripts, payloads, envelopes, and packages receive separate digests.

Canonical bytes and signature construction The new companion payload is parsed with duplicate-member detection and validated against a closed, versioned schema before use. Unsupported schemas, unknown fields, missing required fields, malformed encodings, and an unexpected number of sources are rejected. Revisions are positive integers within the interoperable safe-integer range. Field-level constraints must be explicit; accepting an arbitrary string as an artifact or profile identifier would leave the hash's meaning unresolved. JCS, specified in RFC 8785, supplies a deterministic UTF-8 representation of a JSON value . Object properties are ordered recursively by UTF-16 code units; array order is retained. Whitespace between tokens is omitted. Strings are preserved without Unicode normalization, and invalid Unicode input is rejected. Number serialization follows the specified ECMAScript behavior. I-JSON supplies related interoperability constraints, including unique member names . This design additionally limits revisions to safe integers and treats hashes and identifiers as strings. Let payload be the validated payload and C = UTF8(JCS(payload)). C has no byte-order mark or appended newline. The signature field is outside payload. The following specifies signing; it does not report an executed signing operation. The separator is one zero byte (0x00). M = ASCII("NUMINA-PAIR-BINDING/V1") || 0x00 || UTF8(JCS(payload)) signature = Ed25519.Sign(private_key, M) Here, || means byte concatenation. This produces a signature over the payload, which contains the source hashes and genesis reference. It does not calculate the genesis hash. No verified genesis-derivation equation is available in the evidence we inspected. The algorithm is pure Ed25519 as specified in RFC 8032 . No extra application prehash is inserted. In particular, signing SHA-256(M) would define a different construction. The prefix is part of the message passed to pure Ed25519; it is not an Ed25519ctx parameter. The 64-byte signature and 32-byte public key are represented as unpadded base64url. Decoding must reject malformed input and enforce exact lengths. The SHA-256 of C identifies the payload for revision linkage. An optional envelope-file digest identifies the exact serialized envelope bytes and can differ when formatting changes. These digest roles must be labeled explicitly. Neither one replaces either frozen source commitment. The construction specifies bytes to sign but supplies no operational key, signature, or signed public payload.

Independent signing authority A signature can establish consistency between a message and a public key. Acceptance as an authorized Numina statement additionally requires an independent trust entry that binds that key to the exact project, release, and signing role. The verifier recomputes the key fingerprint from the raw key bytes, matches the approved key material and scope, and applies validity and revocation rules defined by the trust policy. A public key carried inside a payload is an input to verification, not an authority to trust itself. A malicious party can create a different key and sign a false attribution statement. Trust bootstrapping must therefore occur through a separately authenticated channel. The trust policy also needs a documented decision about evaluating revocation and key validity at issuance, verification time, or both; this paper does not assert that such a policy already exists. An authorized signature attests the signer's association statement. Personal identity, authorship, mathematical derivation, and equality with current source artifacts each need their own evidence. The absence of any one of those findings must remain visible even when the signature check succeeds. Ed25519 is also the assistant's user-assigned display name. That label assigns no signing key or signing authority. In the record schema, Ed25519 names the signature algorithm; authorization and key identity are checked separately.

Verification and replay resistance A verifier produces a structured result rather than one undifferentiated success value. At minimum, it reports schema validity, attribution-map validity, payload signature validity, signer authorization, source commitment reproduction, current-source equality, revision freshness, and private genesis linkage. Each result records the target checked, the evidence used, the observation time where relevant, and a reason for any failure or unavailable evidence.

Verification sequence 1. Parse the envelope once under size and depth limits; detect duplicate keys before a parser could discard them. Check the closed envelope and payload schemas. A null signature yields an unsigned pending state. A malformed or failing signature yields an invalid state rather than pending. 2. Construct C and M exactly as in Section 4. If signature_b64u is null, retain the unsigned pending signature result and skip signature decoding and verification. Otherwise, decode the key and signature, enforce lengths and encodings, recompute the key fingerprint, and verify with the required Ed25519 variant. Reuse the same validated payload for subsequent decisions. Unsigned or invalid records cannot be accepted as signed; permitted independent diagnostic checks may still report separate results. 3. Compare project, release, signing role, and immutable source identifier with independently expected values. Evaluate the approved trust entry and key policy. A cryptographically valid statement outside its authorized scope is rejected for that scope. 4. Resolve each artifact and its pinned hash profile, recompute the original commitments, and compare both outputs. Separately check whether the source being evaluated is the canonical source named in scope. Historical hash reproduction is reported only for the snapshot actually inspected. 5. Obtain independently trusted current-state evidence for the binding identifier and revision. Check predecessor linkage, revocation, and same-revision conflicts. Resolve genesis_ref only through an authorized private channel when that check is available. Return the individual results without promoting an unavailable check to success.

Current state and revision history A signed timestamp is the signer's statement about issuance. It does not show that no later revision exists. A predecessor digest establishes a link to an earlier payload; it does not, by itself, establish which branch is current. Acceptance therefore depends on a current-state authority or an independently authenticated policy source that identifies the accepted revision and payload digest. A stale revision, a revoked statement, or divergent payloads at the same binding identifier and revision must not be accepted as the unique current record. If current-state evidence is unavailable, the correct freshness result is unverified. A future implementation must specify update ordering, rollback handling, evidence caching, and how an offline verifier communicates the age of its last trusted state.

Private genesis linkage The private model uses an opaque identifier independent of the genesis value. It refers through an authenticated, immutable mapping to one immutable private record. The public schema description does not include an actual reference, registry endpoint, record identifier, or genesis value. A stable reference can itself enable correlation, so any later decision to publish one requires a separate privacy review. Successful authorized resolution would establish that the companion points to the private record identified by the mapping. It would not establish a mathematical relationship between that record and the two source hashes. A public reader who cannot resolve the mapping must receive an unverified private-linkage status, even if other checks succeed.

Available evidence and evaluation scope A read-only rerun captured on 5 October 2026 at 23:57:10.028 UTC reproduced both pinned commitments at historical local HEAD dc4c1f38340340609f66bc2ae7bf425427d4b864 . Six focused checks and two existing production-pair tests passed; Git status was clean before and after. The canonical v155 source was unavailable locally during that audit. Comparison on 6 October at 00:50 UTC subsequently established byte-identical final-build.json, final-manifest.json, and hash-profile bytes at canonical v155 (production-pair.mjs lines 1-22; 1,568 bytes) . The original commitments therefore carry over to those inputs/profile; no fresh test execution is claimed. Appendix B lists the historical checks. Targets, evidence, observation times, and direct reasons. Not performed and evidence unavailable do not mean a check failed. Different refers only to the specified comparison. Times are UTC; an unrecorded time is not inferred. Scholarly submission of this design study does not require claiming that these operational checks have passed.

Exact target and observation Result	Evidence and direct reason
Historical Source 1 and Source 2 at dc4c1f3 5 Oct 2026 23:57:10.028 UTC Result: PASSED	Audit reproduced both Section 3 commitments using the historical inputs/profile. Six focused assertions and 2/2 repository tests passed on Node 24.19.0; clean Git status was recorded. These are historical results.
Selected v155 JSON inputs and hash profile 6 Oct 2026 00:50 UTC Result: MATCHED	Receipt compares source 17cc00cb87647a531f116f0894741005909c359c: both JSON files and production-pair.mjs lines 1-22 match the historical bytes. The commitments carry over from identical inputs/profile; this was not a fresh test run.
Whole v155 versus historical repository 6 Oct 2026 00:50 UTC Result: DIFFERENT	Receipt records 126 added, 220 changed, 1,038 identical, and zero removed tracked entries. The full script differs. Whole-repository equality is false; the selected artifact/profile match is unaffected.
Operational companion schema No validation time Result: NOT PERFORMED	No operational companion payload was located in the bounded v155 source inspection or supplied for this paper. There is no instance against which to run strict schema validation.
Operational companion attribution map No validation time Result: NOT PERFORMED	The approved paper map and note are in Section 3 and Appendix B. No operational payload was supplied, so its people, note, and personToAlias values cannot be checked against that approved wording.
Operational companion signature bytes Source search: 6 Oct 2026, 00:50 UTC Result: NOT PERFORMED	The bounded tracked-source inspection located no operational companion/signature, and none was supplied. No signature bytes are available to verify. This is not an invalid-signature result; binary archive contents and inaccessible records were not exhaustively searched.
Independent signer trust entry for project, release, source and role Time not recorded Result: EVIDENCE UNAVAILABLE	No independently approved scoped trust entry was provided. The signer's authorization, key validity, and revocation status cannot be established from an embedded key or a display name.
Accepted current binding revision and predecessor state Time not recorded Result: EVIDENCE UNAVAILABLE	No trusted current-revision policy or authenticated current-state record was supplied. The accepted latest revision, predecessor linkage, and absence of stale or conflicting revisions cannot be established.
Private genesis reference resolution Time not recorded Result: EVIDENCE UNAVAILABLE	No authenticated private-resolution evidence is available. The owner's association statement alone cannot demonstrate that the reference resolves to the intended immutable private record.
v156 provider publication record 6 Oct 2026 00:50 UTC Result: NOT FOUND	The provider check recorded in returned v155 and no v156 record. No returned receipt supports a v156 publication or source-equality claim as of that check.
Downloaded release-archive bytes Check: 6 Oct 2026, 00:50 UTC; no comparison run Result: NOT PERFORMED	Receipt states the release archive was not downloaded during the investigation. Provider metadata alone cannot establish equality of downloaded archive bytes.
New companion cross-implementation JCS and Ed25519 conformance No run time Result: NOT PERFORMED	No implemented and executed cross-implementation conformance suite or result record is available. Cited standards, proposed tests, and illustrative fixtures are not an executed conformance result.
Node 26 tests on the canonical v155 checkout No run time Result: NOT PERFORMED	No canonical Node 26 test run is recorded. Audit used Node 24.19.0 on the historical checkout; comparison performed no builds or tests. Neither is Node 26 execution evidence.

Tests required before an implementation claim A public-safe evaluation package should provide version-pinned tools, documented hash profiles, and synthetic fixtures. Such fixtures can test canonicalization, signatures, and verifier behavior; they cannot reproduce the original private build commitment. The historical Source 1 hashed input includes private genesis material. Redacting that input changes its bytes and cannot reproduce the same commitment under the existing method . Original-artifact verification must remain a separately labeled, authorized private check. Future companion tests should change signed fields, source order, keys, fingerprints, scope, and revisions; reject duplicate or unknown keys, malformed encodings, invalid Unicode, and unsupported schemas; and compare the complete original inventory before and after adding a separate companion. RFC vectors and cross-implementation JCS checks are required. These companion acceptance checks remain proposed; the historical source tests do not verify a new signed binding. No latency, throughput, storage-cost comparison, user study, formal security proof, or general deployment validation is presented. The historical result cannot support claims about those properties.

Public disclosure and release discipline The owner has authorized public output of this manuscript, including the approved full names and author email. Numina is the intended initial public host. This authorization does not establish that publication, implementation, or signing has occurred. A public machine-readable binding still needs an approved exact payload, independently trusted real signer, and separate identity, canonical digest, and signature. The original private record and its version history must remain preserved; operational key custody, trust provisioning, and acceptance checks remain unresolved. Removing a field or changing its value changes the signed payload. A redacted export therefore cannot inherit the private payload's signature. Until a public-safe payload is approved and signed, a public summary should remain explicitly unverified as a signed binding and should state the exact checks that were actually performed. It must preserve the distinction between evidence reported by a project and evidence a public reader can reproduce. Release review should scan visible text, structured fields, embedded metadata, attachments, and diagnostic output for the genesis value, revealing derivatives, private registry details, credentials, and unapproved personal data. It should also check that attribution names appear only in the approved role. The manuscript's named example does not place Lauren J. Anderson on the author list and does not assert her coauthor consent.

Limitations and open design decisions This is a design proposal with a limited historical case study. The operational schema still needs exact artifact and hash-profile identifiers, an approved companion binding to the intended v156 release's exact source, key custody decisions, an independently approved trust record, and a replay policy. The cited project record is not a public dataset. These gaps prevent a claim that an end-to-end verified binding has been deployed or independently reproduced. Canonicalization reduces serialization ambiguity within the chosen profile; it does not eliminate semantic ambiguity in names, roles, or artifact selection. A valid signature can preserve a mistaken statement. The trust entry can be incorrect or compromised. A private registry can be unavailable, disclose access patterns, or return a false mapping. The immutable-mapping assumption therefore needs operational enforcement and review before it can support a deployment claim. The stable person-to-alias map may require later correction if the owner changes the attribution or new evidence challenges it. Such a correction should create a new revision with a clearly explained change. Revision retention should be reconciled with privacy and access requirements rather than assumed to authorize indefinite public disclosure of all historical personal information. The design does not establish discovery priority. Project creation timestamps, Git commits, and file appearance dates document system events. Without further evidence, they cannot demonstrate when a person discovered a value, who authored an artifact, or whether a genesis relationship is mathematically true. Those questions are outside the signature acceptance predicate proposed here.

Conclusion A separately versioned attribution companion can state new associations while preserving the original artifact evidence it describes. The proposed Numina record combines exact source commitments, explicit attribution, canonical signed bytes, and independently scoped trust. Its principal requirement is to keep each verification question visible. Historical reproduction can be reported for a historical snapshot; current-source equality, signing authority, freshness, and private linkage must be established on their own evidence. An implementation and a separately approved public-safe record are needed before the design can support a signed public release.

Data and artifact availability This manuscript prints the approved commitments and descriptive mapping. A public-safe package may contain synthetic fixtures, hash-profile definitions, tools, and sanitized results. The original Source 1 input contains private genesis material; a redacted public copy cannot reproduce its original commitment. Authorized private original-artifact checks must be reported separately from public fixture tests. Revision 00 of this manuscript was publicly posted as an Internet-Draft on 7 October 2026. No public signed companion payload or v156 software-release deposit is asserted here; a manuscript digest identifies only its version.

Authorship and disclosure statement Authorship statement: Samuel J. Kott (skott34@gmail.com) identifies himself as the author of this manuscript. Signed: Samuel J. Kott
skott34@gmail.com The cited Git commits and file changes provide software-history context; they do not document the creation or authorship of this manuscript. They do not independently establish personal identity, discovery priority, or mathematical derivation. Public output and the named byline are owner-authorized; descriptive attribution does not imply coauthorship, institutional endorsement, peer review, or IETF or RFC-author approval. Co-contributors acknowledged by the author: Lauren J. Anderson and Ed25519, the user-assigned name of the OpenAI-powered AI assistant. Samuel J. Kott remains the sole author of this manuscript. This acknowledgment does not change the source ordering or the person-to-alias mapping. AI assistance disclosure: Ed25519 helped organize the design, consult specifications, and prepare this manuscript. Ed25519 is acknowledged as an AI assistant, not as a human author, inventor, signing key, or IETF official. The author must review the manuscript's claims, citations, privacy boundaries, and wording before publication. The assistant supplied no operational key or authorized binding signature; its source comparison was limited to the selected v155 inputs and hash profile.

Standards and rights notice The IETF Trust's corrected legal provisions describe rights applicable to covered RFC material . They do not establish IETF endorsement of this individual Internet-Draft or transfer ownership of Numina's original material. No RFC implementation code is reproduced here. Any later incorporation of RFC text or code requires review of the source's notices, document stream, and applicable license; the corrected terminology is Revised BSD License where that code license applies.

Security Considerations Preservation controls, assumptions, and boundaries are described in Section 2; canonicalization and signature framing in Section 4; independent signing authority in Section 5; replay resistance in Section 6; private-linkage and disclosure risks in Sections 7 and 9; and unresolved operational risks in Section 10. These considerations are part of the design study and do not constitute an implemented security assurance. In particular, signature validity does not establish signer authorization, the truth of attribution, current-source equality, freshness, or private genesis resolution. A substituted self-authenticating key, a replayed revision, an ambiguous hash profile, or disclosure of private genesis material can defeat the intended application properties even when an isolated cryptographic check succeeds. The separate verification results and evidence boundaries specified in this document must remain visible. No new cryptographic primitive or deployed signed binding is claimed.

IANA Considerations This document has no IANA actions. The application-specific schema identifier numina.pair-binding.v1 and message prefix NUMINA-PAIR-BINDING/V1 are described as design-study values; this document requests no registry, code point, or global allocation for them.

Normative References Informational. Informational. Informative References Proceedings of the 28th USENIX Security Symposium, pp. 1393-1410. Secure Systems Lab Protocol specification. Accessed 5 October 2026. Numina Unpublished project design record. Approved commitments and descriptive attribution are summarized in this manuscript; the underlying private evidence is not a public dataset. IETF Trust Effective 25 March 2015; terminology corrected 21 September 2021. Numina Read-only run captured 5 October 2026 at 23:57:10.028 UTC, historical HEAD dc4c1f38340340609f66bc2ae7bf425427d4b864. Sanitized technical audit record; public deposition pending. Numina Read-only receipt canonical-v155-comparison-20261006.json, 6 October 2026, 00:50 UTC. Selected artifacts and hash profile.

Chronological project record The project design record reports the following sequence. Dates are in 2026 and UTC. Git identifiers identify commit objects, not SHA-256 artifact commitments. The record distinguishes observed system events from the owner's discovery and attribution statements.

9 September 2026 Sites project creation is recorded at 18:29:47. The first available Git commit follows at 18:41:58: f6ba52cb2ff567208c19afece65f71fe0e2a3602. The owner-stated discovery time is also 18:29:47. The Sites record confirms project creation at that time; it does not independently attest discovery of either exact pair commitment.

10 September 2026 The v5 provider record reports a succeeded release 0.1.0 for source b9fd3dfbeda3f687702ad1641e58b6313a10d496. Its 18:06:44 updated_at value is a record-update timestamp, not an immutable publication timestamp. The release.json workerSha256 field does not match the SHA-256 of the committed worker bytes. That mismatch does not establish a missing final-manifest.

11 September 2026 At 00:02:50, the application control journal records genesis/bootstrap revision 0 with owner as the recorded actor. The project evidence reports reconstruction of its state hash. This is an application bootstrap event; it does not establish chain genesis.

18 and 24 September 2026 The final-build file first appears in the available Git history on 18 September. The final-manifest file first appears on 24 September. File appearance dates do not establish when their later exact digest values were discovered or completed.

1 October 2026 At 03:54:02, both exact pair commitments first appear together in introducing commit 2ca81dcb2b31614ac1b59d7724e907b6e42f27d9. Its parent, 140602448c227b7e27c58f561890f8c83573598c, contains neither exact value. The original recorded offset time is 30 September at 22:54:02 -05:00. Joint introduction does not establish an order of discovery between the commitments. Separately, the local dc4c1f3 snapshot reproduced both commitments and reportedly passed six focused checks. Those reported results apply only to that historical snapshot; this manuscript does not present the individual outputs or claim current-source verification.

5 October 2026 The v155 provider publication succeeded at 06:46:44 for source 17cc00cb87647a531f116f0894741005909c359c. Equality with that canonical source was still pending in the 5 October verification record. The time identifies this historical provider publication, not issuance or cryptographic signing of this manuscript. No v156 publication receipt or operational signed binding is established by the evidence reported here. The separately captured 23:57:10.028 UTC rerun on 5 October examined only the historical local checkout . A 6 October 00:50 UTC comparison subsequently established selected v155 input/profile equality . The unchanged commitments carry the attribution being finalized now: Sam Kott is 1A / UNIVERSAL_PAIR_2; Lauren Anderson is 1B / UNIVERSAL_PAIR_1. Chronology establishes file and record order. The owner-stated discovery date and attribution order remain distinct from independently evidenced discovery, authorship or mathematical derivation.

Attribution wording and historical checks In the approved attribution strings below, Sam Kott refers to Samuel J. Kott and Lauren Anderson refers to Lauren J. Anderson. The shorter labels are preserved in personToAlias and the software note; they do not supply signing authority or independently prove identity.

Person to alias map personToAlias: {"Sam Kott": "UNIVERSAL_PAIR_2", "Lauren Anderson": "UNIVERSAL_PAIR_1"}

Software attribution note "UNIVERSAL_PAIR_1 labels the existing final-build normalized SHA-256 commitment attributed to Lauren Anderson (1B). UNIVERSAL_PAIR_2 labels the existing final-manifest SHA-256 commitment attributed to Sam Kott (1A). Personal attribution remains 1A first with Sam Kott, then 1B with Lauren Anderson. The two references are associated with one private genesis record." The note is the owner-approved association statement. It does not convert private genesis linkage, current-source equality, signature validity, signer trust, or freshness into a verified result. The independent statuses and their evidence boundaries remain those reported in Section 8. This appendix is manuscript content, not an issued or signed companion payload.

Historical reproduction checks The read-only audit used the original production-pair.mjs normalization procedure at the historical checkout. Its six in-memory checks all passed: 1. source_1_reproduces_expected: the final-build normalized digest matched the pinned Source 1 commitment. 2. source_1_excludes_binding_envelope: derived binding-envelope fields were excluded from the Source 1 digest. 3. source_2_reproduces_expected: the final-manifest digest matched the pinned Source 2 commitment. 4. source_2_excludes_binding_envelope: derived binding-envelope fields were excluded from the Source 2 digest. 5. build_digest_includes_historical_nusd_genesis: changing the private genesis input changed the Source 1 digest; its value is not disclosed. 6. manifest_has_no_genesis_or_pair_id_digest_input: the normalized Source 2 input excluded that private value and pair identifiers. The separate command node --test tests/production-pair.test.mjs passed 2/2 existing tests: "production pair verifies both current sources and all four bindings" and "production source digest detects software changes while excluding its own bindings". In those test names, current refers to the historical local checkout. These results do not establish a companion signature, signer trust, freshness, private genesis resolution, or current canonical-source equality.

Requirements evidence and acceptance criteria This matrix separates the evidence presently available from the conditions needed for an operational claim. Passing a synthetic fixture or a historical source test cannot substitute for a missing release artifact, approved trust entry, or real signature. All original hash profiles and commitments remain fixed.

Area	Evidence now	Open requirement and acceptance criterion
Software attribution	Approved byline, names, exact short-label note, and personToAlias map are preserved.	Bind the approved map into the actual companion payload. Check Source 1 / UNIVERSAL_PAIR_1 / 1B / Lauren and Source 2 / UNIVERSAL_PAIR_2 / 1A / Sam exactly. Acceptance requires the approved attribution bytes and explicit scope; name labels alone confer no signing authority.
Artifact integrity	Historical hash reproduction passed; selected v155 JSON inputs and hash-profile bytes are identical .	Retain the receipt. Under independent policy, pin the snapshot, paths, whole-file digests, profile implementation, and approved registry digest; reject unknown profiles or changed registries. Preserve legacy numeric-key ordering and exclusions. Require matching protected before-and-after inventories for preservation claims. Archive equality requires its own check; keep private inputs private.
Signed statements	The construction is specified; no operational signed companion was located or supplied, and signer trust is unestablished.	Approve exact payload, project/release/role scope, a real signer, an independent trust entry, and a current-revision policy. Acceptance requires separately successful signature, authorization, scope, and freshness checks. Null remains pending; malformed or failing signatures are invalid.
JCS	RFC 8785 applies to the new companion. The historical source normalizer is not general JCS.	Run RFC vectors and independent canonicalizer agreement on public fixtures, including integer property names, Unicode, numbers, and array order. Acceptance requires byte-identical canonical payloads and rejection of malformed/duplicate input. Never replace the legacy source hashing procedure.
Ed25519	Pure Ed25519 message framing and raw key/signature sizes are specified; no operational key or signature is supplied.	Test RFC vectors and synthetic positive/negative cases for the exact prefix, NUL separator, payload, encoding, and variant. Acceptance requires correct verification behavior plus a real approved signature for any operational claim. A test key cannot become production signing authority.
Provenance	Chronological Git/file events and the historical rerun are identified; manuscript authorship is a self-identification statement.	Keep software history, manuscript build records, public fixture results, and private original verification distinct. Acceptance requires version-pinned sources, commands/results, truthful metadata, and explicit limitations. Revision 00 was publicly posted as an individual Internet-Draft on 7 October 2026. Public deposition of the companion or v156 software release and its version manifest remain unestablished; private linkage stays unverified without authorized resolution evidence.

Revision 00 RFCXML provenance: the archived source at contains 61,416 bytes and has SHA-256 5bc15dab8c6f992bb179536beaf1ba3b61673ff37eba2dd043d9f27fd9cbb022. This identifies the posted manuscript source, not a companion or software-release artifact.

Required v156 release evidenceFor the intended v156 release and numina.pair-binding.v1 companion, keep one release record containing the following evidence. These are acceptance requirements. Section 8 remains the record of checks actually performed.

1. Final scope and payload. Record the exact approved payload and its schema, binding_id, revision, actual issued_at, predecessor, and scope.project_id, scope.release_id, and scope.canonical_source_id values. Identify the immutable v156 source and release candidate; retain v155 as the inspected baseline. Bind the approved attribution map and note into the payload. Record the canonical payload bytes and SHA-256 separately from the serialized envelope bytes and their digest.
2. Pinned artifacts and profiles. Identify each selected artifact by path, version, size, and whole-file digest. Pin each hash_profile_id to the original input selection and normalization implementation, with its version and registry digest. Preserve the two original source commitments and reject an unknown profile or an unexpected registry. These pins must identify the actual release inputs, not merely a planned filename.
3. Signing and independent trust. Record the approved signing service or key reference, raw public key, and recomputed key fingerprint. Retain the independently authenticated trust entry that binds the key to the project, release, canonical source, and signing role. State the key-validity and revocation policy, including the times at which it is evaluated. Retain the actual signature bytes and verification result for the exact message specified in Section 4. Keep private keys out of the release record.
4. Accepted revision evidence. Retain independently authenticated current-state evidence identifying the accepted binding_id, revision, and canonical payload digest. Record the authority, observation time, predecessor linkage, revocation decisions, and checks for stale or conflicting revisions. Record the age of cached evidence when an offline decision uses it. Apply the separate freshness result specified in Section 6.
5. Private mapping and resolution. Retain an authenticated receipt linking the approved opaque genesis_ref through the immutable mapping to the intended private record. Identify the mapping version or immutable mapping identity, the authorized resolver, observation time, and resolution result within the authorized private evidence. Keep private values, record locators, and registry details out of the public package; provide a public-safe result where appropriate.
6. Executed tests and preservation inventories. Retain the complete before-and-after original-evidence inventories, including file identity, size, and digest. Record version-pinned tools and runtimes, commands, fixture versions, exact source snapshots, and results for the applicable v156 validation and the JCS/Ed25519 checks required in Section 8.1 and this appendix. Keep public fixture results separate from authorized private original-artifact verification. Retain the actual outputs supporting every reported result.
7. Version manifest. Provide a manifest relating each released artifact's filename, version, byte count, digest, and role. Distinguish original source commitments, canonical payload digests, envelope-file digests, and new package digests. Relate the manifest to the immutable release and source identifiers. Record the manifest's own digest separately in the release evidence rather than making it self-referential.
8. Release and public-deposit receipts. Record the approved public-safe files and the privacy-review result. For each authorized release or public deposit actually performed, retain its provider or repository receipt, immutable version or deposit identifier, locator, and observation time. Retrieve the deposited files and compare their bytes and digests with the version manifest. Keep a manuscript deposit receipt separate from a v156 software-release receipt. A planned destination or unverified metadata does not establish a completed deposit or byte equality.

For each check, record the exact target, evidence used, observation time, result, and direct reason. Preserve the independent results defined in Section 6; a successful check does not supply evidence for another check. This release record adds no implementation or test result to the manuscript.