Enaction Engine

Enaction Engine is an experimental set of deterministic, type-safe game-engine library foundations for worlds shaped through perception, affect, intention, action and consequence. It is not yet a complete game engine or runnable host.

The name describes the intended whole: agents and worlds continuously constitute and alter one another through situated action. The current Rust workspace has component-level libraries for timing, trace semantics, package-contract values, and CPU acceleration. They are not yet integrated into a playable game.

Table of Contents

• The invariant everything follows from
• Implemented components
• Intended engine direction
  • Cognition, affect, and conation
• Proving grounds
• Universal Modding Studio
• Using the timing crate
• Repository map
• Current integration evidence
• Build and verification
• Language direction
• Current limitations
• Assurance and readiness
• Licence

The invariant everything follows from

The simulation advances only in whole, equal steps, and render interpolation never feeds simulation state.

Variable frame time must not become simulation input. enaction-time therefore turns elapsed wall time into a count of whole fixed steps and a render-only fraction. A host simulates the whole steps, then may use that fraction to draw continuous values between two completed states. Discrete values are read from the current state, never blended.

Implemented components

These are early, separately testable libraries—not an integrated game runtime. The default Rust test set excludes the Zig-linked native adapter; the dedicated accelerator CI job and just e2e cover that boundary when Zig is available.

Artifact	Implemented behaviour	Evidence and limits
enaction-time	Fixed-step accumulation, whole-step counts, a render-only fraction, DoubleBuffer<T, N>, exact interpolation endpoints, hostile input handling, and a configurable spiral-of-death guard.	Rust unit/doctests. The interpolation design has served in IDApTIK, but this extracted crate has not replaced IDApTIK’s timing code.
enaction-trace	Typed cognitive-affective-conative trace events, ordering and causality, integer milliunit values, belief ascription and retraction queries.	A game-neutral data/query seam; no game consumes it yet and it does not choose agent behaviour.
enaction-contracts	Version and package contract types with validation.	Vocabulary and validation primitives only—not a complete package format, content pipeline, or UMS dependency.
enaction-accelerator	Operation-first capability planning and deterministic CPU reference kernels.	Reference implementation and tests; this is not a general compute framework.
enaction-accelerator-native	Rust adapter for the narrow, versioned Zig accelerator ABI.	Requires the pinned Zig toolchain and is covered by a dedicated CI job; it is not part of the default Cargo member set.

In enaction-time, discontinuities such as teleports, restarts, loads, or resynchronisation use commit followed by snap: the new state first enters the buffer, then stale history is discarded.

Intended engine direction

Enaction Engine is intended to grow into a complete game engine. Its destination includes deterministic simulation; world and event models; agency and embodiment; physics and interaction; rendering and presentation; sound and music; input; networking and multiplayer; persistence and replay; assets and content; host contracts; tools; and Universal Modding Studio integration.

That direction is not a claim that those systems exist today. There is currently no renderer, ECS, audio system, input layer, asset pipeline, networking stack, general AI framework, physical simulation, or complete cognitive, affective, or conative implementation here. New modules must arrive with a real use, implementation, and tests; empty subsystem crates are explicitly disallowed. The staged template-conversion brief and ownership-bounded future-agent prompts are in the developer planning guide; they do not claim those components already exist.

Cognition, affect, and conation

These are sibling dimensions of agency, not competing names for the engine:

• cognition covers perception, attention, memory, belief, inference, and planning;

• affect covers appraisal, mood, atmosphere, trust, fear, attachment, and significance;

• conation covers needs, motives, goals, commitment, inhibition, and action selection.

They operate over host-defined entities, events, worlds, ecologies, and institutions. Games retain their domain ontology and game-specific rules.

Proving grounds

IDApTIK is the first proving ground. Its deterministic, event-sourced Rust core supplied the operational experience behind DoubleBuffer, discontinuity handling, continuous-versus- discrete rendering, replay, and snapshot concerns. FixedStep itself is new engine code and is not yet integrated into IDApTIK.

Chronicles of Slavia is the planned second abstraction test. A facility should not be called general merely because one game can use it: the second game must exercise the boundary without importing IDApTIK-specific ontology into the engine.

Universal Modding Studio

Universal Modding Studio (UMS) will author, generate, validate, preview, and package content through versioned game profiles and contracts. Enaction Engine is runtime infrastructure; it must not depend on the UMS application. Released games consume validated, compiled packages rather than the editor UI. See UMS integration.

Using the timing crate

use enaction_time::{DoubleBuffer, FixedStep};

let mut clock = FixedStep::from_hz(60.0);
let mut buffer: DoubleBuffer<f64, 1> = DoubleBuffer::new();
buffer.prime(&[world.x()]);

for _ in 0..clock.advance(real_dt) {
    world.step();                    // whole steps only
    buffer.commit(&[world.x()]);
}
draw(buffer.sample(0, clock.alpha())); // render-only

Repository map

crates/enaction-time/               fixed-step timing and interpolation
crates/enaction-trace/              typed trace and belief primitives
crates/enaction-contracts/          versioned contract values and validation
crates/enaction-accelerator/        operation planning and CPU reference kernels
crates/enaction-accelerator-native/ Rust adapter for the Zig accelerator ABI
src/interface/Abi/                  Idris2 ABI authority and generator
src/interface/generated/            generated ABI declarations
src/interface/ffi/                  pure-Zig accelerator implementation
verification/                       proof sources, including the Creusot workspace
docs/architecture/                  target architecture and integration boundaries
docs/decisions/                     accepted architecture decisions
docs/status/ROADMAP.adoc            evidence-gated staged direction
.machine_readable/                  policies, metadata, and contracts
build/just/                         recipes imported by the root Justfile
scripts/                            repository and verification gates
tests/                              executable tests and repository checks

Current integration evidence

crates/enaction-time/tests/idaptik_parity.rs covers healthy fixed-step accounting, hostile elapsed time, interpolation, discrete versus continuous state, discontinuities and snapshot/restart interaction. It proves the extracted interpolation boundary; it does not prove that IDApTIK uses FixedStep. IDApTIK still uses Bevy’s accumulator, and this pass deliberately does not replace it.

Enaction is a runtime dependency candidate below games. It does not depend on UMS. An optional UMS preview adapter may be added later, but released games must not depend on the UMS UI. The current IDApTIK appraisal example is game-local; the general enaction-trace seam is new and remains unadopted.

Build and verification

cargo fmt --all -- --check
cargo test --locked --all-targets
cargo clippy --locked --all-targets -- -D warnings
just test-all
just ci

The plain Cargo commands use the default Rust members and do not build the Zig-linked native adapter. just test-all adds the cross-language accelerator conformance gate; just ci also requires the configured formal-proof toolchains. Repository checks and imported task recipes are defined in Justfile and build/just/. EXPLAINME.adoc maps the major claims above to implementation artifacts and checks.

Language direction

Rust is the implementation language now. AffineScript is a future direction only when it has a genuine release artefact and the required typed-Wasm path is ready. Any later port must preserve behaviour and tests, pin its toolchain, and earn adoption through working integration; no AffineScript build is claimed today. See ADR-0004.

Current limitations

• The workspace supplies reusable library foundations, not a frame loop, complete engine runtime, or playable game.

• Determinism of a whole game still depends on the host using deterministic state, ordering, arithmetic, inputs, and side-effect boundaries.

• FixedStep drops excess accumulated time when its step cap is reached; hosts should observe took_shortcut() and decide how to surface degraded timing.

• The no-allocation evidence covers the current fixed-size value representation and its operations, not an instrumented whole-process allocator trace.

• Current extracted code has not yet been validated as a reusable contract by two games.

Assurance and readiness

No SOC 3 report, ISO/IEC 27001 certification, or CIAQ assessment is claimed. Using selected Rhodium Standard Repository (RSR) and estate conventions is not a certification. No CRG component grade has been formally assessed or awarded; see readiness status. Accordingly, this README publishes no compliance or readiness badges.

Licence

Code, configuration, and scripts are GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later). Prose documentation is CC-BY-SA-4.0. Full texts are in LICENSES/; per-file SPDX headers remain authoritative. Long-term attribution uses Quantum-Safe Provenance as described in the provenance exhibit.