Normative documents

Full text of ACTIS_STANDARD_v1.md and ACTIS_COMPATIBILITY.md. These are the canonical normative documents for ACTIS v1.

ACTIS v1 — Autonomous Coordination & Transaction Integrity Standard

Version: 1.0
Status: Normative
Protocol identifier: actis/1.0

This document is the single normative entrypoint for the ACTIS standard. It defines integrity verification and replay semantics for signed, hash-linked transaction evidence. It does not define blame, reputation, risk scoring, or settlement rails.

Normative: The body of this document is normative. Examples and developer notes are labeled informative.

Normative Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Goals

ACTIS provides a deterministic and vendor-neutral procedure for verifying the integrity of autonomous transaction evidence.

Non-Goals

ACTIS does not define:

transaction semantics
settlement protocols
dispute resolution
identity systems
reputation systems

ACTIS is an integrity layer, not an application protocol. The following are not part of ACTIS and MUST NOT appear as normative requirements or as keys in the canonical ACTIS verification report:

Blame or fault determination (who is at fault).
Reputation, confidence scoring, or risk tiers.
Risk or actuarial scoring (e.g. outcome probability estimates).
Settlement rails, payment, or money movement.
Claim qualification, disbursement, or underwriting decisions.
Identity or credential verification beyond what is required to verify signatures on the transcript.

Implementations that produce or consume such information MUST treat it as optional, non-ACTIS data (e.g. in separate attachments or clearly labeled non-ACTIS sections).

1. Purpose

ACTIS specifies:

Integrity verification — Whether evidence is cryptographically intact: signature validity, hash-chain validity, and checksum consistency.
Replay — Whether a transcript can be deterministically replayed and produces the same integrity outcomes (e.g. same round hashes, same final hash).

Conformance to ACTIS means a verifier accepts only the inputs and outputs defined in this standard and reports only the fields defined in the verification report schema (§5). Any additional inputs, outputs, or semantics are out of scope.

2. Canonical Identifiers (v1.0.0)

The following identifiers are the normative reference for implementations. They MUST be used when referencing the standard, schema, report format, or bundle format in manifests, tooling, or documentation.

| Identifier | Value | |------------|-------| | ACTIS_STANDARD_ID | ACTIS/1.0.0 | | TRANSCRIPT_SCHEMA_ID | actis.transcript.v1 | | REPORT_SCHEMA_ID | actis.report.v1 | | BUNDLE_FORMAT_ID | actis.bundle.v1 |

Full definitions and stability rules: ACTIS_CANONICAL_IDS.md (repository path: actis/ACTIS_CANONICAL_IDS.md).

3. Formats

3.1 Transcript

A transcript is a JSON document that represents a single negotiation or transaction session.
It MUST be hash-linked: each round (or equivalent unit) MUST include or reference a content hash; the chain MUST link to a final hash.
It MUST include signature material so that each required signer's contribution can be verified.
Schema and version requirements are defined by the transcript schema in use (e.g. a versioned transcript format). ACTIS verifiers MUST validate schema and version before reporting integrity. Strings MUST be interpreted exactly as encoded in the JSON document without Unicode normalization.

3.2 Manifest

A manifest is a JSON document that describes an evidence bundle.
It MUST list the bundle's contents (e.g. file paths or entry identifiers) and MAY list content hashes or other integrity metadata.
For ACTIS-aligned bundles, the manifest MAY include:
- standard: { "name": "ACTIS", "version": "1.0" }
- core_files: array of paths required for ACTIS verification (e.g. ["checksums.sha256", "manifest.json", "input/transcript.json"]).
- optional_files: array of paths that are not required for ACTIS validity.

When standard.name is "ACTIS", verification MUST require only the files listed in core_files (or the default core set). All other files are optional for ACTIS pass/fail.

3.3 Bundle

A bundle is a container (e.g. a ZIP archive) that includes at least:
- A manifest.
- A transcript (e.g. at a path such as input/transcript.json).
- Integrity data (e.g. a checksum file) covering at least the core files.
Additional files MAY be present. If the manifest declares them as optional, they MUST NOT affect ACTIS verification outcome (pass/fail). Verifiers MAY report their presence as a neutral notice (e.g. optional_attachments_present).

4. Verification semantics

Verification outcomes MUST be computed using the algorithms defined in ACTIS_COMPATIBILITY.md.

Checksums: All paths in the manifest's core set (or default core set) MUST be present in the bundle and MUST match the checksums in the bundle's checksum file.
Hash chain: The transcript's hash chain MUST be valid (each round's hash matches recomputation; final hash consistent).
Signatures: All required signatures on the transcript MUST verify. Signatures are over the round's envelope_hash; the construction of envelope_hash is defined in ACTIS_COMPATIBILITY.md §2.
Replay: For v1.0, replay is hash-chain recomputation only: recompute round hashes and final_hash (if present) and confirm equality with claimed values. For v1.0, replay_ok SHALL equal hash_chain_ok. Signature validity is reported via signatures_ok only. See ACTIS_COMPATIBILITY.md for normative algorithms (envelope hash, round/transcript hashing, signature verification, and actis_status decision tree).

A bundle passes ACTIS verification if and only if all of the above hold. No other criteria (e.g. presence or content of optional files) may affect the ACTIS pass/fail result.

5. Verification report schema

The canonical ACTIS verification report is a single JSON object. No key in this object may encode blame, reputation, risk scoring, or settlement. The following keys are normative.

Canonical status field: actis_status is the canonical status field and MUST be one of:

ACTIS_COMPATIBLE
ACTIS_PARTIAL
ACTIS_NONCOMPLIANT

integrity_status is a deprecated compatibility alias retained for legacy implementations. Implementations MAY emit additional diagnostic values in integrity_status (e.g. "TAMPERED", "VALID", "INDETERMINATE"), but these MUST map to one of the canonical actis_status values. Consumers MUST use only actis_status for conformance determination.

Required:

| Field | Type | Description | |-------|------|-------------| | actis_version | string | ACTIS version, e.g. "1.0". | | actis_status | string | Canonical conformance level. One of exactly: ACTIS_COMPATIBLE, ACTIS_PARTIAL, ACTIS_NONCOMPLIANT. Case-sensitive. | | signatures_ok | boolean | All required signatures verified. | | hash_chain_ok | boolean | Hash chain intact. | | schema_ok | boolean | Transcript schema valid. | | replay_ok | boolean | Deterministic replay succeeded. | | warnings | string[] | Neutral warnings (no blame or risk). |

Optional:

| Field | Type | Description | |-------|------|-------------| | integrity_status | string | Deprecated alias. One of: "VALID", "TAMPERED", "INDETERMINATE". When present, MUST match the semantics of actis_status (VALID↔ACTIS_COMPATIBLE, INDETERMINATE↔ACTIS_PARTIAL, TAMPERED↔ACTIS_NONCOMPLIANT or ACTIS_PARTIAL per ACTIS_COMPATIBILITY.md). New implementations SHOULD emit actis_status and MAY omit integrity_status. | | checksums_ok | boolean | Bundle checksums valid for core files. | | recompute_ok | boolean | Recomputed artifacts match bundle (when applicable). | | evidence_refs_checked_count | number | Number of evidence refs checked. | | files_hashed_count | number | Number of files hashed in replay. | | optional_attachments_present | string[] | Namespaces of optional attachments present (e.g. ["vendor/*"]). Informational only. |

Informative example:

json

{
  "actis_version": "1.0",
  "actis_status": "ACTIS_COMPATIBLE",
  "signatures_ok": true,
  "hash_chain_ok": true,
  "schema_ok": true,
  "replay_ok": true,
  "checksums_ok": true,
  "warnings": []
}

6. Compatibility requirements

Implementations that claim ACTIS conformance MUST consume transcripts and bundles that satisfy the format requirements in §3 and MUST produce reports that conform to §5.
Consumers of ACTIS reports MUST treat only the fields defined in §5 as normative for ACTIS; any extra fields are non-ACTIS and must not be used to infer ACTIS pass/fail.
Backward compatibility: Future ACTIS versions that add optional report fields or optional manifest fields MUST remain backward compatible for the core semantics (integrity, replay, report schema). Breaking changes require a new major version of the standard.

Developer note (Informative): separation of concerns

ACTIS defines only neutral verification (integrity, replay, report schema). Conformant implementations MUST NOT require or normatively reference blame, reputation, risk scoring, or settlement.
Vendor-specific extensions (e.g. fault determination, actuarial snapshots, reputation snapshots, underwriting summaries) are optional, non-standard attachments. They MUST be clearly labeled as such and MUST NOT affect ACTIS pass/fail. Bundles and UIs should keep them in separate namespaces or panels from the ACTIS verification result.

Non-normative examples: multiple implementations may exist. ACTIS conformance is determined by the normative documents and the test vector corpus; no specific implementation is required.

ACTIS is an open standard. Contributions and implementations from any party are welcome.

ACTIS v1 — Compatibility and Verification Algorithms

Version: 1.0
Status: Normative
Entrypoint: ACTIS_STANDARD_v1.md

This document defines the normative algorithms for ACTIS v1.0 verification: envelope hash construction, round and transcript hashing, signature verification, and the actis_status decision tree. Implementations MUST follow these algorithms to be conformant.

Normative: The algorithms and decision rules in this document are normative. Formulas and worked examples are labeled informative.

1. Normative Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as in RFC 2119 and RFC 8174.

2. Envelope Hash Construction

envelope_hash is a round-local digest. It is the hash of a canonical JSON serialization of the round's envelope object. The signature in the round is computed over this digest (the 64-character hex string), not over the raw envelope. The envelope object MUST NOT include the signature or the envelope_hash field itself.

2.1 Envelope Object (round-local)

The envelope object is a JSON object containing only the following round fields, with all other round fields excluded:

Included (if present in the round):

round_number
round_type
message_hash
timestamp_ms
previous_round_hash
round_hash (optional in round; include in envelope object only if present in the round)
agent_id (optional; include only if present)
public_key_b58 (optional; include only if present)
content_summary (optional; include only if present)

Excluded:

envelope_hash — excluded so the digest is not self-referential.
signature — excluded; the signature is over the digest of the envelope, not part of the envelope.

No transcript-level fields (e.g. transcript_id, intent_id) are part of the envelope. The envelope is round-local only.

2.2 Serialization and Digest

Build the envelope object from the round by taking only the included keys listed in §2.1 (with the same values as in the round). Omit any key not present in the round.
Serialize the envelope object to canonical JSON per RFC 8785 (JSON Canonicalization Scheme, JCS): deterministic key ordering, no unnecessary whitespace, deterministic encoding of numbers and strings. Implementations MUST use an RFC 8785–compliant canonicalizer (or equivalent that produces the same output). Strings MUST be interpreted exactly as encoded in the JSON document without Unicode normalization.
Compute SHA-256 over the UTF-8 encoding of the canonical JSON string.
Encode the digest as exactly 64 lowercase hexadecimal characters (no prefix, no spaces).

Formula (informative):

envelope_object = { round fields except "envelope_hash" and "signature" }
envelope_hash = to_lower_hex( SHA-256( utf8( canonical_json( envelope_object ) ) ) )

2.3 Signature Binding

The signer computes envelope_hash as above, then signs the envelope_hash value (the 64-character hex string) as UTF-8 bytes. The verifier MUST verify the signature against the envelope_hash value stored in the round. Verifiers MAY recompute the envelope object from the round (excluding envelope_hash and signature), compute the digest, and compare it to the round's envelope_hash to detect tampering of envelope fields.

2.4 Informative example (pseudocode)

Round (excerpt):
  round_number: 0
  round_type: "INTENT"
  message_hash: "a1b2..."
  envelope_hash: "<to be computed>"
  signature: { ... }   // not part of envelope

Envelope object (input to hash):
  { "message_hash": "a1b2...", "previous_round_hash": "c3d4...", "round_hash": "e5f6...", "round_number": 0, "round_type": "INTENT", "timestamp_ms": 1709500000000 }

Canonical JSON string → SHA-256 → 64 lowercase hex → envelope_hash.
Then: signature = Ed25519_sign( utf8(envelope_hash) ).

3. Round and Transcript Hashing

3.1 Round 0 — previous_round_hash (genesis)

For round 0 there is no previous round. The genesis value is:

previous_round_hash = to_lower_hex( SHA-256( utf8( intent_id + ":" + created_at_ms ) ) )

intent_id and created_at_ms are the transcript-level values. The string is the concatenation of intent_id, the literal character :, and the decimal representation of created_at_ms (no leading zeros, no JSON wrapping). No Unicode normalization or trimming is applied to intent_id.

3.2 Round hash (per round)

For each round, the round_hash is the SHA-256 digest of the canonical JSON serialization of the round object excluding the round_hash field itself. RFC 8785 canonicalization MUST be used. The result is 64 lowercase hex characters.

round_object_without_hash = round with key "round_hash" removed
round_hash = to_lower_hex( SHA-256( utf8( canonical_json( round_object_without_hash ) ) ) )

3.3 Chain linkage

For round index i > 0, round[i].previous_round_hash MUST equal the round_hash of round i-1 (or the digest computed from round i-1 as in §3.2 if round_hash is omitted).

3.4 Final hash (transcript)

The final_hash of the transcript is the SHA-256 digest of the canonical JSON serialization of the entire transcript object excluding the final_hash field. The model_context field (if present) is excluded from the object before serialization so that MRM metadata does not affect determinism. RFC 8785 MUST be used. The result is 64 lowercase hex.

transcript_for_hash = transcript with "final_hash" and "model_context" removed
final_hash = to_lower_hex( SHA-256( utf8( canonical_json( transcript_for_hash ) ) ) )

4. Signature Verification

Scheme: ACTIS v1.0 supports Ed25519 only. The signature is a detached Ed25519 signature.
Message signed: The envelope_hash value (64 lowercase hex characters) encoded as UTF-8 bytes. No 0x prefix, no spaces.
Verification: The verifier MUST decode signature.signer_public_key_b58 and signature.signature_b58 (Base58), decode envelope_hash as hex to bytes, and verify that the signature is valid for the public key over the envelope_hash bytes. If the round's public_key_b58 is present, it MUST match signature.signer_public_key_b58 for the round to be considered valid.

5. Manifest and Bundle Rules

Manifest: The bundle MUST contain a manifest.json at the root (or path declared in the bundle format). The manifest MUST include a core_files array: relative paths, unique, forward slashes, no ../, no absolute or drive paths. The minimal ACTIS core set is ["checksums.sha256", "manifest.json", "input/transcript.json"]. See ACTIS_AUDITOR_PACK.md §2 and schema actis/schemas/actis_manifest_v1.json. The checksum file (e.g. checksums.sha256) MUST NOT list itself; it lists the other core files only.

Bundle security:

Checksums apply only to paths listed in core_files. Only those paths are in the ACTIS verification surface. Unlisted files MUST NOT affect actis_status; verifiers SHOULD warn when unlisted files are present.
Core file paths in the manifest MUST be unique. Duplicate archive entries for the same core path MUST result in ACTIS_NONCOMPLIANT. Symlinks for core paths MUST be rejected. Path traversal (e.g. ../, absolute paths, drive prefixes) in core paths MUST be rejected.
ACTIS_COMPATIBLE means the verified core surface (transcript, hash chain, signatures, listed checksums) is intact. It does not imply that the entire archive is safe to execute or trust beyond that surface. Verifiers MAY add a warning (e.g. in warnings) when unlisted or suspicious entries are present.

6. actis_status Decision Tree

Verification MUST derive actis_status from the following (and only the following) checks:

Schema/layout: Transcript conforms to schema; required fields present; bundle layout valid; manifest core files present and unique; no duplicate core path entries; no symlinks or path traversal for core paths.
Hash chain: All round hashes and previous_round_hash linkage valid; final_hash (if present) matches recomputation.
Checksums: All core files listed in manifest match checksums (if checksum file present).
Signatures: All rounds have valid Ed25519 signatures over the round's envelope_hash.

ACTIS_COMPATIBLE: All of (1)–(4) pass.

ACTIS_PARTIAL: (1), (2), and (3) pass; one or more signatures missing or invalid. No other failure.

ACTIS_NONCOMPLIANT: Any of (1)–(3) fail, or any failure other than signature-only.

Implementations MUST NOT use blame, reputation, risk, or settlement to determine actis_status. Only the checks above are normative.

7. References

RFC 2119: Key words for use in RFCs
RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 8785: JSON Canonicalization Scheme (JCS)