What does “deterministic replay” mean in Pluton?

Given the same truth log and artifacts, Pluton re-derives state byte-for-byte across platforms by enforcing canonical encodings and removing non-deterministic sources (floats, unstable iteration, wall-clock ordering in truth).

Is Pluton a database or a filesystem?

Pluton is an object workspace with an immutable event log at its core. It can present database-like queries and filesystem-like artifacts, but the contract is auditability and replayability rather than “mutable tables”.

How is governance handled?

Pluton supports change-control policies (e.g. approvals required). Effects execute post-commit and can be leased, retried, and audited without rewriting truth.

How do we integrate it into an existing stack?

Use the API for ingestion, queries, approvals, and effects; use the CLI for operations (health, verify, export barriers, compaction, GC). Pluton is designed to keep audit evidence close to the data.

Pluton RSE

Replayable State Engine for systems where provenance matters.

Get Started

Determinism First.

Pluton is built on a single governing principle: anything that cannot be deterministically replayed and independently verified cannot be trusted as infrastructure.
The system prioritizes byte-stable representations, explicitly defined durability boundaries, and operator workflows designed to withstand audit, failure, and adversarial scrutiny.

Deterministic Replay

Canonical encoding, stable iteration, and guardrails prevent non-deterministic state from entering the log.

Immutable Truth, Derived State

Truth is append-only. All state is a pure function of recorded events. Rebuild projections at any time from the same source of truth.

Change Control and Approvals

Policy is attached at ingest. Approvals and actors are recorded. Workflow boundaries are enforced without rewriting history.

Content-Addressed Artifacts

Artifacts are stored in CAS and addressed by hash. Event records remain lean. Integrity verification and deduplication are implicit.

Effects as a First-Class Queue

Side effects are queued and executed post-commit. Leases, retries, and indexed status define execution. Implicit background behavior is disallowed.

Integrity Verification

Records are framed with CRC32C for corruption detection and cryptographically chained where required. Artifacts are content-addressed and referenced by SHA-256.

Architecture \ Pluton Kernel

Pluton is structured in explicit layers with a single objective: keep the truth log minimal, unambiguous, and make everything else rebuildable.

Truth Log: Append-only Commit Batches
Artifacts: Content-addressed blobs and diffs.
Indexes: Timeline, graph, and FTS projections
Effects: Post-commit workers with leases and retries.

Truth → State

commit_batch := append_only(events, metadata)
hash_chain   := H(prev_hash || commit_batch)
	
state := fold(evolve, initial_state, truth_log)
	
indexes := rebuild(state, artifacts)
effects := run_post_commit(truth_log, leases, policy)

Determinism Guardrails

- Doubles/Float values prohibited in truth payloads
- Stable map iteration order and canonical encoding rules (JSON/CBOR)
- Cross-platform determinism & hashing/encoding checks (golden vectors)

These constraints are enforced at the truth boundary to guarantee replayable state across platforms.

API & CLI \ PlutonX

Interfaces are built for deterministic payloads and operator ownership, covering ingestion, querying, approvals, post-commit effects, and integrity verification.

HTTP: create an object

POST /api/v1/objects
Content-Type: application/json
Authorization: Bearer <token>

{
  "objectType": "contract",
  "objectId": "2026-001",
  "properties": {
    "status": "draft",
    "value": {"decimal": {"mantissa": "50000", "exponent": 0}}
  },
  "changeControl": {
    "requiresApproval": true,
    "approvers": ["user:alice", "user:bob"]
  },
  "externalEventId": "create-contract-2026-001-v1"
}

CLI: operator essentials

pluton status
pluton objects show obj:contract:2026-001
pluton timeline obj:contract:2026-001 --limit 50
pluton query --format json 'type:contract status:active'
pluton approvals list
pluton effects list --status pending
pluton admin verify

CLI: Run a repo locally

pluton admin init --data-dir ./data --partitions 4 --effects-partitions 4
pluton status
pluton admin verify --data-dir ./data

Operations

Pluton treats verification, consistency boundaries, and rebuilds as first-class operations, so production state can be audited and reproduced, not inferred.

Verify: Validate hash chains and recorded truth.
Export: Create checkpoint barriers for consistent snapshots.
Compact: Control log growth with segment compaction.
GC: Reclaim unreferenced artifacts safely.

What Pluton records

Decision Inputs

Events and metadata in an append-only log.

Provenance

Hashes, positions, and idempotency keys.

Governance

Approval-gated items and their outcomes.

Effects

Leases, retries, and terminal statuses.

Realistic promise

Pluton keeps truth small and deterministic and makes everything else rebuildable. This is the difference between a system that appears auditable and one that is.

Get Started with Pluton

Pluton is core infrastructure with strict invariants. We work directly with teams before access to ensure it’s the right fit.