An Evidence Preserving Companion Record for the fixed string numina.pair-binding.v1 / Ed25519: A design study of Ed25519; the universal pair binding model.
draft-kott-numina-pair-binding-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Samuel J. Kott | ||
| Last updated | 2026-10-08 (Latest revision 2026-10-07) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kott-numina-pair-binding-01
Network Working Group S. J. Kott
Internet-Draft 8 October 2026
Intended status: Informational
Expires: 11 April 2027
An Evidence Preserving Companion Record for the fixed string
numina.pair-binding.v1 / Ed25519: A design study of Ed25519; the
universal pair binding model.
draft-kott-numina-pair-binding-01
Abstract
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
This note is to be removed before publishing as an RFC.
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.
Kott Expires 11 April 2027 [Page 1]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relation to existing work . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Assumptions and boundaries . . . . . . . . . . . . . . . 4
2.2. Preservation invariants . . . . . . . . . . . . . . . . . 5
3. Record Model and Attribution Example . . . . . . . . . . . . 5
3.1. Frozen source commitments . . . . . . . . . . . . . . . . 6
Kott Expires 11 April 2027 [Page 2]
Internet-Draft Numina Pair-Binding Design Study October 2026
4. Canonical bytes and signature construction . . . . . . . . . 8
5. Independent signing authority . . . . . . . . . . . . . . . . 9
6. Verification and replay resistance . . . . . . . . . . . . . 9
6.1. Verification sequence . . . . . . . . . . . . . . . . . . 10
6.2. Current state and revision history . . . . . . . . . . . 10
7. Private genesis linkage . . . . . . . . . . . . . . . . . . . 11
8. Available evidence and evaluation scope . . . . . . . . . . . 11
8.1. Tests required before an implementation claim . . . . . . 14
9. Public disclosure and release discipline . . . . . . . . . . 14
10. Limitations and open design decisions . . . . . . . . . . . . 15
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Data and artifact availability . . . . . . . . . . . . . . . 16
13. Authorship and disclosure statement . . . . . . . . . . . . . 16
14. Standards and rights notice . . . . . . . . . . . . . . . . . 17
15. Security Considerations . . . . . . . . . . . . . . . . . . . 17
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
17. Normative References . . . . . . . . . . . . . . . . . . . . 17
18. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Chronological project record . . . . . . . . . . . . 19
A.1. 9 September 2026 . . . . . . . . . . . . . . . . . . . . 19
A.2. 10 September 2026 . . . . . . . . . . . . . . . . . . . . 19
A.3. 11 September 2026 . . . . . . . . . . . . . . . . . . . . 19
A.4. 18 and 24 September 2026 . . . . . . . . . . . . . . . . 19
A.5. 1 October 2026 . . . . . . . . . . . . . . . . . . . . . 20
A.6. 5 October 2026 . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Attribution wording and historical checks . . . . . 20
B.1. Person to alias map . . . . . . . . . . . . . . . . . . . 20
B.2. Software attribution note . . . . . . . . . . . . . . . . 21
B.3. Historical reproduction checks . . . . . . . . . . . . . 21
Appendix C. Requirements evidence and acceptance criteria . . . 22
C.1. Required v156 release evidence . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. 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,
Kott Expires 11 April 2027 [Page 3]
Internet-Draft Numina Pair-Binding Design Study October 2026
or a derivation of either commitment from genesis. Each association
remains an assertion whose acceptance depends on a separately
established signer and policy.
1.1. Relation to existing work
Software supply-chain systems such as in-toto organize authenticated
evidence about a development process [4]. DSSE specifies a general
signed-envelope construction with typed payloads [5]. 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.
2. 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.
2.1. 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.
Kott Expires 11 April 2027 [Page 4]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
2.2. 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.
3. 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.
Kott Expires 11 April 2027 [Page 5]
Internet-Draft Numina Pair-Binding Design Study October 2026
+=============+=================================================+
| Component | Required meaning |
+=============+=================================================+
| Record | schema; stable opaque binding_id; positive |
| identity | 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 | genesis_ref is an approved opaque reference. |
| association | 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. |
+-------------+-------------------------------------------------+
Table 1: Private payload components and their roles.
3.1. 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 [6].
1bf43817cf470abb868074a76598cb5f360517d7255b92ab3b409c6b545ec66b
Kott Expires 11 April 2027 [Page 6]
Internet-Draft Numina Pair-Binding Design Study October 2026
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 [6].
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) [9]. 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 [8]. New
manuscripts, payloads, envelopes, and packages receive separate
digests.
Kott Expires 11 April 2027 [Page 7]
Internet-Draft Numina Pair-Binding Design Study October 2026
4. 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 [1]. 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 [3]. 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 [2]. 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.
Kott Expires 11 April 2027 [Page 8]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
5. 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.
6. 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.
Kott Expires 11 April 2027 [Page 9]
Internet-Draft Numina Pair-Binding Design Study October 2026
6.1. 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.
6.2. 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.
Kott Expires 11 April 2027 [Page 10]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
7. 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.
8. 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 [8]. 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) [9]. The original commitments therefore carry over to
those inputs/profile; no fresh test execution is claimed. Appendix B
lists the historical checks.
+=======================+===========================================+
| Exact target and | Evidence and direct reason |
| observation | |
| | |
| Result | |
+=======================+===========================================+
| Historical Source 1 | Audit [8] reproduced both Section 3 |
| and Source 2 at | commitments using the historical inputs/ |
| dc4c1f3 5 Oct 2026 | profile. Six focused assertions and 2/2 |
| 23:57:10.028 UTC | repository tests passed on Node 24.19.0; |
Kott Expires 11 April 2027 [Page 11]
Internet-Draft Numina Pair-Binding Design Study October 2026
| | clean Git status was recorded. These are |
| Result: PASSED | historical results. |
+-----------------------+-------------------------------------------+
| Selected v155 JSON | Receipt [9] compares source |
| inputs and hash | 17cc00cb87647a531f116f0894741005909c359c: |
| profile 6 Oct 2026 | both JSON files and production-pair.mjs |
| 00:50 UTC | lines 1-22 match the historical bytes. |
| | The commitments carry over from identical |
| Result: MATCHED | inputs/profile; this was not a fresh test |
| | run. |
+-----------------------+-------------------------------------------+
| Whole v155 versus | Receipt [9] records 126 added, 220 |
| historical | changed, 1,038 identical, and zero |
| repository 6 Oct | removed tracked entries. The full script |
| 2026 00:50 UTC | differs. Whole-repository equality is |
| | false; the selected artifact/profile |
| Result: DIFFERENT | match is unaffected. |
+-----------------------+-------------------------------------------+
| Operational | No operational companion payload was |
| companion schema No | located in the bounded v155 source |
| validation time | inspection [9] or supplied for this |
| | paper. There is no instance against |
| Result: NOT | which to run strict schema validation. |
| PERFORMED | |
+-----------------------+-------------------------------------------+
| Operational | The approved paper map and note are in |
| companion | Section 3 and Appendix B. No operational |
| attribution map No | payload was supplied, so its people, |
| validation time | note, and personToAlias values cannot be |
| | checked against that approved wording. |
| Result: NOT | |
| PERFORMED | |
+-----------------------+-------------------------------------------+
| Operational | The bounded tracked-source inspection [9] |
| companion signature | located no operational companion/ |
| bytes Source search: | signature, and none was supplied. No |
| 6 Oct 2026, 00:50 | signature bytes are available to verify. |
| UTC | This is not an invalid-signature result; |
| | binary archive contents and inaccessible |
| Result: NOT | records were not exhaustively searched. |
| PERFORMED | |
+-----------------------+-------------------------------------------+
| Independent signer | No independently approved scoped trust |
| trust entry for | entry was provided. The signer's |
| project, release, | authorization, key validity, and |
| source and role Time | revocation status cannot be established |
| not recorded | from an embedded key or a display name. |
| | |
Kott Expires 11 April 2027 [Page 12]
Internet-Draft Numina Pair-Binding Design Study October 2026
| Result: EVIDENCE | |
| UNAVAILABLE | |
+-----------------------+-------------------------------------------+
| Accepted current | No trusted current-revision policy or |
| binding revision and | authenticated current-state record was |
| predecessor state | supplied. The accepted latest revision, |
| Time not recorded | predecessor linkage, and absence of stale |
| | or conflicting revisions cannot be |
| Result: EVIDENCE | established. |
| UNAVAILABLE | |
+-----------------------+-------------------------------------------+
| Private genesis | No authenticated private-resolution |
| reference resolution | evidence is available. The owner's |
| Time not recorded | association statement alone cannot |
| | demonstrate that the reference resolves |
| Result: EVIDENCE | to the intended immutable private record. |
| UNAVAILABLE | |
+-----------------------+-------------------------------------------+
| v156 provider | The provider check recorded in [9] |
| publication record 6 | returned v155 and no v156 record. No |
| Oct 2026 00:50 UTC | returned receipt supports a v156 |
| | publication or source-equality claim as |
| Result: NOT FOUND | of that check. |
+-----------------------+-------------------------------------------+
| Downloaded release- | Receipt [9] states the release archive |
| archive bytes Check: | was not downloaded during the |
| 6 Oct 2026, 00:50 | investigation. Provider metadata alone |
| UTC; no comparison | cannot establish equality of downloaded |
| run | archive bytes. |
| | |
| Result: NOT | |
| PERFORMED | |
+-----------------------+-------------------------------------------+
| New companion cross- | No implemented and executed cross- |
| implementation JCS | implementation conformance suite or |
| and Ed25519 | result record is available. Cited |
| conformance No run | standards, proposed tests, and |
| time | illustrative fixtures are not an executed |
| | conformance result. |
| Result: NOT | |
| PERFORMED | |
+-----------------------+-------------------------------------------+
| Node 26 tests on the | No canonical Node 26 test run is |
| canonical v155 | recorded. Audit [8] used Node 24.19.0 on |
| checkout No run time | the historical checkout; comparison [9] |
| | performed no builds or tests. Neither is |
| Result: NOT | Node 26 execution evidence. |
| PERFORMED | |
Kott Expires 11 April 2027 [Page 13]
Internet-Draft Numina Pair-Binding Design Study October 2026
+-----------------------+-------------------------------------------+
Table 2: 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.
8.1. 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 [8]. 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.
9. 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
Kott Expires 11 April 2027 [Page 14]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
10. 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.
Kott Expires 11 April 2027 [Page 15]
Internet-Draft Numina Pair-Binding Design Study October 2026
11. 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.
12. 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.
13. 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.
Kott Expires 11 April 2027 [Page 16]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
14. Standards and rights notice
The IETF Trust's corrected legal provisions describe rights
applicable to covered RFC material [7]. 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.
15. 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.
16. 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.
17. Normative References
Kott Expires 11 April 2027 [Page 17]
Internet-Draft Numina Pair-Binding Design Study October 2026
[1] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785.html>.
Informational.
[2] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032.html>.
Informational.
[3] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/rfc/rfc7493.html>.
18. Informative References
[4] Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola,
R., and J. Cappos, "in-toto: Providing farm-to-table
guarantees for bits and bytes", 2019,
<https://www.usenix.org/conference/usenixsecurity19/
presentation/torres-arias>. Proceedings of the 28th
USENIX Security Symposium, pp. 1393-1410.
[5] Secure Systems Lab, "DSSE Protocol", Version 1.0.2, 10 May
2024, <https://github.com/secure-systems-
lab/dsse/blob/master/protocol.md>. Protocol
specification. Accessed 5 October 2026.
[6] Numina, "Universal pair binding design", Version 5, 5
October 2026. Unpublished project design record.
Approved commitments and descriptive attribution are
summarized in this manuscript; the underlying private
evidence is not a public dataset.
[7] IETF Trust, "Corrected Legal Provisions Relating to IETF
Documents", Version 5.0, 25 March 2015,
<https://trustee.ietf.org/documents/trust-legal-
provisions/tlp-5/>. Effective 25 March 2015; terminology
corrected 21 September 2021.
[8] Numina, "Historical source commitment audit, historical-
audit-2026-10-05.json", 5 October 2026. Read-only run
captured 5 October 2026 at 23:57:10.028 UTC, historical
HEAD dc4c1f38340340609f66bc2ae7bf425427d4b864. Sanitized
technical audit record; public deposition pending.
Kott Expires 11 April 2027 [Page 18]
Internet-Draft Numina Pair-Binding Design Study October 2026
[9] Numina, "Canonical v155 source comparison", 6 October
2026. Read-only receipt canonical-v155-comparison-
20261006.json, 6 October 2026, 00:50 UTC. Selected
artifacts and hash profile.
Appendix A. Chronological project record
The project design record [6] 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.
A.1. 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.
A.2. 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.
A.3. 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.
A.4. 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.
Kott Expires 11 April 2027 [Page 19]
Internet-Draft Numina Pair-Binding Design Study October 2026
A.5. 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.
A.6. 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 [8].
A 6 October 00:50 UTC comparison subsequently established selected
v155 input/profile equality [9].
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.
Appendix B. 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.
B.1. Person to alias map
personToAlias: {"Sam Kott": "UNIVERSAL_PAIR_2", "Lauren Anderson":
"UNIVERSAL_PAIR_1"}
Kott Expires 11 April 2027 [Page 20]
Internet-Draft Numina Pair-Binding Design Study October 2026
B.2. 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.
B.3. Historical reproduction checks
The read-only audit [8] 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.
Kott Expires 11 April 2027 [Page 21]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
Appendix C. 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 | Approved byline, | Bind the approved map into |
| attribution | names, exact short- | the actual companion |
| | label note, and | payload. Check Source 1 / |
| | personToAlias map | UNIVERSAL_PAIR_1 / 1B / |
| | are preserved. | 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 | Historical hash | Retain the receipt. Under |
| integrity | reproduction | independent policy, pin the |
| | passed; selected | snapshot, paths, whole-file |
| | v155 JSON inputs | digests, profile |
| | and hash-profile | implementation, and approved |
| | bytes are identical | registry digest; reject |
| | [9]. | 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 |
Kott Expires 11 April 2027 [Page 22]
Internet-Draft Numina Pair-Binding Design Study October 2026
| | | its own check; keep private |
| | | inputs private. |
+-------------+---------------------+------------------------------+
| Signed | The construction is | Approve exact payload, |
| statements | specified; no | project/release/role scope, |
| | operational signed | a real signer, an |
| | companion was | independent trust entry, and |
| | located or | a current-revision policy. |
| | supplied, and | Acceptance requires |
| | signer trust is | separately successful |
| | unestablished. | signature, authorization, |
| | | scope, and freshness checks. |
| | | Null remains pending; |
| | | malformed or failing |
| | | signatures are invalid. |
+-------------+---------------------+------------------------------+
| JCS | RFC 8785 applies to | Run RFC vectors and |
| | the new companion. | independent canonicalizer |
| | The historical | agreement on public |
| | source normalizer | fixtures, including integer |
| | is not general JCS. | 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 | Test RFC vectors and |
| | message framing and | synthetic positive/negative |
| | raw key/signature | cases for the exact prefix, |
| | sizes are | NUL separator, payload, |
| | specified; no | encoding, and variant. |
| | operational key or | Acceptance requires correct |
| | signature is | verification behavior plus a |
| | supplied. | real approved signature for |
| | | any operational claim. A |
| | | test key cannot become |
| | | production signing |
| | | authority. |
+-------------+---------------------+------------------------------+
| Provenance | Chronological Git/ | Keep software history, |
| | file events and the | manuscript build records, |
| | historical rerun | public fixture results, and |
| | are identified; | private original |
| | manuscript | verification distinct. |
| | authorship is a | Acceptance requires version- |
Kott Expires 11 April 2027 [Page 23]
Internet-Draft Numina Pair-Binding Design Study October 2026
| | self-identification | pinned sources, commands/ |
| | statement. | 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. |
+-------------+---------------------+------------------------------+
Table 3
Revision 00 RFCXML provenance: the archived source at
https://www.ietf.org/archive/id/draft-kott-numina-pair-binding-00.xml
contains 61,416 bytes and has SHA-256
5bc15dab8c6f992bb179536beaf1ba3b61673ff37eba2dd043d9f27fd9cbb022.
This identifies the posted manuscript source, not a companion or
software-release artifact.
C.1. Required v156 release evidence
For 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.
Kott Expires 11 April 2027 [Page 24]
Internet-Draft Numina Pair-Binding Design Study October 2026
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
Kott Expires 11 April 2027 [Page 25]
Internet-Draft Numina Pair-Binding Design Study October 2026
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.
Author's Address
Samuel J. Kott
Email: skott34@gmail.com
Kott Expires 11 April 2027 [Page 26]