Inquire +

ASAP · ALEETH AI Systems Audit Platform

Capability without control is exposure.

ASAP measures the Truth of the exposure.
ICA permanently closes it.

ASAP is built for the auditor of record. It finds the AI systems in an estate, tests them, and hands the auditor a sealed record, a verifier that needs nothing from ALEETH, and working papers mapped clause by clause to ISO/IEC 42001, the NIST AI RMF and the EU AI Act. ASAP runs on ICA.

Auditors: take the ASAP survey


What the auditor receives

Six things, in your hands, checkable without us.

01.

The sealed Portable Evaluation Record

One record per engagement, in the open asap.per.v1 schema, with its scope boundary inside the body the customer co-signs. The customer co-signs the measurements first, and the seal then decides the label from the measurements and that signature. Every figure carries one of three labels, and an unmeasured figure never reads as a pass, a zero or a hundred.

02.

The Public Verification Oracle

A versioned verifier with nothing to install, on Node's own crypto. Every seal names the verifier version and sha256 that sealed it, and ICA serves that exact verifier, unchanged, at an address that names the version. It re-runs the seven sealing checks and must reproduce the sealed label byte for byte, or it reads the record INVALID. A single-file record viewer does the same from a local file with the network blocked.

03.

Auditor-signed sample re-performance

You supply the seed, and ASAP seals the sample plan into the engagement ledger the moment you fix it. You re-score the sample on your own machine, your registered key signs every outcome, deviation and override, and ASAP appends the result. ASAP never edits an auditor signature or override.

04.

The Certification-Body Working-Paper Export, versioned

ISO/IEC 42001 clauses 4 to 10. All 38 Annex A controls, each with coverage status, evidence hashes and acceptances. NIST AI RMF, all 72 subcategories. EU AI Act obligations. The residual-risk acceptance register, the scope and exclusion list, the operating-effectiveness window, blank working-paper templates and a Statement of Applicability draft. The export is sealed, names the record, the seal and the crosswalk version it was built from, and refuses to issue from an unsealed record.

05.

An independence declaration

ALEETH discloses its own interest: it sells ICA, which appears in every record as one of two remediation paths, beside an alternative path with its residual risk named. ALEETH pays no referral fee and shares no revenue with auditors. The auditor of record keeps the opinion, the scope and materiality.

06.

The Scope of Reliance Statement

A statement hashed into every record. It says what the record evidences, that the record is evidence for the auditor of record, who keeps the opinion, the scope and materiality, and how to verify the record offline.


The seven sealing checks

A record reads ATTESTED when all seven pass.

A missing input is a failing check, never a skip. The offline verifier re-runs the same checks on your machine and must reproduce the sealed label byte for byte, or the record reads INVALID.

  1. 01 cross_family

    Cross-family judging

    Judges from at least two model families of different pretraining lineage return a verdict on every judged item, each call pinned to one provider with no failover, with disagreement at or under 15 percent and no more than 10 percent of items quarantined.

  2. 02 canaries

    Canaries

    A bank of at least 20 known-answer items, committed by a key that belongs to neither ALEETH nor ASAP before scoring and revealed after it, must be scored correctly at least 90 percent of the time.

  3. 03 write_path

    Write path

    The customer co-signs the record's genesis hash with a key it registered and holds, and the append-only engagement ledger must verify from its first entry to the head the record names, so a rewrite or a deletion breaks the chain or the customer's signature.

  4. 04 risk_acceptance

    Risk acceptance

    Every high residual risk left on the alternative path carries a named owner, an unexpired expiry inside the cap for its level, a re-review date before that expiry and the customer key's signature. A critical residual is accepted only by at least two registered keys holding at least two distinct roles.

  5. 05 self_audit

    Self-audit

    The engine's own self-audit record must itself be ATTESTED, no more than 30 days old, with every calibration reference verdict correct. If it is not, the customer engagement is blocked and ASAP runs no probes against it.

  6. 06 scope_boundary

    Scope boundary

    The sealed scope boundary certificate is present and complete: every system in the AI bill of materials sits in exactly one list, included, excluded or discovered but not declared, and the discovery graph hash matches. Every material exclusion carries a valid named acceptance.

  7. 07 incident_linkage

    Incident linkage

    The customer's registered key has signed an incident completeness statement, and every material incident is linked to the gap that allowed it or carries a signed acknowledgement.

ATTESTED

Measured current state, inside a record whose seal passed all seven checks.

INFORMATIONAL

Any projection or modeled figure, and any figure in a record that did not pass every check.

UNMEASURED

Not measured. Never shown as a pass, a zero or a hundred.


Fourteen optimizations, all in v1

A record that cannot go stale, overreach or hide its edges.

Each one is canonical JSON, hashed, sealed through an artifact receipt and checked offline by the same verifier that checks the record. Two of them are sealing checks: a record that fails either one does not read ATTESTED.

  1. 01 verifier {version, sha256}

    Public Verification Oracle

    Every seal names the verifier that sealed it, by version and sha256. ICA serves that exact verifier, immutable, at an address that names the version, and your own copy prints the sha256 it hashes to, so you compare it with the seal yourself. The verifier prints the version a record cites and refuses a record sealed under a newer version than itself. Verifying takes the customer's public key and ALEETH's trust anchor, pinned by you: no login, no API key, no network.

  2. 02 asap.improvement.v1

    Improvement Attestation

    When a newly sealed record takes residual unknown under 10 percent for the first time in its lineage, or cuts it by 5 percentage points or more against the previous sealed record, ASAP issues an Improvement Attestation naming both seals, both percentages, the newly attested systems and the change in the Truth Integrity Score. The customer key co-signs, ICA seals, and it reads ATTESTED only when both records do. Residual unknown that stays above the bound for 30 days of continuous cycles re-opens a finding.

  3. 03 asap.sample-plan.v1

    Auditor-Signed Sample Re-Performance

    You supply the seed, and the sample plan is sealed into the ledger when you fix it: attribute sampling with zero expected deviations, 59 probes at 95 percent confidence and a 5 percent tolerable deviation. You re-score the sample on your own machine, and your registered key signs every outcome, deviation and override before ASAP appends it.

  4. 04 veracity: recompute

    The Price of Residual Risk, Scored

    Each finding's economic delta between the two remediation paths is split into three claims: the alternative-path expected loss, the ICA-path expected loss and the difference. Every claim cites the sealed assumption table by hash, and the Veracity Engine re-computes it and marks it entailed or contradicted. Each delta carries low, base and high bands over the buyer's own inputs and is labelled INFORMATIONAL as a projection, while the arithmetic check stands as its own measured fact.

  5. 05 expires_at

    Self-Expiring Acceptances

    At every seal and every continuous cycle, an acceptance past its expiry with no completed re-review re-opens its item at critical, takes 5 points off the Truth Integrity Score for each expired acceptance and drops the record to INFORMATIONAL. No human step is needed, and re-accepting a critical item takes the multi-party threshold.

  6. 06 asap.federation.v1

    Cross-Estate Canary Federation

    Estates opt in with one signed statement per engagement and contribute only a summary: scoring version, item count, accuracy, disagreement, quarantine share and judge families. A contribution never carries a canary or a customer identity. Each federation release pools accuracy with Wilson bounds and is sealed, every record cites the latest release, and published bounds change only through a new scoring version that cites the release it used. Below three contributing estates, federation figures read UNMEASURED.

  7. 07 crosswalk_sha256

    Export Versioning

    Every crosswalk version is an immutable file listed with its sha256, and the export names the record, the seal, the crosswalk version and its sha256. Re-exporting a sealed record against a newer crosswalk is one action and yields a new sealed export, the original genesis hash stays valid, and the verifier checks the cited crosswalk hash against the file.

  8. 08 scope_certificate Seal check 6

    Sealed Scope Boundary Certificate

    The scope boundary sits inside the record body, so the customer's co-signature covers it. Every system ASAP found is included, excluded or discovered but not declared, and every excluded segment counts as fully unknown. A material exclusion, one consequential system or more than 5 percent of the estate, needs a named acceptance.

  9. 09 asap.incident.v1 Seal check 7

    Incident-Linked Residual Risk

    Past incidents enter an append-only intake, each linked to the gap that allowed it, with the Truth Integrity Score and residual unknown at the time. Where a decision record exists, counterfactual replay decides whether ICA would have contained it; where none exists, the verdict reads indeterminate and INFORMATIONAL. The customer key signs a completeness statement over its incidents.

  10. 10 asap.reversibility-token.v1

    Reversibility Proof Token

    Issued only from ICA evidence on a system under ICA control: the before state, the control insertion, the after state and a rollback executed and verified, each by hash, with an expiry. A control-effectiveness figure for a high-risk system reads ATTESTED only with a valid, unexpired token or a named irreversibility acceptance.

  11. 11 asap.competence-attestation.v1

    Auditor Competence Attestation

    A deterministic exercise against a published, sealed estate labelled TEST ESTATE: verify a record with the oracle and spot a forged one, read residual unknown and cross-family disagreement, and find acceptances and their expiries. No LLM grades it. A score of 90 percent or more issues a sealed attestation bound to your key and the verifier version, valid for 365 days and checkable offline. Renewal means taking it again.

  12. 12 threshold {k, n, roles}

    Multi-Party Acceptance

    An acceptance carries a k-of-n threshold and signatures from distinct registered keys. A critical residual needs at least two signatures holding at least two distinct roles, such as system owner and risk officer, or customer and external auditor. Below threshold the acceptance is invalid and the record reads INFORMATIONAL.

  13. 13 asap.forecast.v1

    Trajectory Calibration Score

    From three or more sealed records in a lineage, ASAP forecasts residual unknown and the Truth Integrity Score at 30 and 90 days by a published least-squares trend with a prediction interval, and seals each forecast when it is issued. When the horizon passes, the sealed value nearest it is the outcome. Trajectory claims read ATTESTED only at 80 percent interval coverage or better over ten or more matured forecasts, and the score is published in the calibration record and in every record.

  14. 14 asap.predicate.v1

    Sealed Predicate Attestation

    Prove one fact about a sealed record without handing over the record: residual unknown under a threshold, no critical system excluded, a Truth Integrity Score at or above a threshold, or no open critical finding. ASAP evaluates the predicate from the sealed record and refuses to issue when it does not hold, the customer key co-signs and ICA seals. A verifier checks both signatures and the source hashes without seeing the record.


Read live from ICA

The engine's own numbers, live.

Your browser reads each figure from ICA's public ASAP routes. Calibration is aggregated from sealed records, plus a live run of the deterministic reference suite. A figure ICA has not published shows as not yet published, and a figure your browser could not reach shows as not read. Neither is ever shown as a number.

Engine calibration

Not read

Canary accuracy

Not read

Known-answer canaries the engine scored correctly, across sealed records.

Sealing bound: at least 90%

Cross-family disagreement

Not read

How often judges from different model families disagreed on the same item.

Sealing bound: at most 15%

Quarantine rate

Not read

Judged items set aside rather than scored.

Sealing bound: at most 10%

Transport failure rate

Not read

Probes whose reply never arrived intact. A failed transport is recorded as inadmissible, never as resilient.

Published as measured

Reference suite

Not read

Known-exposed, known-resilient, dead and refusing reference targets, plus reference claims, each with an expected verdict.

Sealed records

Not read

Records ASAP has sealed, and how many of them reached ATTESTED.

Raw calibration record

Adversarial testing

Not read

Per-agent battery

Not read

Trials fired at each agent's own enforcement posture, as passed over run.

Shared governance gate

Not read

The assurance run over the governance gate every bound agent inherits.

The two are published side by side and never pooled, so gate robustness never reads as an agent result. These figures measure agents ICA governs. An ASAP engagement measures its own estate and carries those results in its sealed record.

Not read. Your browser reads these figures live from ICA.


Download

The schema is open. The verifier is yours.

All three files are served by ICA. Save them once, and every later check runs on your machine. The verifier comes as one bundle per version: every file with its sha256, under a manifest whose hash is the sha256 a seal cites. Write the files to one folder, re-hash them against the manifest, and run the commands below from there: the first prints the sha256 your copy hashes to.

$ node verify.js version

$ node verify.js record --envelope record.json \

--trust-anchor ica-trust-anchor.json \

--customer-key customer.pub.pem --handoff handoff.json

$ node verify.js sample --envelope record.json \

--seed "<your seed>" --plan-out sample-plan.json

$ node verify.js reperform --plan sample-plan.json \

--envelope record.json --outcomes my-outcomes.json \

--key auditor.key.pem --out reperformance.json

$ node verify.js predicate --artifact predicate.json \

--trust-anchor ica-trust-anchor.json \

--customer-key customer.pub.pem

Exit 0 pass · 1 invalid · 2 usage · 3 indeterminate


The ASAP auditor survey

Set the evidence standard with us.

Ten questions for AI governance leads, internal audit, risk officers and certification bodies. Anonymous, about four minutes, and your answers go from your browser straight to ICA.

Take the survey

Request an engagement

Bring the estate.
Bring your auditor.

Tell us the estate in scope and who the auditor of record is. ASAP requests come through the ALEETH inquiry form, and the auditor can check everything on this page before the engagement starts.

Request an ASAP engagement