Deployment-Ready Features

Commit Log

Asset Core treats the commit log as the only atomic write. Every state transition is sealed as an immutable batch that includes both a delta and a post-state snapshot. This keeps the system auditable and prevents hidden state from creeping in.

• Append-only batches with checksums for integrity verification
• Monotonic world sequence per namespace for stable ordering
• Deterministic replay to reconstruct any historical state
• Idempotency keys to safely retry write requests

Namespaces

Namespaces are hard boundaries: each namespace has its own identity space, registries, indices, and commit history. Isolation is enforced in both the write daemon and the read projections. This is how Asset Core supports multi-tenant deployments without cross-namespace state bleed.

• Namespace-scoped class registries and container ID spaces
• Lifecycle states with explicit disable/delete transitions
• Lineage metadata for fork-from-snapshot restores and staged branches
• Per-namespace audit trails and history queries

Write Path

The write path is a deterministic pipeline with explicit sequencing, validation, and durability boundaries. It is intentionally strict so that every commit is reproducible and ordered, even under high concurrency.

• Admission and precheck workers to validate payloads in parallel
• Reorder buffer to preserve deterministic sequencing under concurrency
• Single-writer lane to serialize world mutations
• Append pool and commit-log driver to seal and publish batches

Preflight Validation

Preflight validation simulates a commit without mutating world state or appending to the commit log. It uses the same L2/L3 rules as real commits, so results are commit-equivalent. This is the safest way to validate complex multi-step operations before you commit.

• Fail-fast semantics: stops at the first invalid operation
• Returns validated world sequence and per-op outcomes for planning
• Enables teams to verify complex multi-op changes before submission

Example: a robot planner preflights a pick-and-place sequence against the shared workcell; if it passes, the exact commit will succeed at the same world sequence.

Bulk Operations

Bulk operations provide ordered, atomic batches for cases where shared validation and deterministic planning are required across multiple transfers or moves. They execute in input order and either succeed as a unit or fail without mutation.

• Ordered batch semantics with deterministic execution
• Shared pre-validation to prevent mid-batch failures
• Bulk transfer and move variants for high-throughput workflows

Reverse Commit (Undo Sidecar)

Reverse commit lets you issue a compensating commit using a stored reverse plan from the undo sidecar. The plan is captured at commit time from the undo log plus post-state, and it only applies if the current state still matches the plan’s expected post-state.

• Uses commit_id as the external handle for reversal
• Policy-gated retention and RBAC-controlled access
• Validates expected post-state from the stored plan and fails on conflicts rather than guessing intent
• Audit-ready linkage between original and compensating commits

Authorization

Authorization is evaluated at request admission and per-operation with a default-deny posture. Responses avoid leaking namespace existence. This keeps governance strict while preserving operator-friendly diagnostics.

• Default-deny policy with role-based evaluation
• Namespace-scoped allow/deny bindings
• Non-disclosure posture for unknown namespaces
• Auth failure throttling and optional quota enforcement
• Policy-driven authorization context for varied deployment environments

Log Storage

Asset Core supports multiple commit-log storage and reader configurations to fit different deployment profiles. The commit log interface is modular so deployments can add alternate backends without changing core semantics. This lets you scale storage without rewriting the runtime.

• File-backed durable commit log for production deployments
• In-memory commit log for development and embedded testing
• Memory-mapped reader backend for alternate tailing strategies
• Segment-based storage with checkpoints for fast recovery
• Extensible backend surface for alternate storage media and policies

Observability

The read daemon tails the log to materialize projections and expose freshness metadata. Observability is designed to show you exactly how fresh your reads are and where latency accumulates.

• Freshness and lag metrics tied to world sequence
• History/query endpoints that return sealed commit batches
• Health probes for readiness and catch-up status
• Deterministic replay paths for auditing and incident review
• Projection freshness metadata to bound read-side staleness

For architecture and container fundamentals, see Basics. For runnable demonstrations, see Examples. For deeper technical reference, see Docs. For a real-world walkthrough with full logs, see the Robotic Arm Continuous scenario.