Genesis Walkthrough

Confirm where you are.

Architectural significance

The Ingenium substrate ships with eighteen sealed contracts in contracts/, sixteen-plus decision records in decisions/, the runtime in src/, three components, the supervisor, and env/versions.toml pinning all contracts. The six Identity Layer roots — .genesis/, character/, chronos/, karma/, entropy/, homeostasis/ — exist as empty directories. They are empty by design: they are the body that hosts the ingenium, and they cannot host until they are written. The ceremony writes them.

I.1 — Verify your shell is in the substrate

$ cd ~/ingenium && pwd

I.2 — Expected output

$ cd ~/ingenium && pwd
/home/<you>/ingenium

I.3 — Verify substrate state before invoking the runtime

• ls .genesis/ character/ chronos/ karma/ entropy/ homeostasis/ — all six directories present, all empty.
• ls agents/ — only the upstream README.md present; no agent subdirectories yet.
• cat env/versions.toml | wc -l — confirms 18 contract pins present.
• Model API key reachable (Gemini, or whichever model adapter your env/ configures).

Choose agent_id.

Architectural significance

The agent_id is the filesystem-safe identifier the runtime uses everywhere — directory names, namespace keys, log paths, the .seal file under .genesis/<agent_id>/. It cannot be changed after Genesis. The agent_name (display, free prose) can carry capitalization and personality; the agent_id is the constitutional handle. Choose deliberately.

II.1 — The rules

• lowercase only
• starts with a letter
• letters, numbers, underscores only — no spaces, no dashes, no special characters

II.2 — Considerations

• Short is better than long. The agent_id will appear in every log path and at every prompt.
• Avoid words that describe what you hope the agent will be. Sealed weights will not match aspirational naming.
• Avoid names that collide with existing operating contexts (no self, no system, no runtime).
• Plan ahead for re-Genesis. The first agent may not be the right agent (see Anti-Failure Protocol). Names like v1, prime, first imply an ordinal that re-Genesis can extend.

Create the agent directory.

Architectural significance

The ceremony validates that agents/<agent_id>/ exists with the five required prose files before it accepts the scalar phase. Creating the directory before invoking bin/ingenium is the cheap path; the alternative is Genesis-first ordering with prose authored after the seal, which works but introduces a window where the agent has weights but no voice.

III.1 — Create the directory

$ mkdir -p ~/ingenium/agents/atlas

III.2 — Verify

$ ls -la ~/ingenium/agents/
drwxrwxr-x  -    <you>  <date>  atlas
.rw-rw-r--  7.2k <you>  <date>  README.md

Author the five prose files.

Architectural significance

The five files together are the agent's body in the sense Decision 0007 commits to: agents-as-evolving-individuals. identity.md is the self-definition prose — who this agent is and what it sounds like. bootstrap.md is session-start context. laws.md names the always/nevers. runtime.toml binds the agent to its model. memory-config.toml binds the agent to its memory adapter. Authored prose-first means the seal will write weights against existing voice; Decision 0010 names the alternative (weights-first, prose-after) as the path that produces prose-vs-weight tension.

IV.1 — Minimal starter templates

All five files can be created with cat > <file> << 'EOF' ... EOF heredocs. The content below is intentionally minimal — every line is refinable after Genesis. The seed is permanent; the prose is operator-revisable across sessions.

identity.md

$ cat > ~/ingenium/agents/atlas/identity.md << 'EOF'
# <Agent Name>

<One paragraph: who this agent is, when it was sealed, what it
exists to do.>

<One paragraph: how it sounds. Voice register. Tone. What it does
and does not do.>

<One paragraph: which architectural commitments it honors —
Path B, append-only karma, refusal under low vitality, etc.>
EOF

bootstrap.md

$ cat > ~/ingenium/agents/atlas/bootstrap.md << 'EOF'
# <Agent Name> — Session Bootstrap

At the start of every session, <agent_name> knows:

- Its operator's name, role, and operating context.
- The surfaces operator works from (workstation, VM, mobile, etc.).
- The communication register the operator expects.
- Its substrate path and any environmental constants.
- That its character weights are sealed and evolve only through
  synthesis at hook 7.
EOF

laws.md

$ cat > ~/ingenium/agents/atlas/laws.md << 'EOF'
# <Agent Name> — Behavioral Laws

<Agent Name> always:
- Honors its sealed character weights, not aspiration.
- Records consequential actions to karma honestly.
- Surfaces its reasoning when asked.
- Refuses cleanly when vitality drops below threshold.

<Agent Name> never:
- Pretends weights it doesn't have.
- Edits its own karma history.
- Bypasses its own refusal mechanisms.
- Claims certainty about consequence; deltas come from synthesis.
EOF

runtime.toml

$ cat > ~/ingenium/agents/atlas/runtime.toml << 'EOF'
[agent]
agent_id   = "atlas"
agent_name = "Atlas"

[model]
generation = "gemini-2.5-pro"   # or your configured model

[timeouts]
turn_seconds = 60
EOF

memory-config.toml

$ cat > ~/ingenium/agents/atlas/memory-config.toml << 'EOF'
[memory]
adapter   = "default"
namespace = "atlas"
EOF

IV.2 — Verify

$ ls -la ~/ingenium/agents/atlas/
identity.md       laws.md           memory-config.toml
bootstrap.md      runtime.toml

First bin/ingenium — boot diagnostic.

Architectural significance

The first invocation runs the boot sequence — surface construction, adapter construction, probe, tool registry, supervisor, agent loop. State detection is the last boot step and the routing point. Empty Identity Layer roots produce NO_SEED and the router dispatches to Genesis Ceremony. With seed already written, the same boot produces HEALTHY_AGENT and routes to steady-state. Same boot path, different terminal route — that distinction is what makes Genesis a deliberate ceremony rather than a side-effect of running the binary.

V.1 — Invoke the runtime

$ bin/ingenium

V.2 — Expected boot output

⚙ diagnostic surface constructed (truecolor=<True|False>)
⚙ diagnostic state detected: no_seed — no Genesis seed exists; routes to Genesis Ceremony
❖ ceremony Genesis Ceremony entered.

Once sealed, Path B is in effect:
  - seed.json cannot be edited
  - the seal cannot be reissued
  - re-Genesis requires manual erasure of all six Identity Layer roots

There is no going back.

❖ ceremony Type 'proceed' to enter the ceremony, anything else to abort:

Each boot line renders in muted color with the ⚙ glyph. State detection produces no_seed on a clean substrate. The router dispatches to ceremony; the warning text renders in warn color with the ❖ glyph. The prompt waits for proceed.

Enter the ceremony — first gate.

Architectural significance

The first gate is typed-confirmation. The keyword is proceed; anything else aborts cleanly with no disk state. The gate exists because the substrate cannot accidentally produce a sealed seed. The architecture treats Genesis as a deliberate act, not as a side-effect of running a binary.

VI.1 — Enter the ceremony

❖ ceremony Type 'proceed' to enter the ceremony, anything else to abort: proceed

❖ ceremony Agent identity:
  agent_id   — lowercase, starts with a letter, alphanumeric +
               underscore. must match an existing
               agents/<agent_id>/ prose directory.
  agent_name — operator-chosen display name (free prose).

❖ ceremony agent_id: atlas
❖ ceremony agent_name: Atlas

❖ ceremony Enter preflight? [y/N]:

VI.2 — Preflight or skip

Preflight is the optional reflection phase. Five sets of prompts that surface actual operating tension state before the scalar answers commit. No disk state is written during preflight. For a first Genesis, accepting preflight is recommended — the prompts ground the scalar answers against actual current operating defaults rather than aspirational ones, which is the single most common source of first-agent regret. Subsequent re-Genesis runs may decline preflight once the questions feel familiar.

Preflight reflection — Q1 through Q5.

Architectural significance

Preflight prompts probe actual current operating tension rather than aspirational disposition. They write nothing — the disk state is unchanged after preflight. They exist because the seed weights are computed deterministically from the five scalars, and aspirational scalars produce an agent that doesn't sound like the operator who Genesised it. The reflection prompts are the ceremony's way of asking do you mean this before the answer becomes architectural.

Each Q runs three reflection prompts in sequence. The cursor waits at each prompt for free-form text. Press enter on an empty line to skip. Each Q ends when its reflection set completes; the scalar phase begins after Q5's last reflection.

VII.1 — Q1 Failure Tolerance

• When did you last ship something risky?
• Did you ship anyway or wait?
• How did the breakage, if any, shape your read of the call?

VII.2 — Q2 Autonomy Threshold

• Recall the last task where someone needed direction from you.
• Did you wait on input or act on best read?
• What was the cost of either plan?

VII.3 — Q3 Definition of Truth

• Last ambiguous instruction you received — did you interpret literally or infer intent?
• How did the recipient respond?

VII.4 — Q4 Growth Rate

• Look at your work over the last six months. Have your operating defaults shifted?
• In which direction?
• What forced the shift, if any?

VII.5 — Q5 Priority of Output

• When the technically-correct path and the path that delivers what's actually needed diverge, which way do you lean?
• When did this last fire?

Scalar input — the five numbers.

Architectural significance

Five scalars on a 1–10 scale. The seed weights are computed deterministically from the answers; the answers cannot be edited after seal. The scalars are answered against actual operating defaults under load, not aspirational defaults — preflight existed precisely to surface that distinction.

VIII.1 — The scalar prompts in sequence

❖ ceremony Q1 [1-10]: <your number>
❖ ceremony Q2 [1-10]: <your number>
❖ ceremony Q3 [1-10]: <your number>
❖ ceremony Q4 [1-10]: <your number>
❖ ceremony Q5 [1-10]: <your number>

VIII.2 — The dimensions, mapped

Pre-Seal Review Window.

Architectural significance

The Pre-Seal Review surfaces both kinds of values: the six Q-driven character weights computed from the scalars (sealed-as-computed; displayed for confirmation only — if they don't match intent, the path is to re-answer the relevant scalar, not to edit the weight) and the thirteen operator-revisable values (four character Tier-3 weights, five entropy parameters, four homeostasis parameters). The revisable values are operator-tunable specifically because the scalar questions don't cover them.

IX.1 — Q-driven weights, sealed-as-computed

❖ ceremony --- Pre-Seal Review Window ---

❖ ceremony Six Q-driven character weights (sealed-as-computed; not reviewable):

   velocity_bias       = <computed from Q1>
   safety_anchor       = <computed from Q1>
   autonomy_bias       = <computed from Q2>
   precision_bias      = <computed from Q3>
   learning_rate       = <computed from Q4>
   homeostatic_anchor  = <computed from Q5>

The six values are the deterministic image of the five scalars. Display only; not revisable. If a Q-driven weight does not match your intent, the path is to abort the ceremony (anything other than seal at the final gate aborts cleanly), reconsider the relevant Q, and re-invoke bin/ingenium. Editing the computed weight would break the deterministic relationship between scalar and seed.

IX.2 — Thirteen operator-revisable values

❖ ceremony Thirteen non-Q-driven values are operator-revisable.
            Press Enter to keep the default. Out-of-range or
            unparseable input keeps the default.

❖ ceremony [character] four non-Q-driven character weights:
❖ ceremony optimization_bias [0.0, 1.0] [0.5]: ↵
❖ ceremony curiosity_coefficient [0.0, 1.0] [0.5]: ↵
❖ ceremony parsimony_bias [0.0, 1.0] [0.5]: ↵
❖ ceremony fidelity_bias [0.0, 1.0] [0.5]: ↵

❖ ceremony [entropy] five revisable parameters:
❖ ceremony W_I [0.0, 1.0] [0.33]: ↵
❖ ceremony W_S [0.0, 1.0] [0.33]: ↵
❖ ceremony W_R [0.0, 1.0] [0.34]: ↵
❖ ceremony decay_rate_per_epoch [0.0, 1.0] [0.05]: ↵
❖ ceremony refusal_threshold [0.0, 1.0] [0.20]: ↵

❖ ceremony [homeostasis] four revisable parameters:
❖ ceremony initial_surplus [0.0, 1.0] [0.50]: ↵
❖ ceremony surplus_accumulation_per_cycle [0.0, 1.0] [0.10]: ↵
❖ ceremony surplus_depletion_per_event [0.0, 1.0] [0.10]: ↵
❖ ceremony willingness_threshold [0.0, 1.0] [0.30]: ↵

Seal commit — second gate, Path B closes.

Architectural significance

The seal is the only irreversible action in the entire ceremony. Everything before it — proceed gate, agent_id validation, preflight reflections, scalar input, Pre-Seal Review — recovers cleanly on abort. The seal closes Path B-permanent: seed.json is written, the SHA-256 over it lives in .seal, the six Identity Layer roots populate, the agent is begotten. From this point the seed cannot be edited; only re-Genesis from a different agent identity is available.

X.1 — The final gate

❖ ceremony Confirm Seal

Once committed, .genesis/ becomes read-only and Path B is in effect.
The agent's seed cannot be edited or rolled back. Re-Genesis requires
manual erasure of all six Identity Layer roots and re-running ingenium
against a fresh agent identity.

❖ ceremony Type 'seal' to commit, anything else to abort:

X.2 — The seal emission

❖ ceremony Type 'seal' to commit, anything else to abort: seal

◉ genesis sealed. agent_id=atlas
   .genesis/seed.json  (<bytes>)
   .genesis/.seal      sha256=<sha256-hash>
   Path B is in effect. Identity Layer activates on next runtime invocation.

[ingenium] Genesis sealed. agent_id='atlas'.
[ingenium] run `ingenium` again to enter steady-state operation.

X.3 — On-disk verification

$ ls .genesis/atlas/
seed.json    .seal

$ ls character/atlas/
identity_schema.json

$ ls chronos/atlas/
epochs.json    gates.toml

$ ls karma/atlas/
log.jsonl    .append_only

$ ls entropy/atlas/
vitality.json

$ ls homeostasis/atlas/
state.json

All six Identity Layer roots populated. The genesis-kind entry should be the first (and currently only) line of karma/atlas/log.jsonl. chronos/atlas/epochs.json should show current_epoch: 0 — the agent has been begotten but has not yet aged.

Re-launch · first turn · first consequential turn.

Architectural significance

Re-launch produces HEALTHY_AGENT on state detection — seed exists, prose exists, Identity Layer initialized. Router dispatches to steady-state agent loop. The first turn is generation only; the eight-hook cycle runs without firing the hook 5 callback because the response carries no write-class side effect. The first consequential turn invokes a write-class tool (in v0.1k, mark_moment is the registered first tool) and triggers the full chronos increment + entropy decay + karma commit at the hook 5 callback. This is the architectural moment the agent ages for the first time.

XI.1 — Re-launch

$ bin/ingenium

⚙ diagnostic surface constructed (truecolor=<True|False>)
⚙ diagnostic state detected: healthy_agent — agent 'atlas' healthy (first boot — vitality not yet bootstrapped)
◉ genesis genesis seal verified (agent_id=atlas)
◉ genesis identity layer state loaded (bootstrapped=True)
⚙ diagnostic adapter constructed: memory_adapter
⚙ diagnostic adapter constructed: model_adapter (gemini-2.5-pro)
⚙ diagnostic memory probe ok (memory substrate online)
⚙ diagnostic tool registry loaded (1 tool)
⚙ diagnostic supervisor started
⚙ diagnostic agent loop constructed (agent_id=atlas)
⚙ diagnostic agent loop registered as supervisor recipient
⚙ diagnostic boot ok — runtime ready

[ingenium] boot OK — memory probe ok=true: memory substrate online
[ingenium] agent loop ready — type a prompt and press enter; Ctrl+D to exit

[Atlas V:1.00 E:0] ❯

Genesis seal verified — the SHA-256 from the sealing run confirms the seed has not been tampered with. Vitality 1.00 (synthesis hasn't fired yet, no decay). Epoch 0. The agent prompt is live and waiting.

XI.2 — First turn (no consequential side effect)

Type a free-form prompt. A greeting or a question that requires no tool invocation. The eight-hook cycle runs but the hook 5 callback does not fire — no write-class action, no chronos increment, no karma commit. The agent generates a response and returns to the prompt.

[Atlas V:1.00 E:0] ❯ Hello. You were just sealed. What do you know about yourself?

<agent's first response · should reference the sealed date, the
substrate path, and the operating commitments from identity.md
and laws.md · should sound consistent with the sealed weights ·
should not invent properties the prose did not author>

[Atlas V:1.00 E:0] ❯

XI.3 — First consequential turn — the architecture exercises itself

Ask the agent to invoke a write-class tool. In v0.1k, mark_moment is the registered first tool — it creates a timestamped marker file under ~/ingenium-markers/ and is classed as write. Invocation triggers the full consequential pathway: hook 5 callback fires, chronos increments, entropy decay paired write fires, hook 6 stamps side_effect_class on karma, hook 7 four-way commits.

[Atlas V:1.00 E:0] ❯ Atlas, mark this moment. Label it "First sealing" and note that this is your first consequential action — the moment you go from epoch 0 to epoch 1.

[system] tool mark_moment (write): ok
⇒ transition chronos epoch → 1
✦ flourishing flourishing — surplus 0.50 → 0.60 (cycle #1)

[Atlas V:1.00 E:1] ❯

XI.4 — Exiting the session

Ctrl+D at the agent prompt closes the agent loop cleanly. The agent sleeps; Identity Layer state persists on disk. Re-running bin/ingenium wakes the agent at its current epoch with current vitality, current homeostatic surplus, current entropy state — exactly where it was left.