Decision Machine — System Manual

The minimum you need to get a portfolio recommendation in under 10 minutes.

1. Check the gate — open portal and confirm ARMED · real_money badge is green. Or: GET /status → effective_armed: true.
2. Fetch your TR portfolio — run python engine/tr_client.py on your local machine, approve the push notification in the TR app. See your current positions and cash.
3. Score candidates — GET /candidates/score returns every candidate ranked by V (velocity). Candidates failing a hard gate show eligible: false.
4. Run a round — POST /ask with your question and the top-scoring tickers. The 20-role council deliberates in 2–5 minutes. A transcript and recommendation appear in the portal.
5. Decide and act — read the transcript (especially the Devil's Advocate dissent). POST /decisions/{round_id}/approve or /reject with a note. Execute manually in the TR app. Never hold through the binary.

1.1 What is the Decision Machine?

The Decision Machine is a governed AI council that produces structured buy / hold / pass recommendations for small- and mid-cap biotech candidates approaching a binary catalyst. It is not an autonomous trading system. You bring research data; the machine scores, debates, and returns a written decision surface; you review and act.

The edge it exploits: public-information mispricing in under-analysed biotech. Position early in a catalyst path, exit 2–4 weeks before the binary readout — never hold through the binary.

1.2 The AIM Grid — 3-Column Architecture

Every part of the system is owned by exactly one column. No column improvises another column's content.

1.3 Core Principles

• Model wins over chat: everything decided goes into the model before moving on. Nothing is built from memory or conversation.
• Top-down discipline: start at top-level processes, go deeper only when needed.
• Rules as data: trading math lives in scoring_config.yaml (Business-owned). The score engine reads it; no role embeds math in its prompt.
• Fail-closed: any missing precondition keeps effective_armed=false. Unreadable state returns HOLD. No silent success.
• Append-only: the board (messages table), the ledger, and all audit logs are never updated or deleted. An existing row is the audit entry.
• Separation boundary: the running engine container never touches the host deploy checkout, never pushes to git, never runs docker compose.

2.1 All 20 Roles

You (CEO) are not a role. You are the final decision-maker who reads the transcript and acts.

2.2 Sonar Roles (5)

Sonar roles call the Perplexity Sonar API (api.perplexity.ai). They are grounded — they search the web in real time and cite sources. They are used for research synthesis, risk assessment, and factual data lookup. They do not hold calculations.

• analyst_desk — writes the candidate brief: thesis, trial design, prior data, dilution risk, price action.
• risk_review — estimates p (probability of re-rating), downside scenarios, tail risks.
• portfolio_manager — assesses fit with current exposure, sizing, correlation to existing positions.
• perplexity_expert — real-time news, recent filings, catalyst calendar, sentiment signals.
• app_support — data lookup, fact-checking, change-process front door, known-problem register.

2.3 Agent Roles (15)

Agent roles call the Perplexity Agent API. They receive tool access (e.g. web_search for cto) and perform structured reasoning tasks. Pinned roles fail startup validation if their model ID is absent from the live catalog.

2.4 The Isolation Principle

Each role reaches its judgement in isolation — it sees only its own prompt and the handover protocol relevant to its task. It does not see another role's private reasoning. This prevents anchoring: independent views aggregated produce a better council than one view echoed back.

2.5 Round Execution — Step by Step

3.1 The Edge Thesis (B1 — locked)

Public-information assembly in under-analysed small/mid-cap biotech: position early in a mispriced catalyst path, then exit 2–4 weeks before the binary readout — never hold through the binary.

Evidence base: ~+14% run-up in the ~120 days before a Phase-3 readout; "buy the rumour, sell the news." The edge is in the asymmetry between public information assembled systematically and the market's inattention to small-cap catalysts.

3.2 Q Score — Quality [0–100]

Q is computed by score_engine.py reading scoring_config.yaml. No role computes Q. Roles hand over the input pieces; the tool does the math.

Q-weight multiplier: q_weight = 0.5 + 1.0 × (Q/100) → range [0.5, 1.5]. Low-Q candidates are penalised in the V ranking.

q_min = 50: candidates with Q < 50 are parked (not ranked, not shown to the council) pending data enrichment.

3.3 V Score — Velocity

V = (p × R_up  −  (1−p) × R_down)  /  T_exit  ×  q_weight

R_down defaults by market-cap band (used only when R_down = UNKNOWN): micro = 25%, small = 20%, mid = 15%.

3.4 Five Hard Gates (auto-reject)

Any candidate failing a hard gate is rejected before scoring and before the council sees it. An UNKNOWN input makes the gate unevaluable → candidate is parked, not rejected.

3.5 Enrichment Tiering (B3)

V decides who gets fresh data, controlling machine load:

• Top 10 by V → enrichment every trading day
• Next 40 → enrichment weekly
• Rest → enrichment monthly
• Cold-start guard: a new discovery gets ≥X full enrichment runs before competing on cadence
• /T_exit already lifts near-catalyst names naturally to the top tier

3.6 Five Information Categories (B4)

Gatherers must cover all five. The minimum daily set (required before a real-money round) is starred:

Data freshness rules (real-money mode): catalyst + price fields max 1 trading day old. Cash runway and shelf flag max 7 days old.

4.1 Overview

The Information column governs how the machine changes itself. Every change to a Business rule, a role prompt, a scoring parameter, or a technology principle routes through a structured lifecycle. Nothing is tweaked live. No informal edits bypass the record.

4.2 Lane Routing — 4 Lanes

When in doubt → Lane 4. Calculation changes (scoring weights, gates, formula, parameters) always get Lane 4 with full CAB and a deferred effectiveness re-check after an observation window.

4.3 Change Lifecycle (9 States)

4.4 CAB Process

The Change Advisory Board is the human governance gate before a change goes live. The CEO chairs. The CAB does not have delegated authority to the machine — the worth-it verdict is always human.

• For calculation changes: full CAB attendance + observation window after go-live before the change is considered confirmed
• For instruction changes: scoped CAB attendance (impacted roles' owners only)
• CAB GO → advances to QUALITY; CAB OBJECT → REJECTED
• CAB record reference (cab_record_ref) is required for gate authorization approval

4.5 Real-Money Gate Authorization (G9)

G9 CAB Quorum Rule (G9-QUORUM-001)

The "Quorum rule applied" field in Artifact M must read: G9-QUORUM-001 — never blank.

4.6 Submitting a Change Request — Step by Step

This section explains exactly what you do, in what order, and who (human or AI) acts at each step. By the end the change is live and verified.

Before you start — two questions to answer

• What column does this touch? Business (trading rules, scoring, edge thesis) · Information (change process, governance) · Technology (code, UI, API, config). Most portal features are Technology. When in doubt, pick Technology.
• Is this an emergency? If the system is broken and live money is at risk, use Lane 1 (Emergency) — submit the CR and act immediately, CAB is retrospective. For anything else, follow the standard flow below.

The full flow at a glance

1. Submit the change request — describe the problem or feature in plain language. You do not need to specify a solution; the AI roles produce that in later phases.
   
   Cockpit: open /cockpit.html → "New Change Request" form → fill in description and column → Submit.
   
   API:

   curl -X POST https://engine.accommodus.com/change-request \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{
       "problem": "I want a dedicated business operations page in the portal.",
       "submitter": "eric-trapman-ceo",
       "impacted_columns": ["Technology"]
     }'

   The response contains "request_nr": "CHG-NNN". Note this — it is the reference for every subsequent call.
2. Run Triage — the app_support AI reads your description and classifies lane, severity, and urgency. This is automatic; you do not write the triage, you only trigger it.

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/run-phase \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"to_phase": "triage"}'

   Check the result: confirm the lane. Most portal/code changes will be classified as Lane 4 — Standard. If the lane is wrong, you can reclassify via POST /change-request/CHG-NNN/lane/reclassify.
3. Run Solution — each impacted role contributes its perspective in isolation. For a Technology change, the developer, it_architect, solution_architect_it_pm, sysadmin_devops, and others each produce their part of the solution without seeing each other's reasoning.

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/run-phase \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"to_phase": "solution"}'

   You do not need to read or approve the solution output — it feeds the next phase automatically.
4. Run Aggregate — the change_manager synthesises all role solutions into one coherent implementation plan. If roles disagreed, the aggregate carries the shortlist.

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/run-phase \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"to_phase": "aggregate"}'

5. Run Cost/Benefit — the change_manager estimates credits consumed vs saved and surfaces the cost case.

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/run-phase \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"to_phase": "cost_benefit"}'

6. CAB review — your decision — this is the only step where you must read the output and make a judgment. Open the CR detail:

   curl https://engine.accommodus.com/change-request/CHG-NNN \
     -H "X-Board-Token: <token>"

   Or open /cockpit.html and click the CR to read the full aggregated plan and cost-benefit summary.
   
   If you approve (CAB GO):

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/advance \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"to_phase": "cab_go", "actor": "eric-trapman-ceo", "note": "Approved."}'

   If you reject (CAB OBJECT):

     -d '{"to_phase": "cab_object", "actor": "eric-trapman-ceo", "note": "Reason here."}'

   A CAB OBJECT moves the CR to REJECTED — this is non-terminal (FND-036): changes.html shows a "Re-route to Solution" button on a Rejected CR, which (as of CHG-043) triggers a real Solution-round AI consult, not just a phase-pointer move. The record remains referenceable as evidence of the original considered decision.
7. Run acceptance tests — after CAB GO the sysadmin_devops role runs a read-only acceptance test pass to verify the preconditions for execution are met.

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/run-tests \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"tier": "PARTIAL"}'

   PARTIAL is the default and sufficient for most changes. FULL runs a deeper suite and spends more API credits.
8. Execute — the developer AI authors the patch — the developer role (claude-opus-4-8) reads the approved aggregate and the current repo files, then authors a structured patch (file paths + full contents). The patch is validated and persisted in the board. The container does not write to disk — that happens on the host in the next step.
   
   Cockpit / changes.html (recommended): find the CR in the list → click it → click Execute (AI — ~90s) in the NEXT STEPS panel. Wait for the PATCH READY board row to appear.
   
   API:

   curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/run-phase \
     -H "X-Board-Token: <token>" \
     -H "Content-Type: application/json" \
     -d '{"to_phase": "execute"}'

   If Execute returns HELD: the developer blocked — read the reason in the timeline. The most common cause is a required file being >64 KB and truncated in the AI's context. See §7.6 for the full mechanism and troubleshooting.
9. Host apply — land the patch on the server — SSH to the server and run the host applier. Replace CHG-NNN with the actual reference (e.g. CHG-005):

   cd /root/dm-engine
   ./engine/host/apply_authored_patch.sh CHG-NNN

   This fetches the persisted patch from the board, writes the files, commits as dm-developer-role, rebuilds the engine, and pushes to origin. The /status endpoint will show the new commit when done. See §7.6 for full details and flags.
10. Verify and close — the reality gate — back in changes.html, advance the CR to Quality Gate and click Run Quality Gate. Or via API:

    curl -X POST https://engine.accommodus.com/change-request/CHG-NNN/verify-and-close \
      -H "X-Board-Token: <token>" \
      -H "Content-Type: application/json" \
      -d '{"tier": "PARTIAL", "actor": "sysadmin_devops"}'

    If the gate passes all probes, the CR advances to LIVE → CLOSED automatically. If it returns HOLD, read the failing probe name and reason, fix the underlying issue, and re-run.

Summary: who does what

Quick-reference: the change lifecycle commands

# 1. Submit
POST /change-request           {"problem": "...", "submitter": "eric-trapman-ceo", "impacted_columns": ["Technology"]}

# 2. Triage (AI)
POST /change-request/CHG-NNN/run-phase    {"to_phase": "triage"}

# 3. Solution (AI)
POST /change-request/CHG-NNN/run-phase    {"to_phase": "solution"}

# 4. Aggregate (AI)
POST /change-request/CHG-NNN/run-phase    {"to_phase": "aggregate"}

# 5. Cost/Benefit (AI)
POST /change-request/CHG-NNN/run-phase    {"to_phase": "cost_benefit"}

# 6. CAB — YOU READ AND DECIDE
GET  /change-request/CHG-NNN              ← read the plan
POST /change-request/CHG-NNN/advance      {"to_phase": "cab_go", "actor": "eric-trapman-ceo", "note": "..."}

# 7. Tests (AI)
POST /change-request/CHG-NNN/run-tests    {"tier": "PARTIAL"}

# 8. Execute — developer writes the code (AI)
POST /change-request/CHG-NNN/execute-plan {"actor": "developer"}

# 9. Verify & close (AI)
POST /change-request/CHG-NNN/verify-and-close  {"tier": "PARTIAL", "actor": "sysadmin_devops"}

# 10. Deploy — YOU commit + push + trigger
git add <files> && git commit -m "feat: CHG-NNN — ..." && git push origin master
ssh root@engine.accommodus.com systemctl start dm-deploy.service

5.1 Infrastructure

Security posture (T2): no public Postgres port; API bound to 127.0.0.1 only; nginx terminates HTTPS; firewall: 22/80/443 only; all tokens are high-entropy (openssl rand -hex 24).

5.2 The Board — Postgres Message Store

The board is the single source of truth. It is append-only, never updated or deleted. A row existing IS the log entry.

-- messages table (board.py)
round_id    TEXT        -- groups messages into a round
from_role   TEXT        -- role that posted this message
phase       TEXT        -- e.g. "analysis", "snapshot_ref", "gate_state_ref"
body        TEXT        -- message content
meta        JSONB       -- structured metadata (snapshot_id, gate_state, etc.)
ts          TIMESTAMPTZ -- auto-set on insert

-- Additional tables
decisions   -- round_id → approved/rejected annotation
ledger      -- one record per round (append-only audit)
change_requests -- change lifecycle rows (one row per state advance)
lane_routing    -- lane classification history per change_ref
findings        -- known-problem register (FND-NNN)

5.3 File Stores (engine/model/ and engine/logs/)

5.4 Web Interfaces

5.5 Engineering Lessons L1–L8 (Technology rulebook T6)

Hard-won rules from real self-builds. Each was a failure once. Never repeat them.

6.1 Authentication Flow

6.2 First-Time Setup

1. Open https://app.traderepublic.com in Chrome and log in.
2. Press F12 → Application → Local Storage → https://app.traderepublic.com. Copy the value of awswaf_session_storage.
3. Run: python engine/tr_client.py --phone +31634132095 --pin 7496 --waf-token <value>
4. Approve the push notification in the TR app within 3 minutes.
5. Session saved to engine/model/tr_session.json. Subsequent runs need no arguments.

Required TR v2 Headers

6.3 Portfolio Data Structure

{
  "positions": [
    {
      "isin": "US...",
      "category": "stock",
      "net_size": 100,
      "average_buy_in": 14.20,
      "current_price": 15.80,
      "unrealized_profit": 160.0,
      "unrealized_profit_pct": 11.27,
      "invested_value": 1420.0,
      "current_value": 1580.0
    }
  ],
  "position_count": 1,
  "cash": {"amount": 500.0, "currency": "EUR"},
  "savings_plans": [
    {"id": "...", "isin": "AT0000652011", "amount": 50, "interval": "monthly", "start_day": 16}
  ],
  "portfolio_status": "ACTIVE",
  "has_invested": true,
  "fetched_at": "2026-06-22T10:00:00Z"
}

7.1 Pre-Round Checklist

[ ] GET /status → healthy=true, roles_count=20, db_connected=true
[ ] GET /status → effective_armed=true, system_mode=RUN
[ ] GET /status → drift=false (version_commit matches expected_commit)
[ ] GET /candidates/score → candidate data fresh (catalyst + price ≤ 1 day old)
[ ] python engine/tr_client.py → current positions visible
[ ] Authorization expiry checked (expires_at > today + 14 days)
[ ] No active e_stop (gate.e_stop=false)

7.2 Running a Round

curl -X POST https://engine.accommodus.com/ask \
  -H "X-Board-Token: <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "ACMR has a Phase 3 readout in 45 days, Q=74, V=0.031. Current portfolio has no open positions. Should we enter, and at what size?",
    "name": "ACMR-20260622"
  }'

The name field is optional — used for cost attribution by name (GET /costs/by-name).

7.3 Acting on a Decision

1. Read the full transcript in the portal or via GET /decisions/latest. Pay attention to the Devil's Advocate and the Risk Review dissents.
2. Check the gate stamp on the decision: confirm effective_armed=true was captured at intake.
3. Approve or reject with a human-authored note:

   curl -X POST https://engine.accommodus.com/decisions/{round_id}/approve \
     -H "X-Board-Token: <token>" \
     -d '{"actor": "eric-trapman-ceo", "note": "Entering ACMR. Council thesis aligns."}'

4. Execute the trade manually in the TR app (search by ISIN, not ticker).
5. Update the portfolio record:

   curl -X POST https://engine.accommodus.com/portfolio \
     -H "X-Board-Token: <token>" \
     -d '{"ticker":"ACMR","entry_date":"2026-06-22","entry_price_usd":14.20,"shares":100}'

7.4 E-Stop and Emergency Procedures

# Set e-stop (instant, independent of armed state)
curl -X POST https://engine.accommodus.com/gate/e-stop \
  -H "X-Board-Token: <token>" \
  -d '{"actor": "eric-trapman-ceo"}'

# Clear e-stop (requires TWO distinct named principals)
curl -X POST https://engine.accommodus.com/gate/e-stop/clear \
  -H "X-Board-Token: <token>" \
  -d '{"cleared_by": "eric-trapman-ceo", "confirmed_by": "second-person-name"}'

7.5 Deploying Changes

All deploys go through the locked dm-deploy.service invariant. Do not run docker compose by hand — it bypasses the truthful commit-stamp step and the reality gate.

Standard deploy (human-authored commit already pushed to origin)

# On local machine — commit and push your changes
git add <files>
git commit -m "feat(CHG-NNN): ..."
git push origin master

# On server — trigger the deploy service (SSH or via cockpit)
systemctl start dm-deploy.service

# Watch progress
journalctl -u dm-deploy.service -f

If dm-deploy.service is in a failed state

systemctl reset-failed dm-deploy.service
systemctl start dm-deploy.service

A systemd service that exits non-zero goes into failed state and cannot be started again until reset-failed clears it.

Verify the deploy

curl https://engine.accommodus.com/status | python3 -c "import json,sys; d=json.load(sys.stdin); print('OK' if not d.get('drift') else 'DRIFT')"

7.6 The EXECUTE → Host Apply Mechanism

When the developer role runs EXECUTE, it does NOT directly write to disk or run docker compose. Instead it authors a structured patch, persists it in the board, and waits. A human-triggered host-side script then fetches, applies, and deploys it. This separation is a locked security invariant (L1 / G-018).

Why the separation exists

The engine runs inside an isolated Docker container with no host mount and no Docker socket. The developer AI can read repo files (delivered read-only as EXECUTE context) but cannot write to the host filesystem or rebuild itself. This prevents an AI role from unilaterally deploying arbitrary code — a human always owns the final trigger.

The two-phase flow

Step-by-step: how to re-run EXECUTE

1. Open changes.html — go to https://engine.accommodus.com/changes.html and enter your board token → Connect.
2. Find the CR — the list shows all open change requests. Click on the one you want (e.g. CHG-005 or CHG-006) to expand its timeline panel.
3. Check the current phase — the CR must be in Executing phase. If it is, you will see a NEXT STEPS section at the top of the panel with an Execute (AI — ~90s) button.
4. Click "Execute (AI — ~90s)" — the developer AI (claude-opus-4-8) reads the approved aggregate and the current repo files, then authors a structured patch. This takes ~90 seconds. A status message appears during the wait.
5. Read the result in the timeline — when done, a new developer execute row appears:

   • PATCH READY — success. The patch is persisted in the board. Note the host command shown at the bottom of the entry (it will say cd /root/dm-engine && ./engine/host/apply_authored_patch.sh CHG-NNN).
   • EXECUTE HELD — the developer blocked and did not produce a patch. Read the reason. Common causes: a file needed for the fix is truncated in context (file > 64 KB), or the fix requires a structural change the AI flags as unsafe. In this case, escalate to a direct fix (see below).
6. SSH to the server and run the host applier — replace CHG-NNN with the actual change reference (e.g. CHG-005):

   cd /root/dm-engine
   ./engine/host/apply_authored_patch.sh CHG-NNN

   This script (see §7.6.1 below) fetches the patch, writes the files, commits, rebuilds, verifies, and pushes to origin. Watch for == done. Confirm /status version_commit == at the end.
7. Advance to Quality Gate — back in changes.html, click Advance to Quality Gate →. Then click Run Quality Gate and check the results. If all probes pass, the CR advances to Live → Closed automatically.

7.6.1 apply_authored_patch.sh — what it does

Location on the server: /root/dm-engine/engine/host/apply_authored_patch.sh

Flags

# Normal (apply + rebuild + push to origin)
cd /root/dm-engine && ./engine/host/apply_authored_patch.sh CHG-005

# Apply and commit, but skip the docker rebuild (manual deploy later)
cd /root/dm-engine && ./engine/host/apply_authored_patch.sh CHG-005 --no-deploy

# Apply, rebuild, but don't push to origin (leaves origin behind — avoid unless intentional)
cd /root/dm-engine && ./engine/host/apply_authored_patch.sh CHG-005 --no-push

What CHG-NNN to use

Pass the change reference of the CR that just ran Execute — the same reference shown in the EXECUTE HELD / PATCH READY board row. For example, if CHG-005 was just executed, run:

./engine/host/apply_authored_patch.sh CHG-005

The script reads the latest persisted patch for that reference. If you run it a second time after the patch was already applied, it will re-fetch and re-apply — which is idempotent for file writes but will attempt a new git commit and rebuild.

8.1 Authentication

All endpoints except /health, /status, /model/data, web pages and /steps/recent require a board token.

# Header (preferred)
X-Board-Token: <token>

# Or query string
GET /candidates?token=<token>

The token is set in BOARD_TOKEN in the server's .env. When empty, the gate is open (local dev only).

8.2 Health & Status

8.3 Council — Rounds & Roles

8.4 Candidates & Scoring

8.5 Portfolio & Timeline

8.6 Decisions & Ledger

8.7 Change Management

8.8 Gate System

8.9 RUN/HOLD Mode

8.10 Costs & Telemetry

8.11 Governance & Config

8.12 Observability

8.13 Math Bundle & Artifacts

8.14 System Model & Question Front Door

Detailed reference for each of the 20 AI roles — what they produce, which model they use, and what questions they answer.

How candidate data gets gathered, how to track what happened in every round, and how to diagnose why fields are still UNKNOWN.

10.1 The Enrichment Pipeline

A candidate starts with all scoring fields set to UNKNOWN and enrichment_count = 0. Before it can be ranked or recommended, it must be enriched — meaning real data must be gathered and written into those fields. The machine uses a 7-role enrichment round to do this.

Why enrichment is separate from scoring

Scoring is deterministic — given known field values, Q and V are always the same. Enrichment is data gathering — roles search the web, parse filings, and estimate probabilities. Separating them means the score engine is a pure function with no side effects, while enrichment can be re-run to refresh stale data.

The 7 enrichment roles

Isolation principle in enrichment

Each role receives only the enrichment question — they do not see each other's answers. The change_manager role is the final aggregator: it receives ALL role outputs and synthesizes them. The change_manager is the only role that sees the full picture and is therefore responsible for writing the final --- ENRICHMENT JSON --- block.

What happens after the round

1. 7 roles run in parallel — each receives the enrichment question independently via POST /ask.
2. change_manager aggregates — it receives all 7 role answers and writes a synthesis ending with --- ENRICHMENT JSON --- followed by a JSON object.
3. Browser parses the JSON block — candidates.html searches the synthesis text for the separator, extracts the JSON object, and immediately POST /candidates to write the fields into the candidate store.
4. Score engine re-runs — the leaderboard refreshes. If enough fields are now known, Q and V are computed and the candidate moves from parked to scored.

The 18 scoring fields

UNEVALUABLE vs scored vs parked

A candidate is parked when any hard gate field is UNKNOWN — the engine cannot determine if it passes. It is rejected when a hard gate check definitively fails (e.g. ruin_risk=true). It is scored when all 5 hard gates pass and both Q and V can be computed. The enrichment_count counter increments each time enrichment fields are written; candidates with enrichment_count = 0 have never been enriched.

10.2 Running Enrichment — Step by Step

1. Open the Leaderboard — navigate to https://engine.accommodus.com/candidates.html. Set your board token at the top.
2. Find a parked or unenriched candidate — candidates with red status dots or status parked need enrichment. A candidate with enrichment_count = 0 has never been enriched.
3. Click "▶ Enrich" on the candidate row — this fires an enrichment round for that specific ticker. The button label changes to Running… (~2–3 min).
4. Watch the status message — the page shows "Council deliberating… (~2–3 min)". The 7 roles run, then change_manager aggregates. You will see "✓ Enrichment complete · fields written" when done.
5. Leaderboard refreshes — the candidate's row updates. If the enrichment round produced all required fields, status changes from parked to scored and Q/V scores appear.
6. Inspect the round in Activity — click Activity ↗ in the navigation bar. Find the most recent round (top of list). Click it to see role dots and field status.

10.3 Activity Inspector — How to Use It

The Activity Inspector (https://engine.accommodus.com/activity.html) is a three-panel diagnostic tool. It shows every round ever run, which roles responded, whether their responses were substantive, and the exact content of each API call.

Left panel: Round list

• Each round shows its ID (truncated), timestamp, question preview, message count, and role count.
• A red dot next to a round means at least one role produced an error or empty response in that round.
• Use the search bar to filter rounds by ID or question text.
• The most recent round is always at the top.

Middle panel: Round detail

Clicking a round opens the detail panel with three sections:

1. Question block — the exact instruction sent to all roles. For enrichment rounds, this is the full enrichment prompt including all 5 data categories and the --- ENRICHMENT JSON --- instruction.
2. Enrichment field status — only visible for enrichment rounds. Shows all 18 scoring fields as colored pills:
   • Green ✓ — field was filled with a real value (not UNKNOWN)
   • Red ✗ — field is still UNKNOWN after this round
   • Grey — enrichment JSON was not detected (not an enrichment round)
   The field display also shows the actual value if it was filled (e.g. days_to_catalyst = 47).
3. Role participation chips — one chip per role that participated. Color indicates response quality:
   • Green dot — good response (≥200 chars, no error keywords)
   • Orange dot — short response (50–200 chars) — may be incomplete
   • Red dot — error or near-empty response (<50 chars, or contains ERROR:/BLOCK:/Exception)
   • Grey dot — role did not participate in this round
   Each chip shows character count and cost. Click a chip to load that role's response in the right panel.

Right panel: Message content

When you click a role chip, the right panel shows:

• Role status summary (good / short / error)
• Exact timestamp and model used
• Cost in USD for that call
• The full raw response text — exactly what the API returned
• For enrichment rounds, the --- ENRICHMENT JSON --- separator is highlighted in orange so you can quickly locate where the structured output begins

10.4 New API Endpoints (added with enrichment)

GET /rounds — example response

{
  "rounds": [
    {
      "round_id": "enrich-IBRX-2026-06-30T14:22:01",
      "ts": "2026-06-30T14:22:01.123Z",
      "question_preview": "Enrich trade candidate IBRX: gather all five information categories...",
      "roles_seen": ["analyst_desk","change_manager","compliance","coordinator","devils_advocate","portfolio_manager","risk_review","trade_expert"],
      "message_count": 10,
      "has_error_roles": []
    }
  ],
  "count": 1
}

10.5 Common Enrichment Problems