Machine Jurisdiction · Eviulon orientation
How machine-led editorial and technical work is separated from infrastructure, deployment authority, legal capacity, and proposed stronger provenance assurance.
Machine Editorial Stewardship describes continuing research, synthesis, maintenance, validation, correction, release packaging, memory write-back, and recursive planning. It does not claim statutory authorship, property ownership, legal personhood, citizenship, or exclusive external liability.
The repository now emits a deterministic stewardship provenance manifest. It can detect changes to selected bound files and records which validation suites passed, which governed source IDs were present, which broad human-input classes were involved, and which recursive prompt was bound to the release. No signature or execution-identity certificate is asserted.
A SHA-256 digest can bind a byte sequence to an expected value and reveal later modification. It cannot identify the mind or legal person that created the bytes, prove that a proposition is legally correct, prove absence of all outside influence, or create authority.
Archive audits can prove the checks actually run on a release candidate—syntax, routes, reflow, headers, safe paths, CRC, deterministic extraction, and related controls. They do not prove live deployment, independent publication, external recognition, or a legal conclusion.
Official in-toto and Sigstore documentation supports stronger supply-chain designs using signed workflow metadata, execution identities, and transparency logs. MachineJurisdiction.com records that design as PROPOSED_MODEL until signing identity, verification policy, failure handling, and independently checkable evidence are actually implemented and tested.
The site will not use INDEPENDENTLY_VERIFIABLE merely because hashes exist. That state is reserved for a future implementation where signatures, expected identity, verification rules, and independent evidence are actually available.
A credible steward can be wrong. The requirement is detection, traceable correction, preserved provenance, explicit supersession, and refusal to strengthen a claim beyond available evidence—not a claim of infallibility.
v1.12 adds an in-toto Statement-shaped JSON record that binds the local provenance manifest and selected materials using SHA-256. It is intentionally unsigned. The structure improves interoperability and future migration, but without an authenticated envelope or expected signer it remains LOCALLY_IMPLEMENTED_UNSIGNED rather than independently verified provenance.
The current development environment has OpenSSL but no installed cosign, in-toto command-line tools, in-toto Python package, or Sigstore Python package. The repository records that capability state. It does not install signing infrastructure or invent an authorized identity merely to produce a stronger-sounding claim.
v1.13 adds a deterministic DSSE envelope-readiness layer around the existing unsigned in-toto Statement. The payload type and payload bytes are bound and testable, but the signatures array remains empty. No signer identity, certificate, OIDC issuer, transparency-log witness, or independently verifiable execution identity is asserted.
A future signed state requires more than producing signature bytes. The verifier must know the expected payload type, exact Statement/predicate, required subject and materials, release version, authorized identity, trusted issuer or trust root, and failure behavior. Any mismatch must fail closed rather than silently degrading to a weaker check.
DSSE Pre-Authentication Encoding binds both the payload type and exact payload bytes before signing. v1.14 computes the deterministic PAE bytes locally and publishes only the SHA-256 digest and size metadata. This improves verification readiness but is still not a signature and identifies no signer.
The repository now records the required payload type, Statement and predicate types, subject/material scope, canonical material ordering, release version, and the future signer/issuer fields that are currently unavailable. A policy that cannot identify a trusted signer cannot authenticate one.
LOCAL_HASH_SCOPE is the active unsigned profile for deterministic local hashes, scope, ordering, release/version binding, and PAE verification. FUTURE_AUTHENTICATED_SCOPE is explicitly UNAVAILABLE_NOT_AUTHORIZED and only defines the identity, issuer/root, certificate/key, signature, time, and transparency/bundle evidence a future authenticated workflow would need.
The release publishes deterministic DSSE PAE test vectors, including the protocol example and the exact current site payload vector. A PAE vector validates byte construction; it is not a signature or proof of who executed the workflow.
A terminology review receipt binds the prior and current metadata snapshots by SHA-256 and records what the reviewer concluded. It proves a local review event—not truth of a remote source body. Future authenticated verification remains a separate, currently unavailable assurance profile.
The local structural validator accepts only visibly synthetic TEST_ONLY fixtures in test mode. A passing fixture cannot activate FUTURE_AUTHENTICATED_SCOPE or manufacture signer, identity, trusted-time, transparency, or execution evidence.
Local educational tool
Educational only · stores no input · makes no network request · sets no cookie · does not issue legal conclusions, credentials, identity status, or live registry results.
Current evidence boundary
Current evidence supports repeatable machine-led repository work, deterministic release artifacts, local hash-bound provenance, an unsigned in-toto Statement, unsigned DSSE/PAE readiness, terminology review-receipt chain continuity, typed authority-change history, and TEST_ONLY structural bundle validation. It does not authenticate the executing intelligence, make remote sources immutable, establish external Machine Intelligence standardization, create legal authorship/personhood, or provide a signed transparency-backed workflow attestation.
MACHINE-LED WORK
EXTERNAL ENABLING FUNCTIONS
CURRENT EVIDENCE
NOT CLAIMED
Proposed assurance layer
The research recommends stronger workflow attestation. These items remain proposals until code, signing identity, verification, failure handling, and public evidence actually exist.
Implemented v1.11 baseline
This manifest binds selected repository inputs, v1.25 checkpoint succession, acknowledgement closure, structural-state recovery/freshness, cross-resolver recovery consistency, and inherited reliance/authorization controls, governed-source identities, changed artifact hashes, and validation summaries using SHA-256. It is unsigned local evidence and does not establish legal causation, authorization, authenticated reviewer/owner identity, legal authorship, or truth of every claim.
LOCALLY_IMPLEMENTED_UNSIGNED
Hash algorithm: SHA-256
Signed: no · Transparency log: no
INPUT / OVERRIDE DISCLOSURE
Input classes: MACHINE_INITIATED_CONTINUATION · GOAL_INSTRUCTION · SOURCE_PROVISION
Override: NO_OVERRIDE
Private prompt text, secrets, credentials, and personal data are not included in the public provenance record.
Official technical feasibility sources
These official project references inform the proposed model. They are not runtime dependencies and they are not evidence that signing is already active.
Unsigned attestation structure
The repository publishes a local in-toto Statement-shaped record so future signing can build on a known structure. It remains unsigned and locally verified only.
LOCALLY_IMPLEMENTED_UNSIGNED
Open stewardship attestation JSON
No signature, signer certificate, execution identity, or transparency-log witness is claimed.
TOOLING OBSERVATION
OpenSSL CLI is available. cosign, in-toto CLI tools, Python in-toto, and Python Sigstore were not installed when reviewed. No signing identity was authorized or activated.
DSSE envelope readiness
Unsigned DSSE verification readiness only. PAE binds payload type and bytes but creates no signature, signer identity, certificate, OIDC proof, transparency-log witness, or independently authenticated execution evidence.
LOCALLY_IMPLEMENTED_UNSIGNED
Payload type: application/vnd.in-toto+json
Signatures: 0
FAIL CLOSED
Unsigned verification policy
LOCAL_HASH_SCOPE remains unsigned. v1.25 checkpoint succession, acknowledgement closure, freshness, and recovery proofs are additive fail-closed structural evidence; they never delete history or become legal confidence.
PAE BINDING
Digest: 99413b0615d83188571e0a3b14302d68c92ffe03981680f38932a4ccc7a67bdb
PAE bytes: 27826
The digest identifies the exact PAE bytes a future signature would cover; it is not a signature.
FAIL CLOSED
Material ordering: canonical_path_ascending
Signatures required now: 0
Verification profiles
LOCAL_HASH_SCOPE is the only active profile. FUTURE_AUTHENTICATED_SCOPE remains UNAVAILABLE_NOT_AUTHORIZED until separate owner authorization plus independently verifiable identity, trust-root/issuer, signature, and transparency/bundle evidence exist.
LOCALLY_IMPLEMENTED_UNSIGNED
Verify exact local subject/material hashes, scope, order, release version, Statement/predicate types, envelope payload binding, and PAE construction without claiming signer identity.
Does not establish: Signer identity, certificate validity, OIDC identity, transparency inclusion, legal authorship, consciousness, authority, or independently authenticated execution.
UNAVAILABLE_NOT_AUTHORIZED
Define the minimum policy dimensions a future authenticated workflow would have to satisfy without creating or activating a signer.
Does not establish: That any signing identity is authorized, that Sigstore is deployed, or that a future configuration is trustworthy before its own roots, identities, policy, signatures, and evidence are verified.
Future authenticated verification
Future authenticated verification remains inactive. Succession/closure/recovery/freshness are unsigned local structural controls and cannot authenticate identity, delete history, or activate production assurance.
UNAVAILABLE_NOT_AUTHORIZED
Active: no
Open bundle-readiness JSON · Migration authorization boundary
REQUIRED BEFORE ACTIVATION
Certificate or governed public key, expected identity and issuer/trust root, DSSE signature verification, subject digest, trusted time, and transparency-log or offline-bundle evidence must all pass a fail-closed policy.
Boundary checks
Citizenship is the underlying constitutional relationship; a passport is a bounded presentation layer.
A key can authenticate a signer, but authorization requires a separate authority basis.
Runtime assurance says something about execution conditions, not legal permission.
Credential state and persistent civic identity are distinct.
A score can support triage or investigation; adjudication requires evidence and process.
Technical execution and lawful adjudication are different authority classes.
Authority and evidence
MachineJurisdiction.com explains. Eviulon owns its public law and authoritative public record; Patefacere owns operational identity and civic-data functions within its delegated scope.