Every program starts as a sequence of instructions. In the Church Machine you write those
instructions in CLOOMC — the assembly language that compiles directly to the
Church Machine ISA. Here is a minimal program that loads a value and returns it to the caller.
hello.cloomc — your first Church Machine program
; Namespace slot 3 — Boot.Abstr entry pointLLOADCR1, #42; load literal value 42 into CR1RETURNCR1; hand CR1 back to the caller
Understand that CLOOMC instructions map 1-to-1 to Church Machine opcodes
Recognise that CR1–CR15 are the 15 general-purpose capability registers
See how RETURN transfers control back through the call chain
Key idea: The Church Machine executes one instruction per cycle, reads capabilities
from registers, and validates every memory access through the mLoad pipeline before it touches RAM.
Quick Check
What does the RETURN instruction do?
Think about what the opposite of CALL is — one enters an abstraction, the other exits it.
✓ Correct! RETURN hands the result register back up the call chain.
Step 2 of 6
Add Security Boundaries
Conventional code has no built-in memory safety. The Church Machine enforces boundaries using
Golden Tokens — 32-bit unforgeable capability descriptors that carry version,
CRC/parity checks, bounds, and permission bits. No code can read or write memory without a valid token.
Adding a Golden Token boundary
; CR6 already holds a Golden Token for a data lumpMLOADCR2, [CR6+#0] ; validated load — pipeline checks GT firstMSTORE [CR6+#1], CR2; validated store — same boundary checkRETURNCR2
Every MLOAD/MSTORE passes through the 4-stage mLoad capability validation pipeline
The pipeline checks: version, CRC/parity, bounds, and permission bits — in that order
An out-of-bounds or permission-denied access fires a capability fault, not a crash
Domain purity keeps capabilities strictly separate from code and data words
Golden Token format: bits [31:28] version · [27:16] CRC/parity ·
[15:8] upper bound · [7:0] lower bound. The E (execute) bit is the only
permission in a C-List entry; data tokens carry R and/or W.
Quick Check
In what order does the mLoad pipeline perform its four checks?
The page lists the four checks explicitly — start with the most fundamental property of the token and work outward.
✓ Correct! Version first, then the seal, then bounds, then permission bits.
Step 3 of 6
IDE Test
The Church Machine IDE includes a built-in simulator — no FPGA hardware required. Open the
Pipeline view to watch instructions flow through the capability validation stages, then run the
self-test suite to confirm everything is working correctly.
Open the simulator and navigate to the Pipeline tab
Load the Bernoulli example from the Examples drop-down
Click Run and watch the mLoad pipeline stages light up in sequence
Switch to the Dashboard tab and press Self-Test
All test indicators should show green — that is your proof-of-life
What the pipeline view shows: each clock cycle you see the active instruction,
the Golden Token being validated, which pipeline stage it is in (Fetch → Decode → Validate → Execute),
and any fault that fires. Faults trigger the three-tier recovery system automatically.
Which IDE tab lets you watch instructions move through the Fetch → Decode → Validate → Execute stages in real time?
You opened the link card for it just above — it shows the active Golden Token and which stage it is in on every clock cycle.
✓ Correct! The Pipeline tab visualises each stage of the mLoad validation on every cycle.
Step 4 of 6
Add LUMP to Repository
A LUMP is the Church Machine's unit of deployment — a self-describing binary
that packages compiled code, its C-List of capabilities, and a header with CRC/parity metadata.
Once built, you commit the LUMP to the Mum Tunnel repository so others can lazy-load it.
LUMP anatomy (simplified)
; Word 0 — header: magic, version, lump_size; Word 1 — bounds: cw (code words), cc (clist capacity); Word 2 — CRC/parity over words 0–1; Words 3…cw — compiled CLOOMC instructions; Words cw+1…end — C-List: Golden Token slots
Use the Builder tab to compile your CLOOMC source into a LUMP binary
Download the .lump file and its companion sidecar .json
Add both files plus a manifest.json entry to your repository
Run the consistency gate: pytest tests/lump/test_lump_consistency.py -v
Commit — the LUMP is now available for lazy loading by any Church Machine
Which LUMP word holds the CRC/parity value, and what does it cover?
Look at the LUMP anatomy above: the seal appears third in the layout and protects the two words that precede it.
✓ Correct! Word 2 is the CRC/parity value over Words 0–1 (magic/version/size and bounds).
Step 5 of 6
Lazy Load Approval
Church Machine abstractions are loaded on demand — not at boot time. The
Locator intercepts a call to an unloaded namespace slot, fetches the LUMP
from the Mum Tunnel, validates its CRC/parity, and maps it into RAM before execution resumes.
You approve new LUMPs before they gain execute permission.
A floating lump sets ns_slot: null in the manifest — the Locator assigns a slot dynamically
When first called, the Locator fires a lazy-load fault and pauses the calling thread
The IDE shows an approval prompt listing the LUMP token, CRC, bounds, and requested permissions
Approving grants the E (execute) permission and resumes the thread
Rejecting logs the event and returns a capability fault to the caller
Navana Master Controller: Navana manages namespace entries and orchestrates
lazy loading. It is the only component that can mint a new Golden Token — all other code works
with existing, bounded tokens it has been given.
Which permission bit must be granted before a lazy-loaded LUMP can execute?
The approval dialog grants exactly one permission — the one needed to actually run the code inside the LUMP.
✓ Correct! Approving grants the E (execute) permission and resumes the paused thread.
Step 6 of 6
Calibrate MTBF
Mean Time Between Faults (MTBF) tells you how reliable each abstraction is in production.
Every capability fault is logged with its instruction address, faulting mnemonic, and Golden
Token. The IDE aggregates these into a per-abstraction MTBF score that you use to decide
when to patch, retire, or promote a LUMP.
Connect a Wukong Artix-7 board (serial bridge + call-home)
The board sends call-home telemetry to the IDE on every fault event
Open the Dashboard to see live MTBF scores per named abstraction
A dropping MTBF score flags an abstraction for review before it causes a production outage
Update the LUMP, re-run the consistency gate, and re-deploy — MTBF resets for the new version
Call-home protocol: the FPGA sends a compact fault record over UART whenever
the three-tier recovery system exhausts all options. The IDE decodes it, matches it to a namespace
slot, and updates the MTBF table in the Devices view.