Enablement
Every claim limitation, its status, and what pins it.
Quote the 55 beside the 9. A proof over the anchored subset is not a proof over the claim set, and the prover prints both together for that reason.
The contract this table is held to
A limitation must cite a shipped symbol, a named test and a harness section, all of which exist, and the prover must be able to disable the cited mechanism and make that limitation’s own tests fail. That last clause is what separates “the code is there” from “the code is what makes the test pass”.
Status vocabulary
| Status | Count | What it means |
|---|---|---|
| PRACTICED | 44 | A shipped symbol implements it, a named test exercises it, and disabling the symbol makes that test fail. |
| PRACTICED_WITH_NOTE | 8 | As PRACTICED, with a stated limitation on what the test can reach. |
| BOUNDARY | 3 | The mechanism is implemented and tested up to a declared boundary that this build could not cross — named in the note, never elided. A BOUNDARY limitation is NOT enablement of the part beyond the boundary and no document may read it as one. |
| DESCRIPTION_ONLY | 9 | The specification describes it and no code in this tree implements it. Recorded as a finding, not a placeholder. |
Declared boundaries
A BOUNDARY limitation is not enablement of the part beyond the boundary, and no document may read it as one.
B-HW-PLATFORM
No AMD SEV-SNP, Intel TDX or AWS Nitro hardware was available to this build. The SNP, TDX and Nitro readers are exercised against structurally exact fixtures signed by keys the tests generate.
Proves: the reader — that the caller-supplied field is found at the offset the format defines, that a signature over the correct byte range verifies and one over any other range does not, and that the field lies inside the signed region.
Does not prove: that a real platform emits what the fixture emits. Confirm each provider against one report from real hardware before it gates a payment.
Stated at: 26-settlement/lib/attest.js header; 26-settlement/test/fixtures.js header; every verifyAttestation() result carries it in `boundary`.
B-HW-COLLATERAL
No endorsement certificate path is built and no CRL or OCSP is fetched by any module here.
Proves: nothing about current platform validity.
Does not prove: n/a — the design does not attempt it. Collateral travels in the verification bundle with its retrieval time and bounds the outcome at VERIFIED_AS_OF_TIME_OF_RETRIEVAL, which is what claims 20, 21 and 43 recite.
Stated at: 26-settlement/lib/verification-bundle.js; test E2E4.
B-TDX-ENDIAN
The R‖S octet order of a real Intel TDX quote signature is declared big-endian here and was NOT confirmed against hardware.
Proves: nothing about a real quote's byte order.
Does not prove: n/a. Stated rather than assumed because an unstated endianness assumption produces exactly the same symptom as a forged report, which this session already read once.
Stated at: 26-settlement/lib/attest.js, the TDX provider block.
B-GEOMETRIC
No geometric training, paired-perturbation generation, latent-manifold embedding or flip-rate measurement exists in this tree. grep for flipRate / flip_rate / perturbation over 03-source and 26-settlement returns zero code hits.
Proves: n/a
Does not prove: claims 8, 9, 13, 14 and 29. What DOES exist is the core's geometric ADMISSIBILITY axis — policy.js GEO_POSITION / GEO_STRICTNESS / geometricOf, gate.js:871, check-geometric-isolation.js and test/geometric.test.js — which is a four-rung determination READ FROM A RECORD, not a model. It supports claims 28 and 30 and it does not support the training claims.
Stated at: this register; 26-settlement/README.md
B-ENV-PREIMAGE
`assertNoEnvironmentOperand` compares the four commitment operands to the environment facts by VALUE. Operands 2 and 4 are digests — of the policy document and of the settlement instruction object — so a launch measurement carried inside either document makes the operand a function of that measurement while a comparison of values sees nothing.
Proves: that no operand IS an environment fact, and that no operand CONTAINS one: the check tests containment in both directions over normalised hex, so a measurement with sixteen random octets appended is refused. It also refuses a fact reported in a shape it cannot read, rather than skipping it.
Does not prove: that a measurement is absent from the PRE-IMAGE of a digested operand. A hash check cannot see the hash's input, and no cleverer comparison of values closes that — it is closed by passing the pre-images. `assertNoEnvironmentOperandDeep(preimages, facts)` is that check and is shipped; a caller who does not hold the pre-images at commitment time cannot run it, and this boundary is that caller's.
Stated at: 26-settlement/lib/settlement.js, in the block immediately below assertNoEnvironmentOperand; pinned by SC20 and SC21 in 26-settlement/test/settlement.test.js.
B-LOG-SELF-WITNESS
`TransparencyLog.admit` verifies a presented head by RECOMPUTING this structure's own root at the presented tree size. That is stronger than checking a consistency proof and needs none — but it is available only because this class IS the structure whose history is in question.
Proves: that no head carrying a root this structure did not produce is admitted, at any size: a fabricated root is refused as a split view, and a head claiming more leaves than exist is refused by name.
Does not prove: anything about a REMOTE log this process only witnesses. A witness holding no leaves cannot recompute a root and must fall back on `verifyConsistency` between two heads, which is exercised here (79,494 executed forgery attempts, 0 acceptances) but is a different party asking a different question. A deployment that witnesses a foreign log needs the proof path, and this module does not provide the admission side of it.
Stated at: 26-settlement/lib/transparency.js, in the admission block; pinned by TR22 and TR23.
Every limitation
All 64 limitations, grouped by status. A group is an anchor: the status table above links into each one, because 64 rows with no way in is the same defect as a register with no filter, one order of magnitude smaller.
PRACTICED · 44
| Claim | Limitation | Recites | Pins |
|---|---|---|---|
| 1 | 1(a) | allocating, before the agent action is executed, a settlement instruction handle naming a settlement not yet effected, allocated by the system rather than received from the endpoint the settlement instruction object i… | 4 symbol(s), 5 test(s) |
| 1 | 1(b) | computing a settlement commitment over the settlement instruction handle, a digest of a governing policy, a nonce, and a digest of a settlement instruction object bearing the settlement instruction handle | 3 symbol(s), 3 test(s) |
| 1 | 1(c) | no operand of the settlement commitment being a measurement of, a key held by, or a manifest describing, the sealed execution environment | 2 symbol(s), 5 test(s) |
| 1 | 1(f) | generating, after the executing and once for that executing, a sealed-compute attestation, the signature covering both a digest of the computational trace and the caller-supplied input field | 2 symbol(s), 3 test(s) |
| 1 | 1(g) | holding the settlement instruction object in a store that exposes no interface by which it may be obtained by a caller, the store admitting a single operation that performs a recomputing and a comparing and that emits… | 1 symbol(s), 4 test(s) |
| 1 | 1(h) | releasing only upon verifying the signature, reading the caller-supplied input field from WITHIN that attestation rather than from any copy retained when the attestation request was composed, recomputing the settlemen… | 2 symbol(s), 4 test(s) |
| 1 | 1(i) | registering the sealed-compute receipt in an append-only transparency structure that admits a registration only upon verifying that a tree size carried in a signed tree head is not less than a greatest tree size previ… | 2 symbol(s), 5 test(s) |
| 1 | 1(j) | outputting a verification bundle that cryptographically binds an identity or delegation receipt, a data-provenance record, the sealed-compute attestation, and the concrete settlement identifier, configured to enable o… | 2 symbol(s), 11 test(s) |
| 6 | 6(a) | cryptographically committing each version of the living system plan by hashing the plan content and registering the hash in the append-only transparency structure, and binding each plan version to one or more of the l… | 2 symbol(s), 1 test(s) |
| 7 | 7(a) | the living system plan comprising a System Security Plan, a System Privacy Plan, and a Cybersecurity Supply Chain Risk Management Plan | 1 symbol(s), 1 test(s) |
| 11 | 11(a) | a sealed-execution module, a payment-gating module, a receipt-lineage module and an offline-verification package generator, coupled to one another | 4 symbol(s), 10 test(s) |
| 12 | 12(a) | maintaining the directed provenance graph, mapping it onto control families, generating living system plans, committing each version and binding it to receipts | 2 symbol(s), 2 test(s) |
| 16 | 16(a) | receiving a signed permit object naming a digest of the sealed-compute attestation, and comparing against the caller-supplied input field read from within the sealed-compute attestation NAMED BY THE SIGNED PERMIT OBJECT | 1 symbol(s), 4 test(s) |
| 16 | 16(b) | otherwise leaving the settlement instruction object held and emitting a refusal receipt naming the comparison that failed | 1 symbol(s), 2 test(s) |
| 16 | 16(c) | outputting a verification bundle structured such that an order in which the sealed-compute attestation was signed and the settlement instruction object was released is derivable from the verification bundle alone, wit… | 2 symbol(s), 10 test(s) |
| 17 | 17(a) | for each input artifact, a content digest, an identifier of a party that supplied it, an identifier of an authority under which it was obtained, and a time of obtaining; the input commitment being a root of a Merkle t… | 2 symbol(s), 2 test(s) |
| 18 | 18(a) | the concrete settlement identifier not existing at a time the settlement commitment is computed, and the payment-settlement receipt binding it to the handle after release | 1 symbol(s), 1 test(s) |
| 21 | 21(a) | a verifier returning exactly one of three outcomes, being verified, verified as of the time of retrieval, and unverifiable | 2 symbol(s), 3 test(s) |
| 21 | 21(b) | the outcome verified as of the time of retrieval naming an element whose current validity could not be established, the instant to which the verification extends, and the time at which collateral for that element was … | 1 symbol(s), 2 test(s) |
| 21 | 21(c) | the verifier being INCAPABLE of returning verified unless the named element is retrieved afresh and found current, such that neither passage of time nor re-reading of the same verification bundle changes the outcome | 1 symbol(s), 1 test(s) |
| 22 | 22(a) | an element that cannot be established from the verification bundle is materialised at zero and bounds the outcome, and accumulation of evidence of other kinds does not raise the outcome | 1 symbol(s), 1 test(s) |
| 24 | 24(a) | a countersignature over the signed tree head from a witness INDEPENDENT of an operator of the structure, and requiring a stated number before the verified outcome is returned | 1 symbol(s), 2 test(s) |
| 26 | 26(a) | an offline-verification package generator that serialises in a canonical encoding and emits the serialisation together with a digest over the serialisation | 2 symbol(s), 2 test(s) |
| 27 | 27(a) | determining a set of control identifiers whose mapped nodes or edges changed, recomputing implementation status and evidence references for each, emitting a new plan version carrying each changed field, and registerin… | 3 symbol(s), 4 test(s) |
| 30 | 30(a) | a structural score that is absent being materialised at zero, and a score materialised at zero being able only to withhold or narrow and never to authorise a release | 1 symbol(s), 1 test(s) |
| 31 | 31(a) | emitting a signed release receipt naming the digest of the sealed-compute attestation, the settlement instruction handle, and a digest of the signed permit object, and registering it in an append-only transparency str… | 2 symbol(s), 2 test(s) |
| 32 | 32(a) | carrying a first signed tree head, a second signed tree head, and a consistency proof relating them, structured such that registration of the release receipt after the sealed-compute receipt is establishable from the … | 2 symbol(s), 3 test(s) |
| 33 | 33(a) | a tree size in the second signed tree head exceeding that in the first, and the structure admitting no registration under a signed tree head of a tree size lower than the greatest previously admitted | 1 symbol(s), 3 test(s) |
| 35 | 35(a) | the ordering being an ordering of the sealed-compute attestation against the release of the settlement instruction object, and NOT an ordering of two registrations considered without regard to what they record | 1 symbol(s), 1 test(s) |
| 36 | 36(a) | a stated number of countersignatures required before the verified outcome, and a lesser number returning verified as of the time of retrieval | 1 symbol(s), 1 test(s) |
| 37 | 37(a) | supplying with the signed permit a digest of a living system plan version current when the permit was written, and leaving the object held where that digest differs from the version most recently registered for a cont… | 1 symbol(s), 2 test(s) |
| 38 | 38(a) | a refusal naming a control identifier and the two living system plan version digests that differ, and a control whose implementation status cannot be established being materialised at zero and withholding | 2 symbol(s), 4 test(s) |
| 39 | 39(a) | allocated by the computing system, naming a settlement not effected at allocation, rather than received from the external endpoint or derived from a settlement that already exists | 2 symbol(s), 3 test(s) |
| 40 | 40(a) | an attestation whose caller-supplied input field was populated after the signature was produced being refused as unverifiable | 1 symbol(s), 2 test(s) |
| 42 | 42(a) | the materialising at zero governing a value aggregated into the outcome rather than a condition of a gate, such that an element which cannot be established bounds the outcome even where every condition of the gate is … | 2 symbol(s), 1 test(s) |
| 43 | 43(a) | the outcome naming the time of retrieval and the reported trusted computing base version | 1 symbol(s), 1 test(s) |
| 44 | 44(a) | where the verification does not succeed, effecting no registration and emitting a refusal receipt naming the tree size presented, the greatest tree size previously admitted, and a reason code | 2 symbol(s), 4 test(s) |
| 45 | 45(a) | such that no result of any operation of the store is the settlement instruction object | 2 symbol(s), 4 test(s) |
| 46 | 46(a) | the caller-supplied input field used in the comparing being read from within the sealed-compute attestation after the signature has been verified, rather than from a copy retained when the attestation request was comp… | 2 symbol(s), 4 test(s) |
| 47 | 47(a) | a settlement rail adapter accepting a settlement instruction only where it bears the settlement instruction handle allocated before execution of the agent action, and refusing a settlement instruction bearing any othe… | 1 symbol(s), 3 test(s) |
| 48 | 48(a) | a control whose implementation status cannot be established contributing a value of zero and further capping the aggregate readiness score at a stated ceiling, such that no assessed value of any other control raises t… | 2 symbol(s), 4 test(s) |
| 49 | 49(a) | refused as unverifiable without regard to whether the comparing would yield identity | 1 symbol(s), 1 test(s) |
| 50 | 50(a) | presenting the settlement instruction handle to a settlement rail adapter operated by the computing system, accepting a settlement instruction only under a handle present in a registry it holds, and thereafter present… | 1 symbol(s), 3 test(s) |
| 51 | 51(a) | the leading thirty-two octets carrying the settlement commitment and the following thirty-two the digest of the computational trace, a remainder beyond sixty-four octets being zero-filled and not read, and neither val… | 3 symbol(s), 5 test(s) |
PRACTICED_WITH_NOTE · 8
| Claim | Limitation | Recites | Pins |
|---|---|---|---|
| 1 | 1(e) | executing at least a portion of the agent action inside a sealed execution environment that produces a computational trace comprising an input commitment, a code-version fingerprint, resource-utilization metrics, and … | 2 symbol(s), 3 test(s) |
| 2 | 2(a) | the concrete settlement identifier selected from a group of three | 1 symbol(s), 1 test(s) |
| 5 | 5(a) | a directed provenance graph whose nodes include sealed-compute nodes and settlement-identifier nodes, and mapping nodes and edges onto control families defined in a cybersecurity supply chain risk management standard | 2 symbol(s), 2 test(s) |
| 10 | 10(a) | an omnibus memory-storing-instructions clause spanning the whole of claim 1's method, plus a store having no egress path through the network interface | 1 symbol(s), 1 test(s) |
| 23 | 23(a) | registering the refusal receipt in an append-only transparency structure and obtaining an inclusion proof for it | 2 symbol(s), 2 test(s) |
| 25 | 25(a) | an omnibus memory-storing-instructions clause spanning the whole of claim 16's method | 1 symbol(s), 1 test(s) |
| 28 | 28(a) | supplying the structural score to the payment-gating module WITH AN EFFECT CONFINED TO reducing an authorised amount, narrowing an authorised scope, or setting a gate flag to withhold | 1 symbol(s), 1 test(s) |
| 41 | 41(a) | a region of memory not mapped to a network interface, of which a payment-gating module is the only reader and the only writer, and releasing comprising copying the object out of that region into a SEPARATE egress buff… | 1 symbol(s), 3 test(s) |
BOUNDARY · 3
| Claim | Limitation | Recites | Pins |
|---|---|---|---|
| 1 | 1(d) | writing the settlement commitment into a caller-supplied input field of an attestation request before the attestation is signed, such that a signature of a hardware root of trust covers the settlement commitment boundary B-HW-PLATFORM | 3 symbol(s), 3 test(s) |
| 19 | 19(a) | the caller-supplied input field being a report-data field of an attestation report OR a user-data field of an attestation document boundary B-HW-PLATFORM | 3 symbol(s), 3 test(s) |
| 20 | 20(a) | carrying an endorsement certificate chain, a reported trusted computing base version and a revocation state of each certificate, each accompanied by a time of retrieval, together with a signed tree head boundary B-HW-COLLATERAL | 1 symbol(s), 2 test(s) |
DESCRIPTION_ONLY · 9
| Claim | Limitation | Recites | Pins |
|---|---|---|---|
| 3 | 3(a) | a zero-knowledge proof that a computation satisfying a predetermined policy was performed inside the sealed execution environment | — |
| 4 | 4(a) | a zero-knowledge proof that the concrete settlement identifier was released only after successful verification of the sealed-compute attestation | — |
| 8 | 8(a) | representing a multi-party provenance graph as a geometric structure in a latent manifold and training a geometric reasoning model using paired perturbations boundary B-GEOMETRIC | — |
| 9 | 9(a) | embedding nodes into a latent manifold such that cryptographic linkage edges and authority-delegation edges correspond to geodesic or local neighborhood relationships boundary B-GEOMETRIC | — |
| 13 | 13(a) | a graph-projection module, a geometric training module, a scoring module and a control interface boundary B-GEOMETRIC | — |
| 14 | 14(a) | flip-rate training that measures a rate at which an output changes under paired geometric perturbations boundary B-GEOMETRIC | — |
| 15 | 15(a) | generating the sealed-compute attestation as a zero-knowledge proof and including a ZKP of ordering in the bundle | — |
| 29 | 29(a) | comparing a first flip rate against a second and, where the first does not exceed the second by a recorded margin, emitting no structural score and recording a refusal stating both rates boundary B-GEOMETRIC | — |
| 34 | 34(a) | the endorsement chain, TCB version and revocation state captured at the time the attestation is produced and bound to it by a digest recorded in the sealed-compute receipt | — |
Corobate · standalone install · one product · built by 27-console/build-console.js from the register, not typed.
This page loads nothing from another origin, makes no request at run time, and touches no browser storage. It works from a file on disk with no server.
Nothing in this console is legal advice.