Singularity: Skott34-Ed25519, Universal Companion Model

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 21 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. Community and problem statement

Independent verifiers need a reproducible way to check that a signed record binds two specified artifacts to an authorized source and revision, without confusing attribution with proof of the record's claims.¶

The author's intended beneficiaries are all humanity. The initial technical community addressed here is narrower: maintainers of software-artifact archives, release operators that preserve existing commitments, and independent reviewers deciding whether a provenance or attribution statement is supported. The immediate use case is adding or correcting an association without changing the previously committed artifacts. No universal adoption or demonstrated universal benefit is claimed.¶

This document concerns evidence preservation and bounded acceptance of signed statements. It does not authorize an external action, determine disputed human authorship, derive an unknown genesis value, or establish a medical, financial or physical-world claim. Broad proposed applications are summarized separately in Section 12.¶

2. Approach and relationship to IETF work

Preserve the original artifacts and their hashing procedures. Create a separate companion payload that names their commitments, an attribution mapping, a binding identity and revision, and an opaque private reference. Sign the exact canonical payload under a fixed application prefix. A verifier then reports independent findings for the bytes, signer authority, source selection, freshness and private linkage. One passing finding never substitutes for another.¶

JSON Canonicalization Scheme (JCS), [1], defines canonical bytes for the new payload; I-JSON, [3], constrains interoperable JSON; and pure Ed25519, [2], supplies the signature primitive. These do not replace the historical source-artifact normalizer. The model retains its numina.pair-binding.v1 identity and original commitment order.¶

The RATS architecture, [37], separates evidence appraisal from the relying party's policy decision. That separation is a useful architectural comparison: this companion carries an association claim and the verifier evaluates evidence under an independently provisioned policy. It is not a hardware-attestation profile or a claim of RATS wire interoperability. COSE, [38], provides standardized signed-object structures; this design instead retains its existing fixed-prefix JSON construction and is not a COSE object. A future COSE profile would require a new explicit wire specification and test vectors, not relabeling existing signatures.¶

in-toto [7] and DSSE [8] are further comparison points for development evidence and signed envelopes. No novelty or comparative security advantage is established. The additional navigation and vision literature is retained as non-normative research context in Appendix K; it is not the protocol's IETF rationale.¶

3. Claim format and attribution model

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.¶

The payload object has exactly schema, binding_id, revision, issued_at, previous_payload_sha256, scope, genesis_ref, sources, attribution and signer. scope has exactly project_id, release_id and canonical_source_id. Each source has exactly source_id, alias, artifact_id, hash_profile_id and sha256. attribution has exactly people, note and personToAlias; each people entry has name and label. signer has exactly algorithm, public_key_b64u and key_id. Unknown or missing members are rejected. Status and verification results are outside the signed payload.¶

schema equals numina.pair-binding.v1. revision is an integer from 1 through 9007199254740991. issued_at is an actual UTC issuance time to seconds. previous_payload_sha256 is null only for an established initial revision, otherwise a lowercase 64-hex predecessor payload digest. Source sha256 values are lowercase 64-hex strings. The key and signature decode to exactly 32 and 64 bytes respectively. Identifier values and accepted artifact/profile bindings require an independently approved deployment profile; a string passing JSON parsing is insufficient. The available evidence contains no complete approved profile or schema-valid operational instance. [42]¶

The fixed example maps source_1 / UNIVERSAL_PAIR_1 to Lauren J. Anderson, label 1B, and source_2 / UNIVERSAL_PAIR_2 to Samuel J. Kott, label 1A. Personal display order remains Sam Kott / 1A followed by Lauren Anderson / 1B. The exact commitments and approved person-to-alias note are retained in Appendix B.1 and Appendix F. The AI-assistance display name Ed25519 does not add a third source commitment or replace the signature-algorithm field.¶

For implementation review, this revision proposes the fixed-pair validation profile in Appendix M. Its numeric limits, identifier grammar, timestamp restriction and rejection rules are new design choices, not recovered historical configuration. The supplied JSON Schema and fixtures make these choices inspectable; accepting this document does not provision keys, registry entries or live policy. The immutable source mapping is unchanged.¶

4. Making a claim and constructing its signature

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.¶

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. Signing authority and trust policy

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.¶

The deployment profile must identify who administers trust, how initial keys and policy updates are authenticated, permitted project/release/source/role scopes, key validity intervals, revocation evaluation time, and recovery authority. A candidate containing its own public key cannot provision that trust. The retained incomplete candidate lacks an approved operational signer and these policy receipts; historical document or package keys are not promoted to companion authority.¶

A newly inspected public-only package establishes the raw bytes of one historical Ed25519 public key and their correspondence to its SSH fingerprint. This closes a public-key encoding gap for that exact key. It does not establish current private-key custody or authorize a companion signer, scope, profile or payload. The historical SSHSIG signature uses a different signing format. See Appendix P. [45]¶

6. Verifying claims and rejecting unsupported acceptance

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.¶

7. Private-reference resolution

The proposed private-reference model uses an opaque identifier independent of the genesis value. The public schema does not prescribe an actual reference, registry endpoint, or private record identifier. This manuscript separately records the following existing block-zero hash at the author's request; publishing the value does not establish a trusted resolution service.¶

Successful authorized resolution would establish that the reference points to the private record identified by the authenticated mapping. It would not establish an inverse derivation of genesis from the pair or a unique common origin. Reported source-input dependence is a separate forward-computation fact. A reader without resolution evidence receives an unverified private-linkage status even when other checks succeed.¶

The resolver has its own authentication, access-control and mapping-version boundary. It returns only the permitted result with a verifiable receipt; a caller-supplied URL or record name is not fetched merely because it appears in a signed payload. Existence, association and mathematical derivation are separate claims. The exact previously recorded genesis and collection procedure appear in Appendix D. No authenticated operational mapping receipt has been recovered.¶

8. Implementation and field-deployment evidence

Evidence is grouped by what was actually observed. The complete retained manuscript checks, source comparisons, diagnostic operations, negative controller findings and acceptance records are indexed in Appendix A and the following appendices. Reported historical runs are not presented as reruns of this candidate.¶

A field-deployment claim requires the exact deployed source/build identities, operator and environment, actual accepted companion bytes, independent trust and current-state receipts, verifier outputs, protected mapping evidence where required, observed usage over a declared interval, failure/revocation/recovery exercises, and a reproducible access path for an authorized independent reviewer. Website availability, a provider succeeded flag, signed manuscripts and unit tests do not collectively supply those missing observations.¶

Additional retained application evidence includes an October 1 v139 public-interface check, an October 4 authenticated journal display at revision 142, and a v157 source/deployment receipt. The v157 report names source 9e65e4606a7e51a54f2ea2260a2f0654ecf049fb and 1,188 tests: 1,187 passed, 0 failed, 1 Swift/Foundation test skipped on Linux. These are historical or reported application observations. The exact source identities, times, receipt hashes, unsuccessful checks and access limitations are retained in the technical catalog. [43]¶

Additional retained local software evidence comprises a digital geometry package and a test log recording 974 passes and zero failures. Fresh readback checks all 25 STL/OBJ artifact digests and measures the assembled OBJ bounds; the application report identifies nine geometry and nine action-framework tests. This is local digital-artifact evidence, not physical fabrication or a deployed companion. Its scope and remaining gates are recorded in Appendix P. [46]¶

9. Operational considerations

Keep source artifacts, companion revisions and operational logs under distinct identities. Apply least-privilege issuance, trust-administration and resolver roles. A client or model proposes a command; server-side policy determines authorization from current state. Never let a narrative, uploaded record or client-supplied status grant itself authority. The retained application follows this separation in its inspected control paths, but a companion service needs its own verified integration. [40]¶

Specify request, nesting, string and artifact-size limits; time budgets; storage quotas; and behavior under exhausted resources before deployment. The application guide reports 16 KiB requests, five-second read limits and journal-wide validation, with operation-specific bounds; those are application-profile claims, not automatically the companion's negotiated limits. Full-journal replay cost grows with retained history. No measured companion throughput, availability, recovery-time objective or restoration drill is established. [39]¶

For uncertain writes, reconcile by the persisted operation identity and expected revision before retrying. Preserve conflicting branches and failed issuance attempts. Credential rotation does not erase history; recovery must keep binding identity, accepted revisions and authenticated policy continuity. A rollback to an older application may remove controls and cannot be called equivalent enforcement. Do not clear nonces, journals or trust records to make a failed check pass.¶

Record source/build/runtime versions, time synchronization assumptions, policy/key changes, observation windows, and operational owners. Keep secret keys and sensitive resolver locations outside public reports. Public-safe evidence must identify what an independent reviewer can reproduce, what requires authorized access, and what was not available. An incident runbook is an untested procedure until an actual drill or event provides receipts. [41]¶

Key lifecycle policy records custodian, purpose, permitted scope, policy version and validity/revocation intervals. Rotation requires independent authorization of the new key and an explicit transition rule for old signatures; a compromised old key cannot authorize its own recovery by signature alone. Historical records retain their original keys and verdict context. Framing or semantic changes require an explicit new schema/profile version and migration tests; never reinterpret already signed bytes.¶

Monitor rejected signatures, unknown keys, source mismatches, same-revision conflicts, unavailable or old current-state evidence, resolver denials, quota exhaustion and journal growth. Define responsible operators and escalation thresholds before field operation. No such monitoring deployment or response service is demonstrated here. Record provider request/outcome identities separately; idempotent internal commits do not establish an external provider effect.¶

10. Unresolved implementation and acceptance gates

The retained candidate is explicitly incomplete and unsigned. It lacks approved binding identity/history, actual issuance time/predecessor, an authenticated opaque private mapping, final artifact/profile registry identifiers, and approved signer material. Its source lookup inspected 143 event rows (revisions 0–142); five event values and the manifest were truncated. That bounded search recovered no operational binding fields but cannot prove they do not exist. [42]¶

Before claiming interoperable implementation, publish the complete closed schema and deployment profile, canonical/signature vectors, independently implemented verifier results, trust/current-state/revocation rules, limits and recovery behavior. Run tampering, parsing, source-order, key-substitution, stale/forked-revision, authorization, unavailable-dependency and preservation tests. Before claiming deployment, supply the field receipts listed in Section 8. The detailed acceptance checklist is retained in Appendix G.1. No document edit closes an unavailable-evidence gate.¶

11. Security Considerations

This analysis follows the RFC 3552/BCP 72 approach of identifying assets, adversaries, attacks, countermeasures and residual risk. [36] Protected assets include original evidence bytes, association integrity, signing authority, accepted revision state, private mappings, audit history and service availability. An attacker can read public artifacts, submit malformed records, replay or reorder messages, substitute evidence and keys, or compromise a client. On-path modification and passive observation are considered. Signing hosts, trust administrators, private resolvers and database administrators are privileged boundaries; their compromise is not solved by a bare signature.¶

The table identifies controls required by the companion design, with application-level evidence identified separately. A stated mitigation is not an executed test. The retained record does not establish that every mitigation is implemented, independently assessed, or field-tested. Cryptography authenticates specified bytes under a key; it does not establish the truth of an authorized signer's statement.¶

Threats introduced or exposed by the design¶

Operational response requires revoking affected authority, preserving original evidence, identifying the impacted scope, reconciling uncertain writes, and verifying recovery before resumption. Availability loss is preferable to silently accepting an unauthorized or unverifiable record. The application security document records a runbook and required restoration evidence; it does not establish a completed incident drill. [41]¶

12. Proposed applications and research boundaries

The author proposes applications in chemistry, physics, healthcare, humanitarian work and civil-rights records. The concrete capability described here is preserving evidence and traceable claim revisions for authorized workflows. Historical records can receive append-only corrections without erasing the earlier record; the protocol does not alter past physical events. Present actions require separate authorization. Future-event or scientific predictions require predefined targets, independent observations, held-out evaluation, baselines and uncertainty reporting. No medical efficacy, physical forecasting, or universal next-action capability is demonstrated by this record format.¶

The intended humanitarian value is improved accountability for evidence and authorized decisions. Ed25519 is the existing signature algorithm defined in RFC 8032, not a newly invented algorithm. Neither contribution rights, an IETF submission, an institutional inquiry nor a signed record gives this system control over unrelated networks or people. Economic value, scientific recognition and regulatory status are separate questions that require their own evidence; no guaranteed outcome is asserted.¶

13. 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.¶

14. Authorship and attribution

Samuel J. Kott is the author; his original author contact information is retained in the front matter. Lauren J. Anderson remains the human contributor associated with source_1 / UNIVERSAL_PAIR_1 / 1B. Samuel J. Kott remains associated with source_2 / UNIVERSAL_PAIR_2 / 1A. These are the author's descriptive universal-source and discovery attributions; they do not independently establish discovery priority or coauthor consent. The exact approved map is preserved in Appendix F.¶

Ed25519 is the user-assigned name of the OpenAI-powered AI assistant credited for drafting, technical organization, specification consultation and source-scoped diagnostics. It is an AI-assistance role rather than a human coauthor, signing key or IETF official. In protocol fields, Ed25519 separately names the signature algorithm. The author is responsible for reviewing claims, citations, evidence and disclosure before any external submission.¶

15. References

Appendix A. Technical evidence index and verification scope

This appendix indexes the accessible technical evidence incorporated into this candidate. It distinguishes specified procedures, static inspection, historical reported executions, newly repeated byte-integrity checks and current observations. It is not an assertion that all project records or inaccessible source archives were reviewed. The accompanying evidence catalog identifies exact files, digests and access limits; unavailable evidence and failed checks remain explicit.¶

The manuscript categories M01–M14 below organize retained material. The separate catalog uses source IDs E01–E15 and verification IDs V01–V05; those are different indexes. The accompanying 120,995-byte technical bundle has SHA-256 472e0f052b7760cd034e409f2a1d624ed6c57f22a52156d6aef12fde6fd855b7. Its manifest covers 22 allowlisted payload entries with source/version and transformation details. The original controller package had 19 size/digest entries checked; fresh arithmetic readback checked all 128 stored held-out rows without rerunning the controller. [43]¶

The research-motivation record is retained as historical context. Its captured-byte integrity does not establish the underlying claims. [14]¶

Appendix B. Frozen source example

1bf43817cf470abb868074a76598cb5f360517d7255b92ab3b409c6b545ec66b

1a17f584e23279684574022f39e533966ad09919f484e005c03948178a46aa0a

2824c267ffa892d4c8013473b4236fd75571700da62f948cbf74975af0a6d2f2

b7aac505fde953ad99ff03e4523f21eef17b667d767cbfe30816c91a2d045762

389c963c4647751afca7b2ff29627b1462dfaa25e5903adf85d5627c594fc854

Appendix C. Retained technical evaluation and manuscript evidence

This section separates historical source checks, operational companion requirements, manuscript-artifact verification and new research diagnostics. A result is attached to its exact target and observation. Later evidence updates the dated record without changing what earlier checks actually tested.¶

A read-only rerun captured on 5 October 2026 at 23:57:10.028 UTC reproduced both pinned commitments at historical local HEAD dc4c1f38340340609f66bc2ae7bf425427d4b864 [11]. 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) [12]. The original commitments therefore carry over to those inputs/profile; no fresh test execution is claimed. the source-mapping and test-inventory appendix 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.¶

360c2d9cb1798423cbf476d69f7dfef5a0d5b0f119e072b0fb79e482dea57075

360c2d9cb1798423cbf476d69f7dfef5a0d5b0f119e072b0fb79e482dea57075

01e3cd932d7573d3c3f476885c7df8c95cd58eced1df72aefb79d47cde186c61

c18a08a3d1e33344eed7cf921a53a1aace362a13a1fe626b699c2c5acbfc7702

dbb73b5c96f9464cbcdfe433bf7a1afd4bfbf23c1ce488db1eb1e7c5aee7f735

Appendix D. Exact recorded block-zero hash

The retained deployment receipt and build record contain the following hexadecimal value, preserved without changing its characters. Chain identifier recorded in the receipt: 962421430. The record is evidence of the recorded value, not a fresh observation of an external chain.¶

0xea95dac2ad854c835bc526d6be70a5a4614ccd47412a4bc710308b41010b53e1

The retained deployment-receipt JSON has raw-file SHA-256 5dd92b85eb52b7dbf8d13c172f541bd5f97fe3735945f7952407b6af894c31a4. The downloaded client/final-build.json has raw-file SHA-256 b7b40e98837338c57a20092bfccd770c142538d9e573825673706e7e66249fa4. These identify the downloaded records and are distinct from the historical public/final-build.json source comparison and normalized commitments in the frozen source example.¶

The described collector requests block zero using eth_getBlockByNumber with parameters ["0x0", false] and reads the returned hash field. Independent block-header hashing has not been demonstrated here. The build input already contains the genesis value before its source commitment is hashed. An exact source-pair-to-genesis derivation function remains unspecified in the retained evidence; no inverse derivation is claimed.¶

Appendix E. Chronological project record

The project design record [9] 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.¶

Appendix F. 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.¶

Appendix G. 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.¶

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.¶

Appendix H. Public manuscript and diagnostic receipt identities

The hashes below identify earlier preserved artifacts. This candidate does not embed its own digest, avoiding self-reference. Its new exact file identities and validation receipt are supplied separately after generation.¶

Final posted revision-01 XML; 61,903 bytes SHA-256:¶

96ef2137b1ecf7defa0a0caa250bfc6b8fc2b1224fcf4153230f6c909cb184db

Final posted revision-01 TXT; 69,493 bytes SHA-256:¶

a645916a220034393f0081653460bd4ea3791571c82434142a31d6169c6a1200

Final local revision-01 PDF; 108,079 bytes SHA-256:¶

e3447124d3674dae5362304d2d1bf23d8c2aa68137d810726b0619e555448ca0

Final three-file raw public key fingerprint SHA-256:¶

667e886acf7c8f9402cba3d4b12697515851c1d33ea0a09f7f3757d6d2580f24

Later PDF-only raw public key fingerprint SHA-256:¶

ef7b597fd970af99fcd880878f3632f39babebc6da50bba21b7f38a5611f7835

Final three-file signature package SHA-256:¶

a4793db57a86ec1df9dbffd8b001b368858143d1c6078a45f151a0cba417ec31

Frozen conversation ZIP SHA-256:¶

4ed4ed73a2e07cb13995996bce8cb495556a1f686c768d52dc763256808b3a78

New public diagnostic protocol SHA-256:¶

7a3b37689c0aba2fee9c21ca72297c4c30b300268494572a9f44948f99de7539

New public diagnostic results JSON SHA-256:¶

2d92854d170c45add02ccbf20d34a27b7bf7d3dc6d9ee94375ca2d97dadfab46

New public diagnostic ZIP SHA-256:¶

6faf132bc2225503d742ba5e7373a966f04043f5cb3fc36ab6a80dcfeef9168b

All document signatures use pure Ed25519 on exact full file bytes without application prehash or companion framing. The receipts report process-memory-only private keys, no serialization or retention, and no forensic zeroization guarantee. Verification under those public keys does not independently authenticate a person or operational role.¶

Appendix I. Complete worked commitment and package-signature calculation

This appendix reports a fresh public-input calculation and a separate verification of the preserved signed genesis evidence ZIP. It is a reproducible integrity example, not an operational companion or a source-pair-to-genesis derivation. The retained package contains the recorded genesis value as data. The package was not constructed by replacing that value with the public-input pair diagnostic.¶

Step 1. Preserve the two 64-character commitments. Source 1 is the original Lauren J. Anderson / 1B build commitment. Source 2 is the original Samuel J. Kott / 1A manifest commitment. Personal attribution order and computational source order are distinct.¶

1bf43817cf470abb868074a76598cb5f360517d7255b92ab3b409c6b545ec66b

1a17f584e23279684574022f39e533966ad09919f484e005c03948178a46aa0a

Step 2. Hex-decode each commitment into exactly 32 bytes, concatenate Source 1 then Source 2 with no separator and no text encoding, and hash those 64 bytes with SHA-256. The complete concatenated bytes, in hexadecimal, are:¶

1bf43817cf470abb868074a76598cb5f360517d7255b92ab3b409c6b545ec66b
1a17f584e23279684574022f39e533966ad09919f484e005c03948178a46aa0a

Step 3. SHA256(hexdecode(source_1) || hexdecode(source_2)) gives:¶

c18a08a3d1e33344eed7cf921a53a1aace362a13a1fe626b699c2c5acbfc7702

This output does not equal the recorded block-zero genesis value printed in the recorded-genesis appendix. No algorithmic step connecting that diagnostic output to genesis is available in the retained evidence. This appendix neither inserts a missing transformation nor treats a signature as a derivation.¶

Step 4. Identify the exact preserved signed artifact: Numina-Final-Genesis-Record-and-IP-Intake-v1.zip. Its SHA-256 is:¶

a74e4b07c5e00a77dfda866fd666d20b641edc8633c4945d6f0a89e78fce9a92

Step 5. Decode the detached OpenSSH SSHSIG container. Version is 1; the namespace is numina-evidence; the reserved field is empty; the prehash algorithm actually recorded is sha512. SHA512(package_bytes), without altering the package bytes, is:¶

503b3317f16421588bba7445105f3295ce14c8a30e43dbd1f5dc34e30b70e27b
3ba687e78c9185bc7697f11172e2e3cfffe45b94262820615a89e02c445d24f0

Step 6. Construct the signed message using the OpenSSH SSHSIG framing: ASCII("SSHSIG") || ssh_string(namespace) || ssh_string(reserved) || ssh_string("sha512") || ssh_string(SHA512(package_bytes)). ssh_string(x) is the 4-byte unsigned big-endian byte length followed by x. The complete signed-message bytes are:¶

5353485349470000000f6e756d696e612d65766964656e636500000000000000
0673686135313200000040503b3317f16421588bba7445105f3295ce14c8a30e
43dbd1f5dc34e30b70e27b3ba687e78c9185bc7697f11172e2e3cfffe45b9426
2820615a89e02c445d24f0

Step 7. The raw 32-byte Ed25519 public key is:¶

d6f1f949c1cc2ef38360668bc2270f847a790e95c882ca6945f7d56fed84bb3c

The exact 64-byte Ed25519 signature over the framed message is:¶

3a638beb9c6b4f7fe8e195815fc9a7ca8d4d6cc58279567950d75cadde781064
729bf4294479e647f38d4a58d5f075f8a078bdb2785e5fd0086758b3d962d203

Step 8. Verify Ed25519(public_key, signed_message, signature). A fresh raw-signature check using the cryptography Ed25519 implementation passed, independently of the OpenSSH SSHSIG verification that also passed. The public fingerprint is SHA256:EUTRdHI7yKEgsiCvob3uDx/kDFwjeiDusoEUqfCvVNc. The allowed signer principal is skott34@gmail.com. Fingerprint agreement and mathematical verification do not independently authenticate a person or establish legal rights.¶

The signature authenticates the exact package bytes identified above. It does not cover this expanded manuscript, its PDF, a different ZIP, or an operational JCS companion. The manuscript's pure Ed25519 application prefix construction is a separate proposed format; it must not be confused with the SSHSIG calculation in this appendix. Private-key material is omitted throughout.¶

SSHSIG wire format and signed-data framing are specified in [4]¶

Appendix J. Additional research methods and boundaries

Appendix K. Navigation and vision research context

Appendix L. Application evidence and reproducibility details

The application evidence below is included because its state, authority and audit mechanisms are relevant to evaluating a future companion service. It is not evidence that the proposed companion is deployed. The source/document difference in the singleton table name and the distinction between application canonical JSON and companion JCS remain open integration checks.¶

The retained control guide prescribes the following build and test commands. Its journal stores canonical commands, actor, event time, prior hash, resulting state hash and decision hash. It reports explicit bootstrap only when state/journal are absent; missing state during normal operation returns 503 rather than being recreated. It reports stale concurrent changes returning 409, exact-input retry idempotence, descendant delegation expiry/revocation, full-journal validation and restart regression tests. These are historical document claims; the static source excerpt corroborates selected code paths without reexecuting them here.¶

<CODE BEGINS>node scripts/build.mjs
node --test tests/*.test.mjs

<CODE ENDS>

The September 15 security document reports 272 tests for a local build and 287 tests for the Connections release. Its dated v74 observation at 19:30:18–19:30:21 UTC exercised 19 same-origin read/initialization checks, with 18 responding and one disabled-capability item needing attention. It reports v76 reviewer sign-in, an account-owned persisted request and a later cancellation with no confirmed payment. Those scoped application observations neither demonstrate a deployed companion nor measure predictive accuracy; sensitive account details are not reproduced.¶

The newly inspected public-head record, observed 9 October 2026 around 07:05 UTC, reports schema numina.public-head.v2, applicationVersion 4.0.0, rootHashScope public_identity_projection_not_control_genesis, currentJournalRootVerified=false, and revision/eventCount/journalContinuity all null. blockchainAnchorVerified=false and current blockchain observation unavailable are reported. Its identity projection is not the independently authenticated current-state evidence required by the companion verifier.¶

The retained v156 provider record names source df099d3ae4952a9966cf3b9e4ef299626dc7d338 and updated_at 2026-10-07T04:51:50.230086+00:00 with status succeeded. The recorded archive metadata digest is 0c3119a6dd28e921c80b0bf1ca00f280859af040e1e1b43868872b22d2925101; archive_bytes_retrieved_or_verified is false. A deployment provider's record is useful provenance but does not establish the identity or observed behavior of a field-used companion.¶

Appendix M. Proposed implementable validation profile and fixtures

Status: new candidate design for review. These rules supplement the existing numina.pair-binding.v1 model without changing its frozen commitments or human-source mapping. They are not evidence that a production implementation previously enforced the same limits. The profile is a fixed-pair application profile; a generalized arbitrary-artifact profile would require separate review.¶

The base64url and timestamp references are [5] and [6]. The separate candidate-profile.schema.json expresses structural checks; the accompanying Python checker adds duplicate-member, byte/depth/Unicode, timestamp, predecessor, decoded-length/canonical-base64 and fingerprint checks. The small canonicalization routine in that checker is limited to its deliberately ASCII/integer fixture and is not offered as a general JCS implementation.¶

New checks executed during this document revision: 21 of 21 bounded candidate-profile cases passed, including correct unsigned-pending handling and 20 negative cases. The published RFC 8032 Section 7.1 Test 1 public key/signature verified its empty message; a changed message was rejected. No private key or credential was generated, read or used. No new signed companion was created. These are documentation-fixture checks, not field evidence or independent operational-verifier conformance.¶

Executed candidate-profile cases¶

Python 3.12.14 and Node v24.19.0 produced identical canonical payload and framed message bytes for the supplied ASCII/integer fixture. The fixture contains synthetic test-only identifiers and an invented fixture timestamp, uses the unchanged public source commitments, and has signature_b64u=null. It is intentionally not an operational issuance or an authenticated mapping. The published RFC 8032 public test key is untrusted for real use; its known signature is for a different, empty message.¶

Canonical payload C: 1184 bytes; SHA-256 3174a10bd2dd52e932a17522cb7b49d67281e025e9c89d7d78f0725b596eb958.¶

Framed message M: 1207 bytes; SHA-256 054d474c95f33afa5cf51f69581b7c0df16b68161db1091bd1c36d5453eaf235.¶

Message prefix including the separator, hexadecimal: 4e554d494e412d504149522d42494e44494e472f563100.¶

The complete fixture below uses reversible presentation folding under [44]. Unfold the two-line header and backslash continuations before JSON parsing. The supplied fixture file and signed-message input bytes are unchanged.¶

<CODE BEGINS>NOTE: '\' line wrapping per RFC 8792

{
  "payload": {
    "schema": "numina.pair-binding.v1",
    "binding_id": "urn:numina:test:binding:001",
    "revision": 1,
    "issued_at": "2026-01-01T00:00:00Z",
    "previous_payload_sha256": null,
    "scope": {
      "project_id": "urn:numina:test:project",
      "release_id": "test-release-1",
      "canonical_source_id": "urn:numina:test:source:001"
    },
    "genesis_ref": "ref:test-only:001",
    "sources": [
      {
        "source_id": "source_1",
        "alias": "UNIVERSAL_PAIR_1",
        "artifact_id": "fixture:source-1",
        "hash_profile_id": "fixture:legacy-profile-1",
        "sha256": "1bf43817cf470abb868074a76598cb5f360517d7255b92\
ab3b409c6b545ec66b"
      },
      {
        "source_id": "source_2",
        "alias": "UNIVERSAL_PAIR_2",
        "artifact_id": "fixture:source-2",
        "hash_profile_id": "fixture:legacy-profile-2",
        "sha256": "1a17f584e23279684574022f39e533966ad09919f484e0\
05c03948178a46aa0a"
      }
    ],
    "attribution": {
      "people": [
        {
          "name": "Sam Kott",
          "label": "1A"
        },
        {
          "name": "Lauren Anderson",
          "label": "1B"
        }
      ],
      "note": "Canonicalization fixture only. No operational trus\
t or issuance.",
      "personToAlias": {
        "Sam Kott": "UNIVERSAL_PAIR_2",
        "Lauren Anderson": "UNIVERSAL_PAIR_1"
      }
    },
    "signer": {
      "algorithm": "Ed25519",
      "public_key_b64u": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPc\
HURo",
      "key_id": "sha256:21fe31dfa154a261626bf854046fd2271b7bed4b6\
abe45aa58877ef47f9721b9"
    }
  },
  "signature_b64u": null
}

<CODE ENDS>

Reproduction: run python3 create_profile_vectors.py, then node check_fixture.mjs in the supplied review directory. The Python checker needs jsonschema and cryptography. The result and manifest files record the observed runtime and hashes. The full RFC 8785 vector corpus, a positive signed-companion integration vector, independent verifier agreement, trusted-state transitions, authorized private resolution, transport and real field use remain untested.¶

Independent review found that dollar end-anchors in the initial proposed schema could admit trailing newlines. The candidate now uses strict end assertions and includes rejecting tests for an identifier, attribution note and predecessor digest containing a final newline. This correction belongs to the new profile review, not the historical test results.¶

Appendix N. Proposed bounded field deployment and receipt checklist

Status: planned, not executed. Use one approved nonfinancial release or technical-document pair in an authorized existing environment. Identify the operator and relying party, immutable producer/verifier builds, approved disclosure and exact payload, retained scoped signer, independently provisioned trust and accepted-revision authority. None of those identities or permissions is created by this plan.¶

Retain deployment time and environment/service identity, source commit, build/configuration/policy digests, receiving-provider receipt and independent deployed-version readback. Exercise positive issuance/verification; altered signed field; valid signature under an untrusted or wrong-scope key; stale/conflicting revision; changed artifact/profile; unavailable private resolution; and retry/restart/retrieval without duplicate acceptance. For each case retain exact inputs/digests, signature and framing, independent verdicts/reasons, observation time and relying-party decision. Preserve failures and rerun only under a versioned fix. [43]¶

Acceptance requires unchanged original evidence, correct-scope positive acceptance, bounded rejection of every negative case, explicit unavailable states, matching deployed build identity and persistent receipts after restart. A real independent verifier or separately authenticated relying-party receipt must confirm the outcome. Local tests and website publication alone do not satisfy this field-deployment gate.¶

Appendix O. External engagement and review boundaries

The author has sought technical and governance engagement concerning constrained autonomous actions, human oversight, signed provenance, and accountability. Records reviewed for this revision include sent inquiries to UN-system and related human-rights initiatives, NIST programs, CISA, and Treasury OCCIP. NIST acknowledged a letter of interest and supplied administrative submission guidance; CISA supplied industry-engagement routing and identified an applicable technology-of-interest area. These interactions do not establish institutional endorsement, program admission, security certification, or approval of this specification. Some proposed scientific-method inquiries remain unsent drafts, and UK-authority and AI-laboratory safety-review outreach has not been verified in the inspected records.¶

Historical SkyFi beta-testing correspondence separately documents submitted product/performance feedback, recipient acknowledgment, and reported product-team review. It also records that stress testing stopped at the transition to production and that the recipient asked for further stress testing to remain paused. It does not demonstrate deployment of a fix, a Numina integration, or continuing testing permission.¶

IETF-related records distinguish individual technical proposals and submission administration from technical adoption. NomCom questionnaire activity is candidacy-related and does not establish an IAB or IESG office or Numina approval. The Independent Submissions Editor supplied document-specific feedback that the work requires maturation before publication consideration, including an explicit threat-and-mitigation analysis and field-deployment evidence. Outreach is recorded as process history; it is not evidence that the security properties proposed here have been achieved.¶

Appendix P. Additional public-key and digital-geometry evidence

Evidence cut: 9 October 2026, 08:45 UTC. This bounded update adds verified public-key correspondence and inspected local digital-geometry/software results. It changes no approved operational profile, frozen source commitment, source-artifact normalizer or historical outcome. The proposed companion is still unsubmitted as this artifact, has no newly produced signature, and has not met the field-acceptance gate.¶

d6f1f949c1cc2ef38360668bc2270f847a790e95c882ca6945f7d56fed84bb3c

54d64e8ba4e39d33a85592ac8864a7420be96e60a3864f5d8bf029f4dc33a47c

SHA256:EUTRdHI7yKEgsiCvob3uDx/kDFwjeiDusoEUqfCvVNc

8791301c4565e06e8664153396db39057b13d49c8ba2a844019a86d4322a32d0

42fd1b5a5312c77867f9b02fc7369215a2f20fb497518c4c79e31bb06cf97e6e

a09a479a05d7bc345744a50c1361621b629c89d4bb22f3f443211ffb68586a93

7a20c289293df48cd8a730b90e3e93972331a8e5201c7063773797bee21fdbf5

Author's Address