Primary result: PASS, within a narrow scope. In the tested GitHub release case, a native signed attestation supplied the exact release and asset bindings the consequence layer needed. RISU admitted that proof without adding a new generic abstraction or rebuilding the same facts through a larger evidence path.
The idea in plain language
Verification systems often grow by adding one more API call, one more digest check, one more source of metadata, and one more rule for combining them. That can be necessary. But sometimes the platform already produces a stronger proof that binds the facts we care about.
Native++ asks a simple architectural question: when that stronger proof already exists, can the consequence layer use it directly, under an explicit trust policy, without weakening its standards and without making its generic core more complicated?
For this experiment, the platform was GitHub and the native proof was a signed release attestation.
What changed in the evidence path
The earlier style of reconstruction could require several separate observations to establish the release and asset facts. Native++ tested whether those same facts could instead come from one verified signed statement.
The shorter path is not automatically better. It is acceptable only when the native proof really covers the facts the consequence claim needs. Anything outside that signed scope still has to be established separately.
Experimental setup
The successful primary used a fresh GitHub CLI release target. The expected release commit and selected asset digest were fixed before the signed attestation was consumed.
- Repository
- cli/cli
- Release
- v2.100.0
- Expected commit
- 45437bc7eeeb3359bbfddd1742f79de7652fd3e2
- Selected asset
- gh_2.100.0_linux_amd64.tar.gz
- Expected asset SHA-256
- e4d4bb4498e8d007abe545b6568926793ace1b6447da598294a610018cb164be
- Primary run
- 33809187591
- Execution commit
- 455184caf716751148b7c9c2a372b66084dcaa30
Two checks, not one
A valid signature was not enough by itself. Native++ separated two questions that are easy to blur together.
- Cryptographic verification: did GitHub's verifier accept the signed attestation?
- Semantic admission: did the verified statement use a schema we had explicitly audited, and did it bind the exact facts our claims required?
The experiment accepted only the audited in-toto release predicate versions v0.1 and v0.2. An unknown future schema would be treated as unsupported rather than guessed into compatibility. The decoded DSSE payload also had to match the verifier-returned statement exactly before any consequence-relevant facts were admitted.
A constraint set before the result
The experiment was not allowed to make the GitHub case fit by inventing new generic machinery after seeing the answer. Five generic surfaces were precommitted to remain unchanged.
All five remained at zero in the successful primary.
Primary result
The verified release statement contained 23 subjects. Within that statement, the experiment found exactly the release subject and selected asset subject required by the precommitted claims.
The decoded DSSE payload and the statement returned by the verifier were also checked for exact JSON equality.
Negative controls
A useful admission path has to reject evidence that is close to correct but wrong in a consequence-relevant way. Native++ therefore included two simple controls.
One-byte mutation
The authentic release asset was copied and changed at exactly one byte while preserving its total length. The modified object had SHA-256 a99e439468a59d4d2dcbea681960e5df2b112d23d71c2c816e18663f6b658086. Native verification rejected it because that digest was not a subject of the signed release attestation.
Wrong release
The authentic v2.100.0 asset was checked against release v2.96.0. Verification rejected it because the asset digest was not a subject of the wrong release's attestation.
Both controls behaved as required. The valid target passed, while a one-byte mutation and a valid asset paired with the wrong release were rejected.
What the result means
The result is useful because the consequence layer did not need to become a second GitHub verifier. It could recognize that GitHub's native proof was already stronger for these exact facts, admit that proof under a declared policy, and keep the rest of the generic machinery unchanged.
In architectural terms, this is a small example of evidence-topology collapse: several weaker reconstruction steps can disappear when one stronger proof already covers the same obligation.
Supported conclusion: when a platform-native signed proof already binds the exact facts required by a consequence claim, a frozen consequence-evidence substrate can reuse that proof instead of independently rebuilding those same facts from weaker evidence planes.
What the result does not mean
This was deliberately a narrow checkpoint. It does not show that platform attestations solve consequence verification in general.
- It does not establish cross-provider semantic-labor amortization.
- It does not show that provider-specific binding work is trivial.
- It does not outperform or replace GitHub's native verifier.
- It does not establish availability, temporal delivery, namespace-wide uniqueness, or economic finality.
- It does not establish correctness for arbitrary consequences.
- It does not show that every consequence can be reduced to an attestation.
- It does not eliminate the trusted surface of the binding itself.
- It does not establish commercial superiority over a strong bespoke implementation.
Why the failed runs matter
The successful primary came after two failures, and both are kept in the record because they changed the design in useful ways.
Run 33805476200 stopped before primary observation because archive identity and executable identity had been conflated. Run 33806977992 reached its then-primary target but exposed a stale release-predicate schema assumption after cryptographic verification.
That second target was not recycled into the successful result. Native++ v0.2 selected a fresh primary instead. The earlier runs remain failures and explain why the successful version treats verifier identity, schema admission, and consequence evidence as separate concerns.
Frozen evidence anchors
The public page keeps the result readable. The deeper archival record preserves the exact identities needed to trace it back to the experiment.
- Native binding digest
- sha256:4923181ebacedabf186333b8e16d3f1152f1bc66ab9e16ed8330c8e7402a5c34
- Source archive SHA-256
- a65d2e79590f99cff0efa83de283075f54c69135d00487caa5d1c305ee0aaa8b
- Primary artifact SHA-256
- b3c2242bdfc11d9bdf653f1de2491297174e41da1d4f63b05d230e0a5e852f96
- Post-hoc audit SHA-256
- 5f25db28abce3693e76bf660594318669b06012744982870ca9964ea59ab319e
The raw execution ZIPs are not duplicated on the website. They remain identified by exact digests, while the public page presents the experimental question, result, limits, and reproducibility-relevant anchors in a form that can be read without navigating the repository first.