Run a small example, then plan the service you want to build.
Run an example
Append a record and read it back. No cloud setup is needed.
You need the Cargo toolchain and access to the core repository; public checkout instructions are not yet available here. Create an example beside your mainframe checkout:
cargo new log-example
cd log-example
Replace src/main.rs and Cargo.toml with the files below, then run cargo run. Adjust the dependency path if your checkout is elsewhere.
Success: the program exits without an error after asserting that the read matches the append. This in-memory log loses its contents when the process exits.
Build your service
Choose your data, rules, and recovery strategy. The planner saves a design on this device and produces an implementation brief.
BEGIN WITH THE STATE YOU WANT TO SHARE
What are you building?
Choose an example, then edit it to match your service.
DEFINE HOW CHANGES WORK
What rules must changes follow?
Mainframe puts commands in order. Your code decides which changes
are allowed—for example, a purchase cannot make stock
negative.
◈
PLAN FOR FAILURES
How will the service recover?
Choose where the log lives and how to rebuild local data after
a restart.
Advanced recovery options
YOUR IMPLEMENTATION PLAN
Review and download your plan.
The plan includes your data model, application rules, recovery
steps, and tests. Use it to guide implementation yourself or
with a coding agent.
The plan describes work to implement and test. It does not
build or validate the service for you.
THINGS TO IMPLEMENT
How this plan works
ORDERED HISTORYposition →
≡
SHARED LOGread_next(position)
↓
⌘
KeyValueEngineapply(entry, context)
↓
▤
APPLIED STATEsame entries, same data
⊣
CHECKPOINTcheckpoint + replay
IN MEMORY · VOLATILEFIG. 01 / APPLY PATH
Step 1 of 4
Implementation planMARKDOWN
Complete engine example
Run three local engine replicas over one in-memory log. Two commands target version 7; the first succeeds and the second conflicts. A retry reuses its result.
This example assumes access to the core repository; public checkout
instructions are not yet available here. With an existing
mainframe checkout, create a crate beside it with
cargo new database-example. Replace its Cargo.toml and
src/main.rs with the files below, then run
cargo run inside it. Adjust the dependency path if your
checkout lives elsewhere.
Loading the example…
Expected: all three replicas print
name = Grace · v8; A accepted, B conflicts, followed by a
successful retry check and a check that conflicting request IDs do not stop later entries. Proposals are deliberately ordered in this
example to make the result reproducible.
What this runs
Actual Engine and EngineStack calls, JSON command encoding,
version checks during apply, request deduplication, and local
state protected by a mutex. The log and all replicas live in one
process.
What persistence adds
The mutex gives local atomicity, not crash durability. A
persistent engine must atomically save state, results, and
progress; restore compatible snapshots; retain required log
entries; and use a validated persistent backend. Fresh reads need
a consistent tail check and catch-up.