The real number, not the pitch
"Trust us" doesn't hold up. This page exists so you don't have to take our word for anything — every audit record we produce is signed by a real identity and anchored by a party we don't control, and this is the honest score against an external standard for exactly that.
Who signs these records
Every audit run is signed by Michael S Ross, founder of Nexus Trinity, with the key below. It's published here and independently at the public transparency log, so you never have to trust one location alone.
Full key: /.well-known/pgp-key.txt (also discoverable automatically via Web Key Directory), and the fingerprint is independently confirmable via this domain's DNS: dig TXT _pgp-key.nexustrinity.io. Mirrors: GitHub · GitLab
How it works
Every audit record is hashed, signed with the key above, and the hash is anchored two independent, deliberately different ways: via OpenTimestamps (a free, decentralized protocol anchoring into the Bitcoin blockchain), and separately via a classical RFC 3161 timestamp from an independent timestamping authority. If you specifically distrust one model — decentralized crypto-anchoring, or a centralized timestamp authority — the other one doesn't share that weakness. The signature proves who attested to a record and that it hasn't changed since. Either timestamp proves it existed at or before a specific time, independent of anything we control. Only the hash, signature, and timestamp proofs are published publicly — target names, addresses, and findings stay private, disclosed separately, on a need-to-know basis. What's disclosed can always be checked against what was committed publicly at the time.
Every record also links to the hash of the one immediately before it, signed together as one unit. Deleting, reordering, or altering any past record breaks that chain at exactly the point it happened — not just at the record itself, but visibly, for anyone holding the sequence.
Two more independent channels back the identity itself: a DNS TXT record carrying the key's fingerprint — DNS is a genuinely separate control plane from web hosting, so both have to agree — and periodic Sigstore keyless signatures, bound to a real-time login and logged permanently in Rekor, Sigstore's own public transparency log — the same mechanism most modern open-source package registries use for supply-chain provenance. The public transparency log is also mirrored to GitLab, a second custodian on genuinely different company infrastructure than GitHub.
Self-score: 16/20 · floor criteria: 6/8
Scored against the Digital Integrity Institute's defensibility rubric, a neutral, external standard — not one we wrote. Criteria 3, 4, 6, and 7 are the floor: the ones that decide whether a record survives a real challenge.
- 01Provenance capture — 2/2. Every record now carries the exact Ollama model digest (not just a tag name), the exact pipeline code commit, and an honest human_reviewed field — always false, since no review step exists yet.
- 02Structural capture (pre-action) — 2/2. Records are written contemporaneously as the pipeline runs, not reconstructed after.
- 03Independent authority / tamper-evidence — 2/2 (floor). Four independent, differently-modeled witnesses now anchor every record: OpenTimestamps (Bitcoin), an RFC 3161 authority (FreeTSA), Sigstore/Rekor (OIDC-bound, its own public transparency log), and a second custodian repo on GitLab, separate company infrastructure from GitHub. No single one failing or being distrusted breaks the guarantee.
- 04Identity integrity — 2/2 (floor). The signing key resolves through four independent channels that all have to agree: this domain's web hosting, this domain's DNS (a separate control plane), the GitHub account, and a real-time OIDC login logged permanently in Sigstore's public Rekor log.
- 05Temporal integrity — 1/2. Real for anything anchored going forward. Historical entries signed before this existed only prove unaltered from the signing date, not the original one.
- 06Third-party verifiability — 1/2 (floor). Anyone can clone the public transparency log and verify a disclosed record independently, without trusting us.
- 07Corroboration, not self-attestation — 1/2 (floor). Findings that reach real fork execution are backed by an actual transaction against real chain state, not an LLM's opinion.
- 08Reproducibility of context — 1/2. Real for findings that reach fork execution — exact block, chain, and test are captured and bundled.
- 09Completeness / fail-closed — 2/2. Every record now links to the hash of the one before it, signed together — deleting or altering a past record breaks the chain at that exact point, detectably.
- 10Portability / open expression — 2/2. JSONL, Solidity, markdown, JSON — open, plain-text formats throughout.
What's still not addressed
- —Even at 2/2, criteria 3 and 4 rest on hash commitments and multi-channel identity proof — not full custody of the actual record content by a neutral third party, and not a legally notarized identity beyond platform/domain control. Real permanent archival (so a record literally can't be deleted, not just detectably deleted) is the one further step under consideration — it costs real money and hasn't been built yet.
- —GitHub's "Verified" commit badge specifically is still blocked on confirming security@nexustrinity.io as a verified email on that account — a real but minor loose end.
- —The hash chain (criterion 9) has one honest limitation: deleting the single most recent record is invisible to the chain alone, since nothing yet comes after it to reveal the gap. The separate public transparency-log repo's own commit history (on two independent platforms now) is the second, independent check for that specific case.
- —Historical records signed or chained after the fact only prove unaltered from that signing moment forward — they don't retroactively vouch for the original timestamp before this infrastructure existed (criterion 5).
- —Real fork-execution evidence (criteria 7, 8) only applies to findings that reach that stage — lower-severity or non-fund-loss findings are still text-based.
This page is updated when the underlying infrastructure changes — not before.