Testing a TokenMark™ record — guide for auditors

Who this is for. Internal audit, external audit, and controls functions encountering TokenMark™ records during a walkthrough of an entity's AI cost or vendor management processes. It assumes no familiarity with the product and no cryptography background.

Stated once here, so it need not be repeated below. This is not a compliance certification, and we assert no conformity with any framework. We hold no third-party attestation report at present; an independent assessment is planned and funded. And this guide is written by the vendor — which is precisely why every procedure below is designed to be performed without our participation. Judge it on whether the procedures work when we are not in the room.

1 · The condition this addresses

An entity engages a vendor to reduce its AI model consumption. The vendor is compensated as a share of the reduction it reports. In the ordinary arrangement, the same system performs the optimization, measures the result, and produces the report — and the entity has no independent means of reproducing the figure.

Stated in controls terms: the party performing a transaction is the sole source of evidence about it, and the amount charged is derived from that evidence. Segregation of duties is absent, and the deficiency cannot be remediated by inspecting the report, because the report is the artifact in question.

2 · What a TokenMark record asserts

Each record (a “sealed container”) carries two independent signatures and a set of recorded facts. The assertions are narrow and specific:

The record asserts	Basis
These specific units of context were present in the original request	Enumerated in a manifest before any were removed
These were retained; these were withheld	Recorded as a partition, with the two sets required to be disjoint and to exhaust the manifest
The consumption difference is this figure, measured against this baseline	Baseline fixed by digest before the result was known
The figure was recomputed by a component in a separate trust domain	Second signature, produced under different operating-system credentials
The record has not been altered since it was sealed	Both signatures cover a digest of the record contents

What it does not assert

That the optimization was wise. The record says what was removed, not that removing it was the right decision. Output quality is a separate matter and should be tested separately.
That the baseline is the right baseline. It asserts the baseline was fixed in advance and not changed. Whether the method is appropriate is a judgment for the entity.
That the provider's own token counts are accurate. Where a count originates with the model provider, the record marks it as provider-asserted rather than independently verified. That distinction is carried in the record and should be read.
Anything about the content of the requests. Only one-way digests are recorded.

The central control is a negative capability. The component that performs the optimization cannot produce the second signature, because the operating system denies it access to the key. It is not prohibited from doing so by policy — it is unable to, and the inability is testable before the system processes any traffic. Test the capability, not the assurance

3 · Suggested control objectives

Ref	Control objective
C-1	Amounts charged by the vendor are derived from records that a party other than the vendor can reproduce.
C-2	The basis of measurement is fixed before results are known and cannot be revised afterward.
C-3	The component computing the figure is segregated from the component certifying it, and the segregation is enforced by the platform rather than by procedure.
C-4	Records remain verifiable independently of the vendor's continued existence or cooperation.
C-5	Exceptions are distinguishable from configuration faults and are investigated.

4 · Test procedures

T-1 — Verify a sample of records (addresses C-1, C-4)

Obtain the entity's archive of sealed records for the period, and the verification utility. Both are held by the entity, not the vendor.
Select a sample. Because each record is independently verifiable, sampling may be statistical; there is no incremental cost to verifying the full population, and doing so is reasonable where the archive is machine-readable.
Run the verification utility on each selected record, on entity or audit hardware, with network access disabled. Vendor personnel should not be present.
Record the exit condition for each item.

$ tokenmark-verify <record> --bundle <policy bundle> VERIFIED digest=... savings=... EXIT 0

Expected result: exit condition 0 for every item. Any other condition is an exception requiring investigation — see T-5.

Why this is evidence: the utility recomputes the digest from the record's own contents and confirms both signatures against public keys. It does not ask the vendor anything. A record altered after sealing fails.

T-2 — Confirm the two signatures come from different domains (addresses C-3)

Verification confirms that the two signatures were produced under different operating-system accounts. A record bearing two signatures from the same domain fails verification. Inspect the utility's output for the confirmation, and inquire whether any record in the period was rejected on this basis.

T-3 — Inspect the deployment verification (addresses C-3)

Before the system is permitted to process traffic, it verifies its own segregation against the live platform: distinct service accounts, key ownership, and file permissions restricting each key to its own account. This check is re-runnable at any time and produces a record.

Request the deployment verification record from the period under review.
Re-run the check in the entity's environment and observe the result directly.
Optionally, observe an attempt by the optimizing component to read the certifying key. The expected outcome is refusal by the operating system.

Why this matters: this converts a vendor representation about segregation into an observation of the platform's actual configuration.

T-4 — Test the baseline pinning (addresses C-2)

Each record references the measurement basis by digest. Confirm that the referenced basis matches the policy bundle in force for the period, and that the bundle digest recorded at the start of the period is unchanged at the end. A basis altered mid-period produces records that fail verification rather than records that silently reflect the new basis.

T-5 — Evaluate exceptions (addresses C-5)

The utility distinguishes three conditions. The distinction is material to your response:

Condition	Meaning	Response
Verified	Signatures valid; contents unaltered; structural checks pass	No exception
Integrity fault	A signature is absent or invalid, contents do not match the sealed digest, both signatures share a domain, or a structural check fails	Investigate. The record is not reliable evidence of the amount charged
Configuration fault	An input could not be resolved — missing bundle, wrong path	Re-perform with correct inputs. Not, by itself, evidence of a problem with the record

T-6 — Read the measurement basis flags (addresses C-1)

Each count carries an indication of whether it was verified from the provider's response or asserted by the provider. Where a material portion of the period's savings rests on provider-asserted counts, the assurance obtained is correspondingly weaker, and this should be reflected in your conclusion. The record does not conceal this; it states it.

5 · Evidence retention

Sealed records are self-contained. They remain verifiable after the engagement ends, after the vendor relationship ends, and after the vendor ceases to exist, provided the entity retains the records, the public keys, and the utility. All three are held by the entity. We recommend the entity's retention policy treat them as it treats other supporting documentation for amounts charged.

6 · Why this is testable evidence

Most vendor assertions about their own performance are, from an audit standpoint, inquiry. They can be corroborated only by asking the vendor a second question. A TokenMark™ record is different in a specific and useful way: it is reperformable.

You reperform the computation, not the vendor. The verification utility recalculates the digest from the record's own contents and confirms both signatures against public keys. That is reperformance in the ordinary sense — the same procedure, executed independently, with a known expected result.
The evidence is entity-held. Records, public keys, and the utility all sit with the entity. No step depends on the vendor's cooperation, systems, or continued existence.
The control is observable rather than represented. Segregation between the computing and certifying components is verified against the live platform and re-runnable on demand. You are not accepting a description of a control; you are watching the platform enforce it.
Failures are unambiguous. An altered record fails. A record signed by only one domain fails. The utility separates an integrity fault from a configuration fault, so an exception means something specific rather than something vague.

The result is a vendor charge supported by evidence the entity can reproduce without the vendor. That is an unusual position for a vendor to put itself in, and it is deliberate. The architecture exists so that our assertions are checkable by people who have no reason to take our word for anything. Sealed savings. Proven, not promised.

7 · Where this fits a documentation request

Several supervisory regimes now expect a regulated entity to maintain a governance program over the AI systems it uses, and to produce evidence about that program on a regulator’s timeline rather than its own. We take no position on which regime applies to your client. The recurring requests, across regimes, tend to look the same:

What is asked for	What a vendor-authored log establishes
An inventory of the AI systems actually in use	What the vendor recorded. It cannot show that traffic outside the inventory did not occur, because it only sees traffic it was asked to see.
That approved systems were used for approved purposes	A policy statement and a log written by the system the policy governs.
Accountability for AI the entity did not build	The third party’s own account of the third party’s own conduct.
An audit trail adequate to reconstruct what happened	A trail that can be adequate and still be authored entirely by the subject of the reconstruction.

A sealed record changes the answer in the right-hand column and nothing else. Consumption is recorded at the gateway rather than reported by the model provider; declared lanes make approved-use enforcement observable rather than asserted; the second signature comes from a domain the recording component cannot invoke; and the trail is reperformable by the entity after the vendor is gone. Every one of those is testable by the procedures in section 4.

What this is not

It is not a fairness or bias test. Nothing here evaluates whether a model treats similarly situated people similarly. That is a separate discipline and a separate vendor.
It is not model validation or drift monitoring. The record says what ran, not whether what ran performed as it did in development.
It is not the decision record. Content is never written, logged, or hashed. A record cannot tell you what a model was asked or what it answered, by design. This is the governance and consumption record around a system, not an account of the system’s reasoning.
It is not a compliance opinion. Whether any of this satisfies an obligation your client is under is a question for their counsel, not for us.

We would rather state those limits here than have a practitioner discover them mid-engagement. If a request in front of you needs something in the list above, this is the wrong product and we will say so.

If any procedure in this guide cannot be performed as written, in your environment, without our involvement, we would consider that a defect in the product and we want to hear about it. That invitation stands for any practitioner, whether or not your client is a customer.