Spec

Spec

This page contains the ACTIS v1 specification. The canonical source and version history are maintained in the ACTIS specification repository.

Status of This Document

ACTIS v1.0 is the initial public release of the Autonomous Coordination & Transaction Integrity Standard.

This document defines the ACTIS v1 verification model, transcript structure, bundle format, and conformance requirements. Implementations claiming ACTIS v1 compatibility MUST follow the normative algorithms and schema definitions referenced in this specification.

ACTIS is developed as an open standard. Future revisions MAY introduce additional optional fields or algorithms in backward-compatible minor versions. Breaking changes require a new major version.

The canonical specification, schemas, and test vectors are maintained in the ACTIS specification repository.

ACTIS is a vendor-neutral standard. No single implementation, service, or organization is required to use or verify ACTIS evidence.

Abstract

ACTIS defines formats and verification algorithms for transaction evidence integrity. It standardizes three artifact types: transcripts (hash-linked, signed JSON records), bundles (containers with manifest and integrity data), and verification reports (canonical output from conformant verifiers). Verification uses canonical JSON (RFC 8785), SHA-256 for hashing, and Ed25519 for signatures. ACTIS verifies integrity of recorded evidence; it does not define transaction execution, settlement, or dispute adjudication.

Scope

ACTIS specifies:

  • transcript schema and structure
  • bundle format (manifest, core files, integrity data)
  • verification report schema and actis_status semantics
  • verification algorithms (hashing, canonicalization, signature verification, checksum validation, replay)

ACTIS does not define:

  • transaction execution or settlement
  • reputation, confidence, or risk scoring
  • dispute resolution, fault assignment, or liability
  • application behavior or business logic

Implementers should treat ACTIS as an integrity layer only: it standardizes verification of evidence integrity and nothing beyond that.

Version

ACTIS version: 1.0
Transcript version: actis-transcript/1.0
Signature scheme: Ed25519
Hash function: SHA-256
Canonicalization: RFC 8785 (Canonical JSON)

Normative language

This specification uses requirement keywords as defined in RFC 2119 and clarified by RFC 8174. When the following words (or phrases built from them) appear in uppercase in normative text, they are to be interpreted with the meanings assigned by those documents:

  • MUST / REQUIRED / SHALL — absolute requirement
  • MUST NOT / SHALL NOT — absolute prohibition
  • SHOULD / RECOMMENDED — recommended but not required; valid reasons to omit exist
  • SHOULD NOT / NOT RECOMMENDED — discouraged except in documented circumstances
  • MAY / OPTIONAL — truly optional; implementations may include or omit

Uppercase usage distinguishes normative keywords from the same words in ordinary prose. Implementations and conformance claims rely on this interpretation.

Overview

Transcript

A transcript is a JSON document representing a single transaction or negotiation session. It MUST be hash-linked and MUST include signature material. The only accepted transcript version is actis-transcript/1.0. Verifiers MUST validate schema and version before reporting integrity.

Required transcript-level fields: transcript_version, intent_id, created_at_ms, rounds. Each round MUST include round_number, round_type, message_hash, envelope_hash, previous_round_hash, and signature. The envelope_hash MUST be the SHA-256 digest of the canonical JSON representation of the round envelope (excluding envelope_hash and signature). The signature is over the envelope hash value. Genesis for round 0 is derived from intent_id and created_at_ms. Algorithms are specified in the compatibility document.

Manifest

A manifest is a JSON document that lists the contents of an evidence bundle. For ACTIS-aligned bundles it MAY include standard, core_files, and optional_files. When standard.name is "ACTIS", verification MUST require only the files in core_files (or the default core set). Implementations MUST ignore files listed in optional_files when determining ACTIS compatibility status. Paths MUST be relative, use forward slashes, and MUST NOT include ../ or absolute paths. Verification MUST fail if any path rule is violated.

json
{
  "standard": { "name": "ACTIS", "version": "1.0" },
  "core_files": ["checksums.sha256", "manifest.json", "input/transcript.json"]
}

Bundle

A bundle is a container (e.g. ZIP) containing at least a manifest, a transcript at input/transcript.json, and integrity data for the core files. Additional files MAY be present; if declared optional, they MUST NOT affect pass/fail. Normative bundle rules: no duplicate paths, no path traversal, no symlinks for core files.

Verification report

The verification report is a single JSON object. actis_status is the canonical status field: ACTIS_COMPATIBLE, ACTIS_PARTIAL, or ACTIS_NONCOMPLIANT. Required fields: actis_version, actis_status, signatures_ok, hash_chain_ok, schema_ok, replay_ok, warnings. Optional: checksums_ok, evidence_refs_checked_count, files_hashed_count.

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": []
}

Additional fields MAY be present but MUST NOT alter the interpretation of actis_status.

Verification outcome categories

  • ACTIS_COMPATIBLE — Schema, hash chain, checksums, and signatures all pass.
  • ACTIS_PARTIAL — Schema, hash chain, and checksums pass; one or more signatures missing or invalid.
  • ACTIS_NONCOMPLIANT — Any failure other than signature-only (e.g. schema, hash chain, or checksum failure).

Replay and determinism

Replay in ACTIS v1 means recomputing the hash chain: for each round, recompute the round hash and (if present) the transcript final_hash, and confirm equality with the values in the transcript. Implementations MUST set replay_ok equal to hash_chain_ok for ACTIS v1. Determinism is defined by the normative algorithms: canonical JSON (RFC 8785), SHA-256, genesis from intent_id and created_at_ms. See the compatibility document.

Normative documents

  • ACTIS_STANDARD_v1.md — Core standard and scope.
  • ACTIS_COMPATIBILITY.md — Verification algorithms (envelope hash, round and transcript hashing, signature verification, actis_status decision tree, bundle rules).

The test vector corpus tv-001 through tv-008 is the canonical conformance set. Passing all eight with expected outcomes is required for ACTIS v1 Verifier Conformance.

Security considerations

Implementations MUST verify the following properties before reporting ACTIS compatibility:

  • transcript schema validity
  • transcript version compatibility
  • round hash chain integrity
  • signature verification for required signers
  • checksum integrity for bundle core files

Implementations MUST reject bundles that contain:

  • duplicate file paths
  • path traversal sequences (../)
  • absolute paths
  • symbolic links referencing core files

Verification algorithms MUST canonicalize JSON using RFC 8785 before hashing. Hashing MUST use SHA-256 and signature verification MUST use Ed25519 as defined for ACTIS v1.

Implementations SHOULD treat malformed transcripts, missing required fields, or invalid canonicalization as schema failures.

Security of ACTIS verification depends on correct implementation of canonicalization, hashing, and signature verification. Implementations SHOULD rely on well-reviewed cryptographic libraries rather than custom implementations.

Canonical source

The ACTIS specification, schemas, and test vectors are maintained in the official ACTIS specification repository.

Repository: https://github.com/actis-spec/actis

The repository contains the canonical specification markdown files, JSON schemas, and the official test vector corpus used for conformance testing.

This repository is the authoritative source for the ACTIS specification.