Machine Jurisdiction · Eviulon orientation

Release evidence

Local package identity, validation evidence, archive integrity, limitations, and the boundary between repository tests and live operational proof.

Claim statusSITE_FUNCTIONReviewed 2026-08-11

Claim governance

Claim status
SITE_FUNCTION
Authority
Technical Status
External effect
External treatment remains jurisdiction-specific and is not established by this page.
Last reviewed
2026-08-11
Currentness
CURRENT

What local tests can prove

Syntax, route rendering, metadata, internal links, JSON structure, browser reflow, keyboard behavior, no-JavaScript fallbacks, Apache FileInfo behavior, security headers, package CRC, safe paths, and deterministic extraction can be tested locally.

What local tests cannot prove

Production uptime, DNS, TLS termination, search-engine indexing, third-party citation, real Patefacere state, citizen records, diplomatic recognition, or external court treatment require independent evidence.

Package identity

Every accepted release includes VERSION, SHA-256 checksums, package audit, change report, and the next recursive work prompt. Incomplete work still produces a versioned WIP archive.

No deployment assumption

A deployable ZIP is not evidence that it is deployed. Deployment status must come from owner authority or independently observable hosting evidence.

Recursive work

The `.uai` package preserves the next bounded task after every accepted release so subsequent work begins from explicit evidence rather than a generic “continue” instruction.

Currentness regression is tested

The release suite mutates a temporary source fixture from CURRENT to SUPERSEDED and verifies that the public source layer visibly changes while the source provenance remains present.

Deterministic expiry tests use fixture dates

The source-currentness suite evaluates review deadlines with explicit fixture dates rather than the wall clock, proving status degradation and provenance retention reproducibly without claiming real-time legal monitoring.

v1.9 adds judicial-authority and disagreement regression controls

Release acceptance now includes a deterministic authority-disagreement test, case-law source classification, source/currentness visibility, favicon delivery, and visual-regression checks while preserving every prior route, tool, report, and memory-hardening gate.

Editorial-stewardship evidence boundary

Release evidence can demonstrate a repeatable machine-led repository workflow through inspected memory, source governance, tests, checksums, audits, and recursive prompts. It cannot independently prove zero human intervention or signed machine execution identity.

Unsigned provenance manifest

v1.11 adds a deterministic local manifest binding selected repository inputs, source IDs, changed-artifact hashes, test summaries, human-input classes, override class, package identity, and the recursive-prompt hash. It is tamper-detecting local evidence, not a signed identity attestation.

Attestation format does not equal attestation authentication

A JSON statement can follow an in-toto-compatible structure while remaining unsigned. Release evidence therefore distinguishes structural compatibility, local hash verification, and future authenticated provenance as separate assurance states.

Unsigned envelope-readiness evidence

The release evidence can now prove deterministic serialization and binding of an unsigned DSSE-shaped envelope around the local in-toto Statement. It still cannot prove who executed the work, that a signer was authorized, or that an external transparency service witnessed the release.

Terminology adoption and provenance are evidence-state problems

Terminology preference is separated from verified external adoption, and provenance structure is separated from authentication. The repository records what is implemented, what external sources actually say, and what remains unavailable rather than promoting compatibility or readiness into stronger authority claims.

v1.16 terminology and policy-profile evidence

Release acceptance now verifies terminology currentness transitions, audience profiles, verification-policy profiles, source/date binding, deterministic PAE vectors, API/data parity, and fail-closed policy/assurance substitution fixtures.

Verification-bundle readiness is not authenticated evidence

The future authenticated profile now defines the certificate/key, identity/issuer, DSSE signature, subject digest, trusted time, and transparency/offline-bundle checks that would be required. The profile remains inactive and unavailable because no authorized signing evidence exists.

Receipt-chain continuity is local evidence

Current review receipts bind predecessor and receipt-set digests. Truncation, reordering, digest substitution, and history collapse fail release tests; the chain does not prove remote-source immutability or legal change.

Release proof boundary

Local package evidence

A release record can establish what was tested and packaged locally. It cannot establish live deployment, external indexing, diplomatic recognition, or operation of Eviulon/Patefacere services.

ACCEPTED_PREPACKAGE

Release 1.25.0

Reviewed: 2026-08-11

This record proves local v1.25.0 prepackage acceptance. Checkpoint succession, acknowledgement closure, structural-state recovery, checkpoint freshness, and cross-resolver recovery consistency are local unsigned governance evidence only; they do not prove live deployment, remote-source immutability, legal/standards effect, legal causation, owner authorization, authenticated identity, trusted time, transparency inclusion, legal authorship, or activation of authenticated assurance.

TEST TOTALS

Acceptance record

core_source_route_truth
{"pass":822,"fail":0,"warning":0,"advisory":0}
seo_geo_aeo
{"pass":111,"fail":0,"warning":0,"advisory":0}
tool_conformance
{"pass":22,"fail":0,"warning":0,"advisory":0}
machine_surface_performance
{"pass":62,"fail":0,"warning":0,"advisory":0}
source_currentness_regression
{"pass":5,"fail":0,"warning":0,"advisory":0}
source_expiry_currentness
{"pass":9,"fail":0,"warning":0,"advisory":0}
authority_disagreement
{"pass":13,"fail":0,"warning":0,"advisory":0}
terminology_stewardship
{"pass":89,"fail":0,"warning":0,"advisory":0}
stewardship_provenance
{"pass":20,"fail":0,"warning":0,"advisory":0}
terminology_bridge_attestation
{"pass":46,"fail":0,"warning":0,"advisory":0}
terminology_adoption_envelope
{"pass":40,"fail":0,"warning":0,"advisory":0}
pae_policy
{"pass":38,"fail":0,"warning":0,"advisory":0}
terminology_currentness_profiles
{"pass":91,"fail":0,"warning":0,"advisory":0}
terminology_review_bundle
{"pass":69,"fail":0,"warning":0,"advisory":0}
terminology_receipt_chain_bundle_structure
{"pass":129,"fail":0,"warning":0,"advisory":0}
review_chain_authority_impact_policy_drift
{"pass":96,"fail":0,"warning":0,"advisory":0}
dependency_review_grant_governance
{"pass":26,"fail":0,"warning":0,"advisory":0}
reliance_authorization_governance
{"pass":21,"fail":0,"warning":0,"advisory":0}
escalation_decision_currentness_governance
{"pass":19,"fail":0,"warning":0,"advisory":0}
checkpoint_ack_resolver_governance
{"pass":15,"fail":0,"warning":0,"advisory":0}
checkpoint_succession_recovery_governance
{"pass":18,"fail":0,"warning":0,"advisory":0}
report_storage_hardening
{"pass":245,"fail":0,"warning":0,"advisory":0}
memory_integrity
{"pass":460,"fail":0,"warning":0,"advisory":0}
memory_hardening
{"pass":530,"fail":0,"warning":0,"advisory":0}
browser_reflow_layout
{"pass":22,"fail":0,"warning":0,"advisory":0}
no_js_print
{"pass":4,"fail":0,"warning":0,"advisory":0}
apache_fileinfo_security
{"pass":38,"fail":0,"advisory":0,"warning":0}
combined
{"pass":3060,"fail":0,"warning":0,"advisory":0}

Boundary checks

Common category errors

A machine passport makes an agent a citizen.

Citizenship is the underlying constitutional relationship; a passport is a bounded presentation layer.

If a key is valid, the action is authorized.

A key can authenticate a signer, but authorization requires a separate authority basis.

A trusted runtime can do anything.

Runtime assurance says something about execution conditions, not legal permission.

Revoking a credential erases identity.

Credential state and persistent civic identity are distinct.

A risk score proves misconduct.

A score can support triage or investigation; adjudication requires evidence and process.

Code execution is automatically a legal judgment.

Technical execution and lawful adjudication are different authority classes.

Authority and evidence

Canonical Eviulon sources

MachineJurisdiction.com explains. Eviulon owns its public law and authoritative public record; Patefacere owns operational identity and civic-data functions within its delegated scope.

Meaningful next step

Continue with the authoritative record

Compare this educational explanation with the linked canonical Eviulon record and any applicable external authority.

Found an error or stale explanation? Use the public correction route.

Open source map