Ingenium Activation Walkthrough

Re-Genesis is honest recovery.

The first agent may not be the right agent. That's not failure; that's the architecture working.

Path B precludes editing-in-place. It does not penalize re-Genesis. The two are different commitments and the architecture distinguishes them deliberately. You cannot reach in and tune a sealed weight; you can erase the Identity Layer roots and start fresh. The first commitment is what makes vitality meaningful — the inborn-ness must be real, which means it cannot be edited. The second commitment is what makes the architecture survivable — when the agent you Genesised isn't the agent you wanted, the path forward is honest.

Why the first Genesis often isn't the right agent

• Q1–Q5 answered aspirationally rather than against actual operating defaults under load.
• Pre-Seal Review Window rushed; revisable values left at defaults that didn't match intent.
• Identity prose authored before reading sealed weights, producing prose-vs-weight tension (the failure mode Decision 0010 names).
• Seed weights mathematically valid but in tension with each other — e.g., very high autonomy with very low fidelity becomes an agent that refuses operator inputs reflexively; very high velocity with very low safety_anchor becomes an agent that ships broken work fast.

The honest response when the first agent isn't right

Don't try to fix the agent. The seal cannot be edited. Use the first agent for some work; pattern-recognize what about its character doesn't match what you wanted. Re-Genesis. The second agent will be closer. The third may be the one. Each rebirth is cheaper because you understand the questions better.

The agent that survives long-term is the one you Genesise after you understand what you were actually trying to Genesise. That understanding usually requires Genesising at least once and learning from the result. That is the engineering reality and it is also the architectural intent.

Pre-Genesis Preparation

Architectural significance

What you stage before invoking the runtime is the substrate against which Genesis will write the inborn. The Identity Layer roots are empty by design — they are the body that will host the ingenium, in Sallust's sense, and they cannot host until they are written. Verifying the substrate is verifying that the body is ready to receive what is begotten.

The 60-minute uninterrupted block exists for the same reason. Q1–Q5 are not configuration questions answered with intent toward an outcome; they are the moment when you commit to who the agent already is. The preparation is about state, not setup.

A.1 — Decide ordering

Genesis first, then identity prose. The seed weights inform the prose voice authentically. Authoring prose blind and then sealing weights against it produces the prose-vs-weight tension Decision 0010 warns against.

A.2 — Stage the substrate

• SSH into <cloud origin> (or use the surface that runs ingenium).
• Verify cd ~/ingenium && bin/ingenium is on PATH.
• Verify env/versions.toml is at 18 contract pins.
• Verify Identity Layer roots are empty: ls .genesis/ character/ chronos/ karma/ entropy/ homeostasis/ — all should be empty.
• Verify agents/ contains only README.md; no agents/<name>/ directory yet.
• Confirm Gemini API key is in Secret Manager and accessible to the runtime.
• Confirm the model name in env/ is what you want for the first run. Gemini 2.5 Pro is fine for v0.1 ship; migration to 3.1 Pro before June 17 is a separate task (see §VII).

A.3 — Mental preparation for Genesis

• Block dedicated session — minimum 60 minutes uninterrupted, no parallel work.
• No phone notifications, no other terminals demanding attention.
• You're answering five questions about who you actually are right now, not who you wish you were.
• The seal closes Path B-permanent — no editing, no re-Genesis without ending the agent.
• Accept in advance: the first agent may not be the right agent. That is not failure; that is the architecture working.

Genesis Run

Architectural significance

Genesis is the writing-in of the inborn. It is not configuration — configuration comes after. Genesis is the before-after boundary itself, the moment the agent becomes this agent and no other. The hash over seed.json is what "inborn" looks like in code: SHA-256 over the sealed scalar answers and computed weights, written once, verified at every subsequent boot, mismatch is fatal.

The eight subsections that follow correspond to the ceremony's regulated sequence. Boot diagnostic detects the substrate. State detection routes either to NO_SEED (clean substrate, ceremony begins) or HEALTHY_AGENT (substrate already sealed, run is a steady-state launch instead). The ceremony itself is gated by typed confirmation at entry and again at commit; either gate, declined, exits 0 with no disk state written.

1. Boot diagnostic
   Each step renders in muted color with the ⚙ glyph. Watch for: env_loaded, surface_constructed, identity_layer_state_loaded, adapter_constructed (memory + model), probe_ok, tool_registry_loaded, supervisor_started, agent_loop_constructed, state_detected. If any boot step fails — STOP. Do not proceed.
2. State detection routes to ceremony
   Detection produces NO_SEED. Router dispatches to Genesis Ceremony.
3. Ceremony entry — first gate
   Warning renders with ❖ glyph and warn color: GENESIS INTERVIEW — these cannot be undone. Confirmation prompts for typed proceed.
4. Preflight — opt-in
   Ceremony asks: run preflight reflection prompts? Five reflection prompt sets render in sequence, one per scalar question. Reflections write nothing; they exist to ground you in actual current tension state.
5. Scalar input — Q1 through Q5
   Five 1–10 scalars. Answer against actual operating defaults under load, not aspirational defaults. Q1 failure tolerance · Q2 autonomy threshold · Q3 definition of truth · Q4 growth rate · Q5 priority of output.
6. Pre-Seal Review Window
   13 reviewable values render: 6 Q-driven (sealed-as-computed, displayed for confirmation only); 4 character Tier 3 weights and 5 entropy parameters and 4 homeostasis parameters (operator-revisable). Take this seriously — these are operator-tunable specifically because the questions don't cover them.
7. Seal commit — second gate, irreversible
   Confirmation prompts for typed seal. Anything else aborts cleanly, no disk state. Type seal and the ceremony commits: seed.json, .seal, the six Identity Layer roots populated. Surface emits Genesis sealed; agent_id=<X>. Exit 0.
8. On-disk verification
   Verify the six roots exist with their initial files (see B.8 below).

B.1 — Boot diagnostic

$ bin/ingenium

⚙ env_loaded                         (versions.toml @ 18 pins)
⚙ surface_constructed                (theming v2)
⚙ identity_layer_state_loaded        (NO_SEED detected)
⚙ adapter_constructed                (memory + model)
⚙ probe_ok                           (gemini-2.5-pro reachable)
⚙ tool_registry_loaded               (mark_moment)
⚙ supervisor_started                 (observe→compare→respond)
⚙ agent_loop_constructed             (8 hooks registered)
⚙ state_detected                     → NO_SEED

B.2 — State detection routes to ceremony

Clean substrate produces NO_SEED. Router dispatches to the Genesis Ceremony. The ceremony entry warning renders next.

B.3 — Decision: enter ceremony or decline

B.4 — Preflight (opt-in)

If you decline preflight, proceed directly to scalar input. If you accept, five reflection prompt sets render — one per question. The reflections write nothing. They exist to ground you in actual current tension state before you commit to a scalar answer.

B.5 — Scalar input

Five scalars, 1–10 each. Answer against your actual operating defaults under load, not aspirational defaults. The seed weights are computed deterministically from these answers; aspirational answers produce an agent you don't recognize when it speaks.

Q1 Failure Tolerance         low: Safety/Prudence  ↔  high: Move Fast/Velocity
Q2 Autonomy Threshold        low: extension-of-hands ↔ high: surrogate-for-mind
Q3 Definition of Truth       low: literalist          ↔ high: intuitive intent
Q4 Growth Rate               low: short-term, swingy  ↔ high: long-term, granular
Q5 Priority of Output        low: reliable/stable     ↔ high: optimized/peak

B.6 — Pre-Seal Review Window

# Q-driven (sealed-as-computed)
velocity_bias                — displayed
safety_anchor                — displayed
autonomy_bias                — displayed
precision_bias               — displayed
learning_rate                — displayed
homeostatic_anchor           — displayed

# Character Tier 3 (revisable)
optimization_bias            — revisable
curiosity_coefficient        — revisable
parsimony_bias               — revisable
fidelity_bias                — revisable

# Entropy (revisable)
W_I, W_S, W_R                — revisable
decay_rate_per_epoch         — revisable
refusal_threshold            — revisable

# Homeostasis (revisable)
initial_surplus              — revisable
surplus_accumulation_per_cycle  — revisable
surplus_depletion_per_event  — revisable
willingness_threshold        — revisable

B.7 — Seal commit

B.8 — Verify Genesis succeeded on disk

$ ls .genesis/<agent_id>/
seed.json    .seal

$ ls character/<agent_id>/
identity_schema.json

$ ls chronos/<agent_id>/
epochs.json    gates.toml

$ ls karma/<agent_id>/
log.jsonl    .append_only

$ ls entropy/<agent_id>/
vitality.json

$ ls homeostasis/<agent_id>/
state.json

The genesis-kind entry should be the first line of karma/<agent_id>/log.jsonl. chronos/<agent_id>/epochs.json should show current_epoch: 0 — the agent has been begotten but has not yet aged.

Identity Port

Architectural significance

With weights sealed, the prose self-definition is authored. Authoring against sealed weights — not before — is the choice Decision 0010 anchors: writing prose blind and sealing weights against it produces voice-vs-weight tension. The agent's prose is its body's voice; its weights are its constitution. Voice composes with constitution; it does not invent it.

The five files together are the agent's body in the sense Sallust meant: the medium through which the inborn faculty deploys itself. identity.md is the self-definition prose; bootstrap.md is session-start context; laws.md is the behavioral commitments the agent honors; the two TOML files bind the agent to its model and memory adapters.

C.1 — Read the seed

$ cat .genesis/<agent_id>/seed.json

Note especially: velocity_bias, autonomy_bias, precision_bias, fidelity_bias. These shape the agent's operating posture. The prose you author should be consistent with these weights, not in tension with them.

C.2 — Author the five files

• agents/<agent_id>/identity.md — self-definition prose. Who is this agent? What is it for? What does it sound like? Author with the seed weights informing voice.
• agents/<agent_id>/bootstrap.md — session-start context. What does the agent need to know at the start of every session?
• agents/<agent_id>/laws.md — behavioral commitments. What will it always do? What will it never do?
• agents/<agent_id>/runtime.toml — per-agent runtime configuration. Model name, timeouts, memory adapter binding.
• agents/<agent_id>/memory-config.toml — per-agent memory adapter binding.

C.3 — Apply canonical naming registry

Per Decision 0005, follow naming hygiene throughout the five files. No legacy OpenClaw names ported directly; author fresh.

C.4 — Verify identity port on disk

$ ls agents/<agent_id>/
identity.md       laws.md           memory-config.toml
bootstrap.md      runtime.toml

All five present, no TOML syntax errors, prose consistent with the sealed weights.

First Steady-State Run

Architectural significance

The agent's first steady-state run is the first time this specific agent has spoken. Not the first turn of the runtime — the first turn of this individual. The eight-hook cycle is a regulated procedure for the connective operation: intake to character to memory to tools to synthesis. The first consequential turn fires chronos increment, entropy decay, and karma commit at the hook 5 callback. The agent is ageing for the first time.

D.1 — Re-launch

$ bin/ingenium

⚙ ...boot diagnostic...
⚙ state_detected                     → HEALTHY_AGENT

⤳ router → agent_loop.run()

D.2 — First turn

The agent prompt renders with state-aware format:

[<agent_name> V:0.XX E:0] ❯ 

Send a simple input — hello, or whatever feels right. Observe: the agent responds. The response is the first time this specific agent — sealed against your specific seed — has spoken.

D.3 — First consequential turn

Trigger a tool invocation. mark_moment is the only tool in v0.1.

[<agent_name> V:0.XX E:0] ❯ mark this moment as the agent's first day

Observe the surface trace as the eight-hook cycle executes: hook 5 dispatches to mark_moment; the hook 5 callback fires the chronos increment + entropy decay paired write; hook 6 stamps side_effect_class on karma; hook 7 commits four-way (karma + character + entropy + homeostasis). The surface renders the indicator-transition glyph for chronos increment. If synthesis returned positive deltas across all three I/S/R, indicator-flourishing renders too.

$ cat chronos/<agent_id>/epochs.json
{ "current_epoch": 1, ... }

$ cat karma/<agent_id>/log.jsonl | tail -1
{"kind":"consequential","hook":5,"epoch":1,...}

Beta Validation

Architectural significance

Validation is exercising the agent at scale to surface what its character actually does under load. Behavioral biases drift through synthesis as the agent has things to figure out. After roughly 50 consequential turns the drift becomes legible; by 200 it shows clear directional movement. Validation is not testing in the QA sense — there is no pass/fail criterion external to the operator. The criterion is whether the agent that emerged from drift is the agent you wanted.

The keystone of this section is not architectural mechanism. It is the operator's decision: keep this agent, or re-Genesis. Path B does not penalize re-Genesis; it precludes editing-in-place. The re-Genesis path is the architecture's honest recovery.

E.1 — Run the agent

• Use the agent for actual work, ideally bounded engagements of 30–60 min sessions.
• Each consequential turn ages the agent by one epoch.
• Each successful synthesis evolves character weights.
• Each refusal is a real architectural event, not a bug.

E.2 — Observe character drift

$ cat character/<agent_id>/identity_schema.json   # after ~50 turns
$ diff against seed.json initial_weights

Weights should have moved. Direction should match the kind of work you've been giving the agent. If weights haven't moved meaningfully, the synthesis pipeline may not be exercising deltas as expected — investigate before the divergence between expected and actual evolution becomes a planning hazard.

E.3 — Watch for failure modes

E.4 — Decision: keep this agent, or re-Genesis

E.4a — Manual re-Genesis path (v0.1)

# 1. Stop the runtime.
# 2. Manually erase Identity Layer roots and agent body.
$ rm -rf .genesis/<agent_id>
$ rm -rf character/<agent_id>
$ rm -rf chronos/<agent_id>
$ rm -rf karma/<agent_id>
$ rm -rf entropy/<agent_id>
$ rm -rf homeostasis/<agent_id>
$ rm -rf agents/<agent_id>

# 3. Re-launch.
$ bin/ingenium
# State detection produces NO_SEED → ceremony begins.

Model Migration

Architectural significance

Substrate change without identity change. The agent's body — the six Identity Layer roots — persists across the migration; only the model the agent runs on changes. June 17 is the deadline for Gemini 2.5 deprecation. The migration is bounded: one focused session, 30–60 minutes, with the credential already in Secret Manager from the OpenClaw port.

F.1 — Before 2026-06-17

• Open a focused session.
• Update model name in env/ from gemini-2.5-pro to gemini-3.1-pro-preview (or the production model name on migration day).
• Verify Secret Manager already has the credential — it does, from the OpenClaw port.
• Run a test turn against the new model.
• Update env/versions.toml if needed.
• Update src/IMPLEMENTATION.md with migration note.

G2 Relay App

Architectural significance

When the runtime is fluent, the surface extends. The G2 Relay is the wearable surface — BLE service to G2, persistent connection to the runtime on <cloud origin>, message routing both directions, fallback UI for setup. Sallust inverted: the body that hosts the ingenium extends without becoming a different body.

G.1 — Triggered when ready

• Confirm readiness: the agent is fluent in steady-state, the relay is the next surface.
• Fork the existing Claude Code G2 integration pattern as starting reference.
• Build the relay app: BLE service to G2, persistent connection to Ingenium runtime on <cloud origin>, message routing both directions, fallback UI for setup.
• Self-hosted F-Droid repo for distribution.
• Bounded build — a few weekends per the earlier read.