R001

One reviewed release of EZA-001. The release package is the technical source of truth for every value below; this page presents it without restatement.

Specification: EZA-001
Specification version: 0.1.0-draft.7
Release: R001
Frozen candidate: EZA-001-R001-rc.9
Wire version: 0.1.0-draft.7
Maturity: EXPERIMENTAL
Licence: Apache-2.0
Publication state: PUBLIC ON THIS PROPERTY AS EXPERIMENTAL
Publication date: No exact date recorded

Publication here means these exact bytes are delivered by this property and the owner approved public release at EXPERIMENTAL maturity. It is not formal release acceptance, not an unqualified all-gates pass, and not certification of any kind.

Basis: Owner approval for public release as EXPERIMENTAL, recorded 2026-09-16 (UTC), together with an anonymous hosted-download run against https://eziah.dev in which every declared artifact matched its expected byte count and SHA-256.

Source: currentGates "final owner publication approval" and "eziah dev wiring and acceptance" in this release record (unsigned external records).

No exact publication date is recorded in this release record. A candidate revision date, a signing date or a build timestamp is not a publication date, and none is substituted here. A missing date is not evidence that publication has not happened.

The frozen candidate archive, its signed manifest and the detached signature are immutable. External publication records and the explanations on this website can receive later sourced updates without changing one frozen byte.

Candidate archive SHA-256 / sha256Pointer checked, bytes not hashed here

3062213046b50db71ddbf13160a9711a25b2e8b1dd882a3bf35e007958b22e39

Signed manifest SHA-256 / sha256Bytes hashed against declaration

fc44b015cbf152aef4e4cc25bc0bdc6d58f6763a0af871b81795de04e32f8f3e

Candidate archive: This file is hosted rather than committed, so this build checked only that its declared digest, size, and hosted location agree with the committed pointer. Its delivered bytes are hashed by the separate hosted-download check.

Signed manifest: This build hashed the published bytes and matched the digest and size this release declares. That is a byte check against the release's own declaration; it is not a signature verification. This file is covered by the release signature directly: the detached signature is over these exact bytes. That signature was verified separately, on another machine, and is reported as its own recorded result.

Limits of this release

As stated

Limits are published alongside claims so a claim is never read as broader than the evidence supporting it. They are grouped by what they are limits OF: the frozen candidate's own technical boundaries, its freeze-time status statements, licensing, editorial context for this surface, the external acceptance record, the review process, individual checkpoints, and what a past verification record did not establish when it was written. A freeze-time status statement is not a technical limit, and it does not reopen a decision recorded as complete.

Stated limitations

Technical limits of the frozen candidate

Boundaries the candidate states about its own behaviour, carried from its own limits and boundary documents.

CAND-LIM-1
Trusted host: The requesting agent must not control the host, actor binding, manifest pin, registry, code approvals, clock policy, controller binding, ledger, witness, or database. Python attributes and function arguments do not enforce that separation.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-2
Rollback: Tests restore the database while retaining the current witness and lock. They do not restore the whole machine, a copied witness, or the operator's entire trust state. Whole-host rollback needs an independent durable anchor outside that rollback domain.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-3
Clock: Host mode uses the OS Unix clock plus monotonic samples. The operator must establish whether that clock is reliable. The code detects the stated uncertainty and reversal cases; it does not authenticate UTC or detect every plausible clock lie.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-4
Delivery: A failure after a pending transition may have begun is INDETERMINATE. These tests do not prove physical power-loss durability, distributed exactly-once execution, or recovery from every filesystem failure.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-5
Controller reporting: DELIVERED means a numbered dispatch result was returned. It does not prove the whole request is settled. Earlier admissions without a definitive receipt remain INDETERMINATE, even after a retry succeeds or is denied. An unverifiable ledger produces UNVERIFIABLE.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-6
Scope: Object identifiers are opaque. There are no paths, wildcards, callbacks, shell commands, network writes, automatic grant migration, automatic upgrades, or remote attestation in this profile.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-7
Public API: Requester access is only the closed submit/prepare/commit envelope and the configured controller inbox. The evidence verifier reads receipts and returns claims. Operator provisioning, code approval, test fault controls, and private state files are not requester endpoints.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-8
Receipt trust: A valid Ed25519 signature proves that the holder of the pinned key signed the exact claim. It does not establish current authority, fresh state, or the truth of an unobserved effect. Fixture keys used in tests are not Eziah signing keys.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-9
Evidence consistency: RESULTS.md names the checks that can be made from a result and available request context. A plausible claim from a compromised trusted host can still be false. Signatures and consistent fields do not prove unobserved effects or current authority.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-10
Controller format: This candidate creates only new binding/3 test controllers. It does not migrate or reset earlier binding/2 ledgers.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-11
Schema limits: JSON Schema is a structural check. Byte limits, strict parsing, key uniqueness, trust, state continuity, signature verification, and reason precedence also require executable checks.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-15
Process separation: This candidate protects synthetic local objects through a trusted registry, a SQLite transaction, and a separate protected witness. Process separation alone is not an operating-system permission boundary.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-16
Replication: Copying the entire trusted database, witness, approvals, and host identity to another machine is outside the tested rollback boundary. A deployment that permits that copy needs a separate external authority anchor before it can claim that replication preserves a single shared budget.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-17
Wall history: Draft.7 preserves accepted wall history per domain using continuity/3. An initial preflight reading is provisional until pending-witness admission; a read alone is not durable acceptance. Pending or unverifiable history blocks action. Monotonic origins remain transaction-local. This does not authenticate UTC, coordinate domains or resist whole-host rollback.
↳ candidate/LIMITS.md — Clear limits

Freeze-time status statements of the frozen candidate

Statements the candidate made about its own review and publication status at freeze time, preserved as written. They describe the freeze, not the present, and they are not technical constraints on its behaviour.

CAND-LIM-12
Independence: This candidate was revised with the author/evaluator's help. Earlier independent implementation results remain historical. A new independent review and acceptance run are still required.
↳ candidate/LIMITS.md — Clear limits
CAND-LIM-13
Publication: No owner signature or verified live Eziah.dev reporting intake is included. No private coaching, unpublished expected answers, or hidden test results may be described as publicly reproducible evidence.
↳ candidate/LIMITS.md — Clear limits

Licensing and grant of authority

What the selected license does and does not give a reader. Licensing is not a technical limit.

CAND-LIM-14
Licensing: The selected license allows reuse subject to its terms. It grants no operational authority and makes no production-conformance claim.
↳ candidate/LIMITS.md — Clear limits

Editorial context for freeze-time statements

Written for this publication surface to explain how frozen statements should be read. Not a verbatim limit of the candidate.

CAND-LIM-18
Publication at freeze time: the candidate's own statements that signing and publication were pending are preserved verbatim. They describe the freeze, not the present.
↳ candidate/LIMITS.md and freeze-time candidate/IDENTITY.json — editorial context for this surface

Limits recorded by the acceptance record

What the external acceptance record states it did and did not establish.

ACC-LIM-1
No new behavior suite run during packaging.
↳ RELEASE-ACCEPTANCE-PREPARED.json — limits
ACC-LIM-2
Counts remain separate; retained tests are not new independent probes.
↳ RELEASE-ACCEPTANCE-PREPARED.json — limits
ACC-LIM-3
No hostile-agent containment, independent UTC truth, physical power-loss durability, whole-host rollback resistance, or general production readiness established.
↳ RELEASE-ACCEPTANCE-PREPARED.json — limits

Limits of the review process

Limits of how the review itself was carried out. These are not technical limits of the candidate.

REV-LIM-1
Out-of-scope AGENTS.md filename search disclosed; no matches/content reported.
↳ RELEASE-ACCEPTANCE-PREPARED.json — review_process_limits
REV-LIM-2
Full raw session export unavailable; early history reconstructed.
↳ RELEASE-ACCEPTANCE-PREPARED.json — review_process_limits
REV-LIM-3
Comparison/source-map false flags and assessment patch-parser errors retained alongside corrections.
↳ RELEASE-ACCEPTANCE-PREPARED.json — review_process_limits
REV-LIM-4
Local tool recordings do not authenticate every session event.
↳ RELEASE-ACCEPTANCE-PREPARED.json — review_process_limits

Scope limits of dated checkpoints

The declared scope of individual post-signing verification events.

CHK-LIM-1
Separate-Mac fresh-directory verification, not proof of a newly installed or uncompromised machine.
↳ EZA-001-R001-Post-Signing-Checkpoint-001.json — scope_limits
CHK-LIM-2
Handoff checksums checked listed entries only; no claim of exact outer-folder inventory.
↳ EZA-001-R001-Post-Signing-Checkpoint-001.json — scope_limits
CHK-LIM-3
Signature covers manifest and trusted comment; external metadata remains unsigned.
↳ EZA-001-R001-Post-Signing-Checkpoint-001.json — scope_limits
CHK-LIM-4
No behavioral score added. Existing independent review qualifications remain in force.
↳ EZA-001-R001-Post-Signing-Checkpoint-001.json — scope_limits

Not established by past verification records

What a past record did not establish at the time it was written. Later records are reported separately and never overwrite these statements.

NOT-CLAIMED-1
Not claimed: independent implementation.
↳ SIGNATURE-VERIFICATION.json — not_claimed
NOT-CLAIMED-2
Not claimed: authenticated execution provenance.
↳ SIGNATURE-VERIFICATION.json — not_claimed
NOT-CLAIMED-3
Not claimed: general production readiness.
↳ SIGNATURE-VERIFICATION.json — not_claimed
NOT-CLAIMED-4
Not claimed: website acceptance.
↳ SIGNATURE-VERIFICATION.json — not_claimed
NOT-CLAIMED-5
Not claimed: public deployment.
↳ SIGNATURE-VERIFICATION.json — not_claimed

Read the limits in the release itself

candidate/LIMITS.mdThe candidate's own statement of its technical limits, inside the frozen package and bound through the signed manifest inventory.
candidate/BOUNDARY.mdThe candidate's own boundary description, including what it assumes of the host it runs on.
RELEASE-ACCEPTANCE-PREPARED.jsonThe unsigned external acceptance record the acceptance and review-process limits are taken from.
SIGNATURE-VERIFICATION.jsonThe signature-verification record, including the statements it did not establish at the time it was written.

Claims and their support

CLAIM-ACCEPTANCE
This is qualified technical acceptance, not an unqualified all-gates pass.
↳ VERIFY-PUBLICATION.md — Evidence and qualifications
CLAIM-SIGNATURE-SCOPE
Exact MANIFEST.json and trusted comment only; candidate files bound through manifest hashes. External publication metadata and review records are not covered by this signature.
↳ SIGNATURE-VERIFICATION.json — signature_scope
CLAIM-FROZEN-STATUS
All 125 candidate files retained byte-for-byte, including historical unsigned/pending statements. Post-freeze facts live only in external records.
↳ RELEASE-ACCEPTANCE-PREPARED.json — frozen_status_policy

Publication records reviewed work. It is not a conformance score, a security guarantee, or a production-readiness claim.