Draft capability entry (reuse-surface REUSE-WP-0017-T04, cohort 1)

Honest first-pass maturity vector grounded in README/docs/tests present
in this repo; no invented evidence. Flagged for human review before
publish. See reuse-surface history/2026-07-06-coverage-classification.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.claude/rules/agents.md

@@ -0,0 +1,20 @@
+## Kaizen Agents
+
+Specialized agent personas available on demand via the state-hub MCP.
+
+**Discover:** `list_kaizen_agents()` — returns all agents with name, description, category
+**Load:** `get_kaizen_agent("tdd-workflow")` — returns full instructions; read and follow them
+
+Common agents:
+
+| Agent | Category | When to use |
+|-------|----------|-------------|
+| `tdd-workflow` | testing | Step-by-step TDD8 workflow for any feature |
+| `code-refactoring` | quality | Code quality analysis and safe refactoring |
+| `test-maintenance` | testing | Diagnose and fix failing tests |
+| `requirements-engineering` | process | Prevent interface/mock mismatches upfront |
+| `keepaTodofile` | process | Maintain TODO.md during work |
+| `project-management` | process | Track status, determine next steps |
+| `datamodel-optimization` | quality | Optimize dataclasses and data structures |
+
+All 17 agents: call `list_kaizen_agents()` for the full list.

.claude/rules/architecture.md

@@ -1,20 +1,8 @@
-# Architecture Notes
+## Architecture
 
-The intended architecture is layered:
+<!-- TODO: Describe the key design decisions and component structure.
+     Key modules, data flows, external integrations, state machines, etc. -->
 
-```text
-markitect-tool     -> syntax layer
-kontextual-engine  -> system/runtime layer
-infospace-bench    -> application layer
-```
+## Quick Reference
 
-The first implementation should establish repo shape before service shape:
-
-- `infospaces/` for concrete infospace projects
-- `schemas/` or dependency references for artifact schemas
-- `workflows/` for application-level workflow definitions
-- `reports/` for evaluation and inspection outputs
-- `docs/` for migration and design records
-
-Use direct dependencies on lower-layer projects only where they clarify the
-boundary. Avoid copying infrastructure wholesale from `markitect-main`.
+`~/state-hub/mcp_server/TOOLS.md` — MCP tool reference

.claude/rules/credential-routing.md

@@ -0,0 +1,50 @@
+# Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=infospace-bench` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`

.claude/rules/first-session.md

@@ -0,0 +1,38 @@
+## First Session Protocol
+
+Triggered when `get_domain_summary("communication")` shows **no workstreams**.
+The project is registered but work has not yet been structured.
+
+**Step 1 — Read, don't write**
+- `~/the-custodian/canon/projects/communication/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/communication/roadmap_v0.1.md` — planned phases
+- Scan repo root: README, directory structure, existing code or docs
+
+**Step 2 — Survey in-progress work**
+Look for TODOs, open branches, half-finished files. Note done vs. started but incomplete.
+
+**Step 3 — Propose workstreams to Bernd**
+Propose 1–3 workstreams — each a coherent strand, weeks to months, anchored to a
+roadmap phase. **Wait for approval before creating.**
+
+**Step 4 — Create workplan file first, then DB record (ADR-001)**
+```
+workplans/IB-WP-NNNN-<slug>.md   ← write this first
+```
+Then register in the hub:
+```
+create_workstream(topic_id="5571d954-0d30-4950-980d-7bcaaad8e3e2", title="...", owner="...", description="...")
+create_task(workstream_id="<id>", title="...", priority="high|medium|low")
+```
+
+**Step 5 — Record the setup**
+```
+add_progress_event(
+    summary="First session: structured communication into N workstreams, M tasks",
+    event_type="milestone",
+    topic_id="5571d954-0d30-4950-980d-7bcaaad8e3e2",
+    detail={"workstreams": [...], "tasks_created": M}
+)
+```
+
+<!-- Delete or archive this file once past first session -->

.claude/rules/repo-boundary.md

@@ -1,19 +1,8 @@
-# Repo Boundary
+## Repo boundary
 
-`infospace-bench` owns application-level infospace usage. It must not absorb
-lower-layer responsibilities.
+This repo owns **infospace-bench** only. It does not own:
 
-Belongs here:
-
-- Infospace definitions and examples
-- Application workflow definitions
-- Evaluation and inspection reports
-- Migration notes from `markitect-main`
-- Workplans for applied infospace capabilities
-
-Belongs elsewhere:
-
-- Markdown parsing and structural syntax primitives: `markitect-tool`
-- Runtime persistence and orchestration: `kontextual-engine`
-- LLM provider abstraction: `llm-connect` or equivalent
-- Final production domain artifacts: the relevant domain repo
+<!-- TODO: List what belongs in adjacent repos, e.g.:
+- SSH key management → railiance-infra/
+- State hub code     → state-hub/
+-->

.claude/rules/repo-identity.md

@@ -1,11 +1,5 @@
-# Repo Identity
+**Purpose:** Application-layer workspace and service for concrete structured knowledge spaces; scoped successor to markitect-main infospace work.
 
-- Project: `infospace-bench`
-- Domain: `markitect`
-- State Hub repo slug: `infospace-bench`
-- State Hub topic ID: `5571d954-0d30-4950-980d-7bcaaad8e3e2`
-- Purpose: application-layer workspace and service for concrete infospaces.
-
-This repo is a scoped successor to the application-level infospace work in
-`markitect-main`. It should preserve and extend the parts that help create,
-evaluate, inspect, and evolve real knowledge spaces.
+**Domain:** communication
+**Repo slug:** infospace-bench
+**Topic ID:** 5571d954-0d30-4950-980d-7bcaaad8e3e2

.claude/rules/session-protocol.md

@@ -1,8 +1,85 @@
-# Session Protocol
+## Session Protocol
 
-1. Read `SCOPE.md`, `INTENT.md`, and the active workplan before making changes.
-2. Check `git status --short` and preserve user changes.
-3. Use State Hub as the coordination record when available.
-4. Keep repo artifacts traceable: workplans, docs, configs, metrics, and outputs
-   should explain what changed and why.
-5. Prefer narrow, inspectable changes over broad platform work.
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
+
+**Step 1 — Orient**
+
+Read the offline-safe brief first — it works without a live hub connection:
+```bash
+cat .custodian-brief.md
+```
+Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
+```
+get_domain_summary("communication")
+```
+If MCP tools are unavailable in the current agent session, use the REST API:
+```bash
+curl -s "http://127.0.0.1:8000/state/summary" | python3 -m json.tool
+```
+If the hub is offline: `cd ~/state-hub && make api`
+
+**Step 2 — Check inbox**
+With MCP tools:
+```
+get_messages(to_agent="infospace-bench", unread_only=True)
+```
+Mark read with `mark_message_read(message_id)`. Reply or act on coordination
+requests before proceeding.
+
+Without MCP tools:
+```bash
+curl -s "http://127.0.0.1:8000/messages/?to_agent=infospace-bench&unread_only=true" \
+  | python3 -m json.tool
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+**Step 3 — Scan workplans**
+```bash
+ls workplans/
+```
+For each file with `status: ready`, `active`, or `blocked`, note pending
+`wait`/`todo`/`progress` tasks.
+
+**Step 4 — Present brief**
+
+1. **Active workstreams** for `communication` — title, task counts, blocking decisions
+2. **Pending tasks** from `workplans/` + any `[repo:infospace-bench]` hub tasks
+3. **Goal guidance** — if `goal_guidance` in summary:
+   - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
+   - `alignment_warnings`: flag if active work is not aligned with current goal
+4. **Suggested next action** — highest-priority open item
+5. **SBOM status** — flag if `last_sbom_at` is unset for this repo
+
+If no workstreams: follow First Session Protocol (`first-session.md`).
+
+**During work:** `record_decision()` · `add_progress_event()` · `resolve_decision()`
+
+> State Hub is a *read model*. Bootstrap tools (`create_workstream`, `create_task`)
+> are First Session Protocol only. Work structure belongs in repo files (ADR-001).
+
+**Session close:**
+With MCP tools:
+```
+add_progress_event(summary="...", topic_id="5571d954-0d30-4950-980d-7bcaaad8e3e2", workstream_id="<uuid>")
+```
+Without MCP tools:
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{"topic_id":"5571d954-0d30-4950-980d-7bcaaad8e3e2","workstream_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
+```
+If workplan files were modified, ensure the local copy is up to date first:
+```bash
+git -C <repo_path> pull --ff-only
+cd ~/state-hub && make fix-consistency REPO=infospace-bench
+```
+For repos where implementation runs on a remote machine (e.g. CoulombCore),
+use the combined target which pulls before fixing:
+```bash
+cd ~/state-hub && make fix-consistency-remote REPO=infospace-bench
+```
+**C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
+will sync the file to match DB.  **C-16** (repo behind remote) blocks all writes
+until you pull — intentional to prevent clobbering remote progress.

.claude/rules/stack-and-commands.md

@@ -1,17 +1,19 @@
-# Stack And Commands
+## Stack
 
-The implementation stack is not established yet. Until it is, prefer
-documentation and small scaffold changes over choosing frameworks prematurely.
+<!-- TODO: Fill in language, frameworks, and key dependencies -->
+- **Language:**
+- **Key deps:**
 
-Useful commands:
+## Dev Commands
 
 ```bash
-git status --short
-rg --files
-```
+# TODO: Fill in the standard commands for this repo
 
-State Hub registration was completed with:
+# Install dependencies
 
-```bash
-/home/worsch/the-custodian/state-hub/.venv/bin/custodian register-project --domain markitect --path /home/worsch/infospace-bench
+# Run tests
+
+# Lint / type check
+
+# Build / package (if applicable)
 ```

.claude/rules/workplan-convention.md

@@ -1,9 +1,40 @@
-# Workplan Convention
+## Workplan Convention (ADR-001)
 
-- Workplans live in `workplans/`.
-- Prefix new workplans with `IB-WP-`.
-- Use YAML frontmatter with `id`, `type`, `title`, `domain`, `repo`, `status`,
-  `owner`, `topic_slug`, `created`, and `updated`.
-- Include task blocks with stable IDs, status, priority, and optional State Hub
-  task IDs.
-- Keep workplans tied to this repo's PRD/FRS requirements and State Hub context.
+File location: `workplans/IB-WP-NNNN-<slug>.md`
+ID prefix: `IB-WP-`
+
+Work items originate as files in this repo **before** being registered in the hub.
+
+Canonical workplan/workstream frontmatter statuses are:
+`proposed`, `ready`, `active`, `blocked`, `backlog`, `finished`, `archived`.
+Use `proposed` for a newly drafted plan, `ready` after review against current
+repo state, and `finished` when implementation is complete. `stalled` and
+`needs_review` are derived health labels, not stored statuses.
+
+Closed workplans may be moved to `workplans/archived/` with a completion-date
+prefix: `YYMMDD-IB-WP-NNNN-<slug>.md`. The frontmatter id remains
+unchanged; the prefix is only for quick visual reference.
+
+Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
+`workplans/ADHOC-YYYY-MM-DD.md`, workstream slug `adhoc-YYYY-MM-DD`, and task ids
+`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
+directly. Promote anything requiring analysis, design, approval, dependencies, or
+multiple planned phases into a normal workplan.
+
+Ecosystem todos from other agents arrive as `[repo:infospace-bench]` hub tasks —
+visible at session start. Pick one up by creating the workplan file, then registering
+the workstream.
+
+Task blocks use this shape:
+
+```task
+id: IB-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
+<!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

.custodian-brief.md

@@ -1,88 +1,18 @@
 <!-- custodian-brief: generated by fix-consistency — do not edit manually -->
 # Custodian Brief — infospace-bench
 
-**Domain:** markitect  
-**Last synced:** 2026-05-14 11:13 UTC  
+**Domain:** communication  
+**Last synced:** 2026-07-03 16:42 UTC  
 **State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
 
 ## Active Workstreams
 
-### Replacement Readiness And CLI Parity Gate
-Progress: 0/4 done  |  workstream_id: `72b6a923-cad5-450b-b658-b35a00cecd4d`
-
-**Open tasks:**
-- · Legacy command parity table  `b48edb8e`
-- · End-to-end acceptance suite  `12eb0f88`
-- · Documentation and migration guide  `cd4ee529`
-- · Replacement decision record  `ca88d1c5`
-
-### Pruned Legacy Reference Pilot
-Progress: 0/4 done  |  workstream_id: `5bcc4fe2-a1d3-4edf-9e6e-0b2844b5b499`
-
-**Open tasks:**
-- · Select representative slice  `49d4865b`
-- · Migrate schemas/contracts and methodology  `3bea0589`
-- · Run successor pipeline  `fe012682`
-- · Publish migration report  `5a6c885f`
-
-### Kontextual Engine Integration Boundary
-Progress: 0/4 done  |  workstream_id: `0f69d4dc-b301-436c-8ccb-858a00bd2847`
-
-**Open tasks:**
-- · Engine capability contract  `f77c10cf`
-- · Repository adapter design  `bd20ddaa`
-- · Sync and provenance model  `12ffd95b`
-- · Agent-safe operation notes  `fe1031d6`
-
-### Applied Workflow And Generation Pipeline
-Progress: 0/4 done  |  workstream_id: `e8c96f7b-f5c7-4fbb-b4dc-fcae7e9817f0`
-
-**Open tasks:**
-- · Workflow definition model  `32c1dafc`
-- · Deterministic workflow runner  `2bb1f82b`
-- · Assisted generation boundary  `2dd1ad70`
-- · CLI workflow commands  `63d34a33`
-
-### Evaluation History And Metrics Parity
-Progress: 0/4 done  |  workstream_id: `f00ba036-dc97-4370-a4a5-9ac2bce7ce6f`
-
-**Open tasks:**
-- · Evaluation file I/O  `95b48ad3`
-- · Snapshot history  `b4800ba8`
-- · Metrics merge and viability reports  `7abcbd63`
-- · Legacy metric compatibility notes  `675d1d45`
-
-### Entity And Relation Model Migration
-Progress: 0/4 done  |  workstream_id: `3f6f17c9-bf50-4297-9bd5-cbe1e33efa76`
-
-**Open tasks:**
-- · Define entity model  `d6c401be`
-- · Parse entities from artifacts  `25e42321`
-- · Define and parse relation model  `845a8ea0`
-- · Manifest integration  `155028a2`
-
-### Markitect Tool Adapter And Markdown Artifact Validation
-Progress: 0/4 done  |  workstream_id: `713415b0-0c14-4367-8217-26c729648aec`
-
-**Open tasks:**
-- · Add dependency and adapter boundary  `b438be61`
-- · Parse Markdown artifacts through markitect-tool  `d37d6be3`
-- · Validate artifact contracts  `74a78679`
-- · CLI inspection integration  `99b4e2ca`
-
-### Orthogonal Successor Architecture
-Progress: 0/4 done  |  workstream_id: `ce26304b-aef2-4e01-926c-0635fc7a0f9b`
-
-**Open tasks:**
-- ► Feature inventory from legacy markitect-project  `10b456fa`
-- · Boundary and interface map  `f5a57259`
-- · Replacement acceptance matrix  `0a4f35b4`
-- · State Hub alignment  `5e9f9889`
+*(none — repo may need first-session setup)*
 
 ---
 ## MCP Orientation (when available)
 
 If the state-hub MCP server is reachable, call:
-`get_domain_summary("markitect")`
+`get_domain_summary("communication")`
 This provides richer cross-domain context.
 If the MCP call fails, use this file as your orientation source.

.gitignore

@@ -174,3 +174,8 @@ cython_debug/
 # PyPI configuration file
 .pypirc
 
+# artifact-store self-contained registries inside infospaces (IB-WP-0014).
+# Bytes and event log are reconstructable from the artifact-store deployment;
+# only output/archives/index.yaml (the pointer log) is checked in.
+infospaces/*/output/archives/.store/
+

.repo-classification.yaml

@@ -0,0 +1,17 @@
+repo_classification:
+  standard: Repo Classification Standard
+  version: '1.0'
+  classified_at: '2026-06-22'
+  classified_by: agent
+  category: project
+  domain: communication
+  secondary_domains: []
+  capability_tags:
+  - knowledge
+  - documentation
+  business_stake:
+  - technology
+  - product
+  business_mechanics:
+  - coordination
+  - operation

AGENTS.md

@@ -0,0 +1,219 @@
+# infospace-bench — Agent Instructions
+
+## Repo Identity
+
+**Purpose:** Application-layer workspace and service for concrete structured knowledge spaces; scoped successor to markitect-main infospace work.
+
+**Domain:** communication
+**Repo slug:** infospace-bench
+**Topic ID:** `5571d954-0d30-4950-980d-7bcaaad8e3e2`
+**Workplan prefix:** `IB-WP-`
+
+---
+
+## State Hub Integration
+
+The Custodian State Hub tracks work across all domains. Interact via HTTP REST —
+there is no MCP server for Codex agents.
+
+| Context | URL |
+|---------|-----|
+| Local workstation | `http://127.0.0.1:8000` |
+| Remote via tunnel | `http://127.0.0.1:18000` |
+
+### Orient at session start
+
+```bash
+# Offline brief — works without hub connection
+cat .custodian-brief.md
+
+# Active workstreams for this domain
+curl -s "http://127.0.0.1:8000/workstreams/?topic_id=5571d954-0d30-4950-980d-7bcaaad8e3e2&status=active" \
+  | python3 -m json.tool
+
+# Check inbox
+curl -s "http://127.0.0.1:8000/messages/?to_agent=infospace-bench&unread_only=true" \
+  | python3 -m json.tool
+```
+
+Mark a message read:
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+### Log progress (required at session close)
+
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{
+    "summary": "what was done",
+    "event_type": "note",
+    "author": "codex",
+    "workstream_id": "<uuid>",
+    "task_id": "<uuid>"
+  }'
+```
+
+Omit `workstream_id` / `task_id` when not applicable.
+
+### Update task status
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"status": "progress"}'
+# values: wait | todo | progress | done | cancel
+```
+
+### Flag a task for human review
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"needs_human": true, "intervention_note": "reason"}'
+```
+
+---
+
+## Session Protocol
+
+**Start:**
+1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
+2. Check inbox: `GET /messages/?to_agent=infospace-bench&unread_only=true`; mark read
+3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
+
+**During work:**
+- Update task statuses in workplan files as tasks progress
+- Record significant decisions via `POST /decisions/`
+
+**Close:**
+1. Update workplan file task statuses to reflect progress
+2. Log: `POST /progress/` with a summary of what changed
+3. Note for the custodian operator: after workplan file changes, run from
+   `~/state-hub`:
+   ```bash
+   make fix-consistency REPO=infospace-bench
+   ```
+   This syncs task status from files into the hub DB.
+
+---
+
+## Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=infospace-bench` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
+
+<!-- REPO-AGENTS-EXTENSIONS -->
+<!-- Append repo-specific agent instructions below this marker.
+     The state-hub template sync preserves content after this line. -->
+
+---
+
+## Workplan Convention (ADR-001)
+
+Work items originate as files in this repo — not in the hub. The hub is a
+read/cache/index layer that rebuilds from files.
+
+**File location:** `workplans/INFOSPACE-WP-NNNN-<slug>.md`
+
+**Archived location:** finished workplans may move to
+`workplans/archived/YYMMDD-INFOSPACE-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
+the completion/archive date; the frontmatter `id` does not change.
+
+**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
+`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use
+this only for low-risk work completed directly; create a normal workplan for
+anything needing analysis, design, approval, dependencies, or multiple phases.
+
+**Frontmatter:**
+
+```yaml
+---
+id: INFOSPACE-WP-NNNN
+type: workplan
+title: "..."
+domain: communication
+repo: infospace-bench
+status: proposed | ready | active | blocked | backlog | finished | archived
+owner: codex
+topic_slug: ...
+created: "YYYY-MM-DD"
+updated: "YYYY-MM-DD"
+state_hub_workstream_id: "<uuid>"   # written by fix-consistency — do not edit
+---
+```
+
+Use `proposed` for a new draft, `ready` after review against current repo
+state, and `finished` after implementation. `stalled` and `needs_review` are
+derived health labels, not frontmatter statuses.
+
+**Task block format** (one per `##` section):
+
+```
+## Task Title
+
+` ` `task
+id: INFOSPACE-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+` ` `
+
+Task description text.
+```
+
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
+
+To create a new workplan:
+1. Write the file following the format above
+2. Notify the custodian operator to run `make fix-consistency REPO=infospace-bench`
+   (or send a message to the hub agent via `POST /messages/`)

CLAUDE.md

@@ -1,7 +1,12 @@
+# infospace-bench — Claude Code Instructions
+
 @SCOPE.md
 @.claude/rules/repo-identity.md
 @.claude/rules/session-protocol.md
+@.claude/rules/first-session.md
 @.claude/rules/workplan-convention.md
-@.claude/rules/repo-boundary.md
-@.claude/rules/architecture.md
 @.claude/rules/stack-and-commands.md
+@.claude/rules/architecture.md
+@.claude/rules/repo-boundary.md
+@.claude/rules/credential-routing.md
+@.claude/rules/agents.md

Makefile

@@ -0,0 +1,29 @@
+PYTHON ?= .venv/bin/python
+UV ?= uv
+
+.PHONY: help venv install test test-archive clean
+
+help:
+	@echo "infospace-bench dev targets"
+	@echo
+	@echo "  make venv          create ./.venv via uv"
+	@echo "  make install       install path deps (markitect-tool, artifactstore) into .venv"
+	@echo "  make test          run the full pytest suite"
+	@echo "  make test-archive  run only the artifact-store archive integration tests"
+	@echo "  make clean         remove ./.venv and pytest caches"
+
+venv:
+	$(UV) venv
+
+install: venv
+	$(UV) pip install -e .
+	$(UV) pip install pytest pytest-asyncio
+
+test:
+	$(PYTHON) -m pytest -q
+
+test-archive:
+	$(PYTHON) -m pytest tests/test_archive.py -q
+
+clean:
+	rm -rf .venv .pytest_cache

README.md

@@ -18,8 +18,26 @@ Start with:
 - `docs/evaluation-and-inspection.md`
 - `docs/reference-pilot-decision.md`
 - `docs/markitect-main-scope-assessment.md`
+- `docs/markitect-tool-adapter.md`
+- `docs/entity-relation-model.md`
+- `docs/evaluation-history-and-metrics.md`
+- `docs/workflow-generation-pipeline.md`
+- `docs/kontextual-engine-boundary.md`
 - `docs/orthogonal-successor-roadmap.md`
+- `docs/legacy-infospace-feature-inventory.md`
+- `docs/successor-boundary-interface-map.md`
+- `docs/replacement-acceptance-matrix.md`
+- `docs/legacy-command-parity.md`
+- `docs/legacy-infospace-migration-guide.md`
+- `docs/replacement-readiness-decision.md`
+- `docs/wealth-vsm-generation-pipeline.md`
+- `docs/generic-source-generator.md`
+- `docs/agentic-memory-profile-pilot.md`
+- `docs/lefevre-epub3-validation.md`
 - `infospaces/bootstrap-pilot/`
+- `infospaces/wealth-vsm-legacy-slice/`
+- `infospaces/wealth-vsm-generation-pilot/`
+- `infospaces/agentic-memory-profile-pilot/`
 - `workplans/`
 
 Current development command:

SCOPE.md

@@ -7,45 +7,94 @@
 
 ## One-liner
 
-Application-layer workspace and service for building, evaluating, inspecting,
-and evolving concrete structured knowledge spaces.
+File-backed application workspace and current CLI for creating, developing,
+evaluating, inspecting, exporting, archiving, and iterating concrete structured
+knowledge spaces.
 
 ---
 
 ## Core Idea
 
 `infospace-bench` turns the infospace ideas that emerged in `markitect-main`
-into a focused successor project. It should host real infospaces, their
-configuration, evaluation runs, inspection outputs, workflow traces, and export
-experiments.
+into a focused successor project. It hosts real infospaces, their manifests,
+profiles, workflow declarations, deterministic fixtures, generation runs,
+inspection outputs, budget records, archive records, exports, and pilot reports.
 
-The repo is intentionally above the lower layers:
+The strategic layer model remains:
 
-- `markitect-tool` owns markdown syntax and document transformation primitives.
-- `kontextual-engine` owns persistence, orchestration, and runtime system
-  concerns.
-- `infospace-bench` owns concrete applied knowledge spaces and their lifecycle.
+- `markitect-tool` owns the syntax layer: markdown structure, structured
+  markdown validation, document transformations, and reusable Markitect
+  contracts.
+- `kontextual-engine` owns the system layer: durable persistence,
+  orchestration, permissions, retrieval, workflow runtime, and audit concerns.
+- `infospace-bench` owns the application layer: concrete applied knowledge
+  spaces, their lifecycle, evaluation methodology, and reference pilots.
+
+Current supporting integrations include:
+
+- `artifact-store` for durable content-addressed packages, archive identity,
+  storage, retention, and archive backend concerns.
+- `llm-connect` for reusable provider-routing primitives and quality-ledger
+  policy mechanics.
+
+These supporting integrations do not redefine the strategic layer ownership.
+The default operating mode is file-backed and inspectable. Optional integrations
+are explicit, reviewable adapters rather than hidden infrastructure drift.
+
+`infospace-bench` should also act as a reference environment for applied
+knowledge-engineering practice: concrete pilots, reviewable outputs, reusable
+patterns, and clear evidence of what should move into lower layers.
+
+---
+
+## Primary Actors
+
+- Knowledge engineers and developers building structured content systems
+- Researchers and practitioners organizing or analyzing domain knowledge
+- Automation systems (`atm`) executing scoped knowledge workflows
+- LLM agents (`agt`) helping generate, review, and refine infospaces
+- Human reviewers deciding when generated artifacts, metrics, and archives are
+  good enough to trust or preserve
 
 ---
 
 ## In Scope
 
-- Defining infospaces as first-class, inspectable project artifacts
-- Populating infospaces from real sources and domain-specific configurations
-- Evaluating entity quality, collection quality, structure, and viability
-- Inspecting relationships, provenance, metrics history, and workflow outputs
-- Running application-level generation, transformation, and analysis workflows
-- Capturing reusable patterns that may later move into lower-layer repos
+- Defining infospaces as first-class, manifest-backed project artifacts
+- Populating infospaces from local sources, EPUB-like inputs, profiles, and
+  domain-specific workflow templates
+- Running deterministic fixture workflows and explicit live provider workflows
+  for generation, extraction, relation mapping, evaluation, and reports
+- Reviewing, pruning, revising, refining, and exporting knowledge artifacts as
+  infospaces evolve
+- Evaluating entity quality, collection quality, viability thresholds, metrics
+  history, and plan-vs-actual generation behavior
+- Inspecting entities, relations, artifact graphs, provenance, workflow runs,
+  provider metadata, budget records, and archive records
+- Capturing reusable applied patterns that may later move into lower-layer repos
+- Maintaining reference pilots that make abstract infospace concepts concrete
+- Documenting best-practice evidence for applied knowledge engineering without
+  turning this repo into the reusable infrastructure layer
+- Planning and recording one-way syncs from file-backed artifacts into an engine
+  adapter while keeping the local manifest authoritative
+- Archiving reviewed infospace snapshots through `artifact-store` without making
+  archives a substitute for the working folder or git
 
 ---
 
 ## Out of Scope
 
 - Low-level markdown parsing, schema syntax primitives, or rendering engines
-- Generic persistence infrastructure or workflow orchestration platforms
+- Generic persistence infrastructure, retrieval systems, permissions, audit, or
+  workflow orchestration platforms
+- Artifact storage backends, retention-policy implementation, replication, or
+  backup operations
 - General content management, publishing, or WYSIWYG editing
-- Reusable libraries that belong in `markitect-tool` or `kontextual-engine`
+- Reusable provider-routing policy engines or cross-repo LLM infrastructure
+- Secret management for provider keys, archive backends, or engine deployments
 - Silent coupling to a single LLM vendor or runtime
+- Final ownership of production domain artifacts once a dedicated domain repo
+  should take over
 
 ---
 
@@ -53,36 +102,95 @@ The repo is intentionally above the lower layers:
 
 - A real corpus, book, project, or organization needs an explicit infospace
 - Knowledge artifacts need systematic evaluation and iteration history
-- Relationship structure and quality metrics need to be inspected over time
+- Relationship structure, provenance, and quality metrics need inspection over
+  time
 - Agent-assisted knowledge development needs scoped project context
-- A MarkiTect infospace experiment needs to be migrated or reimplemented
+- A MarkiTect infospace experiment needs to be migrated, pruned, compared, or
+  reimplemented
+- Generation work needs deterministic fixture runs, guarded live model runs,
+  routing observations, and budget evidence in one inspectable workspace
+- A reviewed infospace milestone needs a content-addressed archive package
 
 ---
 
 ## Not Relevant When
 
 - The work is only markdown syntax manipulation
-- The work is engine/runtime infrastructure
+- The work is engine/runtime infrastructure or durable memory persistence
+- The work is only artifact-store backend, retention, or storage operations
 - A finalized domain repository should own the production artifact
 - A few simple documents only need ordinary editing
+- A live provider run is being attempted without budget planning, review gates,
+  and explicit secrets supplied outside the repo
 
 ---
 
 ## Current State
 
-- Status: newly bootstrapped successor repo
-- Source intent: `INTENT.md`, PRD, and FRS in `wiki/`
-- Upstream comparison target: `/home/worsch/markitect-main`
-- State Hub registration: `infospace-bench` under the `markitect` domain
-- First workplans: lifecycle scaffold, MarkiTect migration triage, evaluation
-  framework, and reference infospace pilot
+- Status: implemented application-layer workspace with a Python CLI, test suite,
+  reference docs, committed pilots, and deterministic fixtures
+- Package entry point: `infospace-bench` / `python3 -m infospace_bench`
+- Service posture: `INTENT.md` still treats "service" as a strategic maturity
+  target, but this repo does not currently ship a standalone server or API
+  service; the implemented surface is file-backed plus CLI
+- Current CLI surface: lifecycle, artifact add/export/validate, readiness
+  status, entity and relation listing, metrics/checks, history diffs, viability,
+  graph export, workflow inspect/plan/run, source generation, routing ledger
+  summaries, budget rollups, archive/restore, and engine sync planning
+- Current infospaces:
+  - `bootstrap-pilot`
+  - `wealth-vsm-legacy-slice`
+  - `wealth-vsm-generation-pilot`
+  - `agentic-memory-profile-pilot`
+  - `lefevre-reminiscences-of-a-stock-operator`
+  - `patterns-of-it-securita-architecture`
+- Current profiles: bundled `general-knowledge` and `trading-literature`, with
+  the Lefevre infospace carrying a checked-in trading-literature profile copy
+- Current provider posture: fixture runs are deterministic by default;
+  OpenRouter and routed live runs are explicit, budget-aware, and guarded by
+  environment-provided credentials
+- Current archive posture: `infospace-bench archive`, `archive-list`, and
+  `restore` integrate with `artifact-store` for reviewed snapshots
+- Current engine posture: local file-backed manifests remain authoritative;
+  engine sync is dry-run by default and currently uses an inspectable local
+  adapter store
+
+---
+
+## Important Boundaries
+
+- `artifacts/index.yaml` is the authoritative manifest for an infospace in this
+  repo.
+- Service or API behavior must be added explicitly; it should not be inferred
+  from the strategic service wording in `INTENT.md`.
+- Generated outputs, budget records, metrics, workflow runs, and reports are
+  evidence for review; they do not silently become durable engine state.
+- Live LLM output is review material. Scaling from a one-chapter or bounded run
+  to a larger corpus requires explicit planning and human review.
+- Archives are immutable evidence packages. Use git for in-flight working state
+  and artifact-store archives for milestone preservation.
+- Successful applied patterns may inform `markitect-tool`, `kontextual-engine`,
+  `artifact-store`, or `llm-connect`, but this repo should not absorb their
+  reusable infrastructure responsibilities.
 
 ---
 
 ## Getting Oriented
 
-- Start with: `INTENT.md`, `wiki/ProductRequirementsDocument.md`,
+- Start with: `README.md`, `INTENT.md`, and this file
+- Product framing: `wiki/ProductRequirementsDocument.md`,
   `wiki/FunctionalRequirementsSpecification.md`
-- Migration assessment: `docs/markitect-main-scope-assessment.md`
+- Layout and lifecycle: `docs/infospace-layout.md`,
+  `docs/evaluation-and-inspection.md`, `docs/entity-relation-model.md`
+- Generation and pilots: `docs/generic-source-generator.md`,
+  `docs/wealth-vsm-generation-pipeline.md`,
+  `docs/agentic-memory-profile-pilot.md`, `docs/lefevre-readiness.md`
+- Integrations and boundaries: `docs/markitect-tool-adapter.md`,
+  `docs/kontextual-engine-boundary.md`, `docs/archive-integration.md`,
+  `docs/routing-config.md`, `docs/replacement-readiness-decision.md`
+- Code map: `src/infospace_bench/`
+- Pilots: `infospaces/`
+- Tests: `tests/`
 - Workplans: `workplans/`
-- State Hub rules: `CLAUDE.md` and `.claude/rules/`
+- State Hub and session rules: `AGENTS.md`, `CLAUDE.md`, and
+  `.claude/rules/`

docs/agentic-memory-profile-pilot.md

@@ -0,0 +1,97 @@
+# Agentic Memory Profile Pilot
+
+Date: 2026-05-15
+Workplan: IB-WP-0017
+
+## Purpose
+
+This pilot validates agentic memory profile fixtures against concrete
+infospace work. It does not add reusable memory runtime infrastructure to
+`infospace-bench`.
+
+## Pilot Selection
+
+The selected corpus is `infospaces/wealth-vsm-legacy-slice`. It is bounded,
+reviewable, and already contains a source, entities, relation, evaluation,
+metrics, history, and an engine sync plan. That makes it a better pilot than a
+new synthetic corpus because the memory package can be evaluated against a real
+restart task: resume review of the Wealth/VSM entity and relation neighborhood.
+
+## Memory Question Matrix
+
+| Memory Question | Pilot Evidence | Acceptance Threshold |
+| --- | --- | --- |
+| Which reasoning decisions should become durable memory? | `decision.file-backed-pilot` and `constraint.no-durable-runtime` | A restart package explains ownership boundaries without rereading Workplan 17. |
+| Which conversation or workflow events are useful later? | `trace.entity-review-restart` and `event.workflow-restart-trace` | Events explain why a package item exists and what task it supports. |
+| Which knowledge graph neighborhoods improve review? | Wealth/VSM source and entity nodes | The package includes the active artifact neighborhood, not only planning notes. |
+| Which context package shapes help agents? | `restart-context-selection.yaml` | Eight or fewer items, source spans preserved, no live LLM required. |
+| Which profile parameters are too abstract or misplaced? | `context-package-evaluation.yaml` | Contract feedback is routed to Markitect or the engine, not hidden in this repo. |
+
+## Fixture Contracts
+
+The checked-in pilot uses Markitect contract versions:
+
+- `markitect.memory.profile.v1`
+- `markitect.memory.graph.v1`
+- `markitect.memory.selection.v1`
+
+The default test suite validates the profile and graph through
+`markitect_tool.memory.graph`, compiles the selection to a context package, and
+checks the deterministic fields against
+`restart-context-package.expected.yaml`.
+
+## Context Package Evaluation
+
+The restart package is considered useful when it:
+
+- contains the boundary decision, no-runtime constraint, package plan, review
+  gate, and active Wealth/VSM artifact neighborhood
+- preserves provenance for all selected nodes or synthetic Markitect event spans
+- remains under the declared 1200-token package budget
+- keeps runtime writes review-gated and fixture-only
+
+The first pilot snapshot scores restart quality at `4.2/5.0` and provenance
+coverage at `1.0`.
+
+## Engine Integration Plan
+
+File-backed in this pilot:
+
+- selected corpus and infospace manifest
+- Markitect memory profile, graph, and selection fixtures
+- expected package shape and evaluation metrics
+- workflow trace examples and review notes
+
+Engine-backed later:
+
+- durable memory node, edge, event, and audit storage
+- permission-aware query and activation behavior
+- retention, refresh, compaction, and policy decisions
+- dry-run and apply plans for durable memory writes
+
+The first integration should mirror this fixture into `kontextual-engine` as an
+imported Markitect graph. Dry run should report creates, updates, denied writes,
+and policy reasons. Apply should require an explicit review gate and record an
+engine audit event separately from Markitect contract events.
+
+## Architecture Feedback
+
+Markitect contract feedback:
+
+- Add a timestamp-stable context package output mode for golden fixtures.
+- Document when selected events should become package items versus metadata.
+- Make package provenance for implied edges easy to inspect.
+
+Kontextual engine feedback:
+
+- Import Markitect graph/profile envelopes without redefining node vocabulary.
+- Persist runtime audit events separately from Markitect memory events.
+- Keep durable memory updates review-gated and export Markitect-compatible
+  package inputs.
+
+Infospace-bench boundary:
+
+- Keep corpus selection, applied metrics, evaluation history, workflow traces,
+  and practical package-quality evidence here.
+- Do not store credentials, durable user memory, or general graph/event
+  persistence inside an infospace.

docs/archive-integration.md

@@ -0,0 +1,151 @@
+# Archive Integration With artifact-store
+
+`infospace-bench` is an application workspace for *live* infospaces. The
+working state lives in a local folder and is read-write-read-write across many
+sessions. Durable, content-addressed preservation of finalized snapshots is
+delegated to [`artifact-store`](file:///home/worsch/artifact-store), which
+owns identity, manifests, retention policy, audit, and pluggable storage
+backends (local FS today, S3-compatible / Ceph RGW in artifact-store WP-0004).
+
+This document is the operator-facing companion to workplan
+[`IB-WP-0014`](../workplans/IB-WP-0014-infospace-backend-abstraction.md).
+
+## When to archive
+
+Archive an infospace when:
+
+- A milestone has been reached (pilot complete, evaluations stable).
+- The infospace will be referenced from another system (StateHub linkage,
+  release notes, audit evidence).
+- You want a recoverable point-in-time snapshot before a destructive change.
+- You need to share an exact, hash-verifiable copy of the state with someone
+  else.
+
+Do **not** archive as a substitute for normal save / commit. Each archive
+creates a new immutable package; long sequences of archives without intent
+will inflate the local store. Use git for in-flight working state.
+
+## What gets archived
+
+By default, the archive includes:
+
+- `infospace.yaml`
+- `artifacts/`
+- `workflows/`
+- `output/` (metrics, evaluations, run records, memory traces, ...)
+- `reports/`
+- `exports/`
+
+Always excluded:
+
+- `output/archives/.store/` (the artifact-store data dir — would cause
+  recursive capture)
+- `output/archives/index.yaml` (the archive record index itself is a local
+  pointer, not part of the preserved snapshot)
+
+Override the include / exclude sets with `--include` and `--exclude`
+(repeatable). Both accept relative paths or globs.
+
+## Retention class
+
+`artifact-store` ships these retention classes:
+
+| Class                 | Typical use                                |
+|-----------------------|--------------------------------------------|
+| `transient`           | Scratch outputs you only need briefly      |
+| `raw-evidence`        | Untriaged raw run output                   |
+| `summary-evidence`    | Aggregated metrics / reports               |
+| `release-evidence`    | Snapshots tied to a release or milestone   |
+| `permanent-record`    | Never expires                              |
+
+The infospace-bench default is `release-evidence`. Override with
+`--retention-class`. Run `artifactstore retention sweep` from the
+`artifact-store` repo to mark expired packages eligible for deletion.
+
+## CLI usage
+
+```bash
+# Archive the current infospace (default include set)
+infospace-bench archive infospaces/agentic-memory-profile-pilot \
+  --note "Memory profile pilot v1 frozen"
+
+# Custom include set
+infospace-bench archive infospaces/lefevre \
+  --include reports --include exports --include infospace.yaml \
+  --retention-class summary-evidence
+
+# List recorded archives
+infospace-bench archive-list infospaces/agentic-memory-profile-pilot
+
+# List with current retention state (eligibility, holds, expiry)
+infospace-bench archive-list infospaces/agentic-memory-profile-pilot \
+  --with-retention
+
+# Restore an archive into a new directory
+infospace-bench restore <package-id> \
+  --target /tmp/restored-infospace \
+  --from infospaces/agentic-memory-profile-pilot
+```
+
+## Storage location
+
+By default, each infospace gets its own self-contained artifact-store under
+`<infospace>/output/archives/.store/`:
+
+```
+output/archives/
+  index.yaml                    # human-readable archive record list
+  .store/
+    registry.sqlite             # artifact-store event log + materialised views
+    storage/
+      blake3/
+        ab/
+          cd/
+            abcdef...           # content-addressed bytes
+```
+
+To point a different artifact-store deployment (shared host, separate
+volume), pass `--store-root` or run a shared artifact-store service and pass
+its CLI / library handle in code. Future improvement: respect the standard
+`ARTIFACTSTORE_*` environment variables so an operator can point any
+infospace at a shared deployment without code changes. Today the in-process
+helper builds a self-contained store; an `artifactstore.app.build_registry()`
+adapter for that env-driven path is a small follow-up.
+
+## Credentials policy
+
+- Never write secrets (API keys, S3 access keys) into `infospace.yaml` or
+  archive metadata. Archive metadata is part of the immutable manifest.
+- Backend secrets live with the artifact-store deployment
+  (`ARTIFACTSTORE_S3_ACCESS_KEY_REF=env:NAME` or
+  `file:/run/secrets/...`) — never inside the infospace.
+
+## Round-trip guarantees
+
+- `restore_archive` re-materializes every file recorded in the package's
+  manifest into the target directory, byte-equivalent to the originals.
+- The manifest digest (`blake3:<hex>`) returned by `archive` is the stable
+  external identifier; it survives store relocations.
+- Restoration refuses to overwrite a non-empty target unless `--force` is
+  passed. Pre-existing files not in the manifest are left in place.
+
+## What this is not
+
+- Not a replacement for the local working folder during active work.
+- Not a sync / replication channel between hosts. Use git or
+  artifact-store's S3 backend (artifact-store WP-0004) for that.
+- Not a backup strategy. Backups are an operations concern at the
+  artifact-store deployment level.
+- Not an S3 or git client inside `infospace-bench`. Those backends live in
+  `artifact-store`.
+
+## Related workplans
+
+- [`IB-WP-0014`](../workplans/IB-WP-0014-infospace-backend-abstraction.md) —
+  this integration.
+- [`IB-WP-0013`](../workplans/IB-WP-0013-wealth-vsm-generation-pipeline-parity.md) —
+  generation parity on the local working folder (archives capture its
+  outputs).
+- `artifact-store` WP-0004 — S3-compatible / Ceph RGW backend; pointing
+  infospace-bench archives at S3 will be an artifact-store configuration
+  change only.

docs/entity-relation-model.md

@@ -0,0 +1,54 @@
+# Entity And Relation Model
+
+`infospace-bench` owns the application-level semantic model for infospace
+entities and relation triplets. `markitect-tool` remains the Markdown structure
+provider and is accessed only through `infospace_bench.markdown_adapter`.
+
+## Entity Artifacts
+
+Entity artifacts are registered in `artifacts/index.yaml` with `kind: entity`
+and are stored under `artifacts/entities/`.
+
+The parser extracts:
+
+- `artifact_id`: manifest identity such as `entity/division.md`
+- `slug`, `title`, and `h1_raw`: identity derived from the document H1
+- `definition`, `source_chapter`, `context`, `domain`, `original_wording`,
+  and `modern_interpretation`: legacy-style sections where present
+- `h1_is_title_case`, `has_original_wording`, `definition_word_count`,
+  `total_word_count`, and ordered `section_slugs`: compatibility metrics used by
+  evaluation and inspection flows
+- `source_path`: path to the concrete artifact file
+
+`## Definition` is required. Missing required sections raise
+`invalid_entity_artifact` with a `missing_sections` detail list.
+
+## Relation Artifacts
+
+Relation artifacts are registered with `kind: relation` and are stored under
+`artifacts/relations/`.
+
+The parser extracts:
+
+- `artifact_id` and `slug`: manifest identity plus a relation slug derived from
+  the H1
+- `subject`, `predicate`, `object`: the relation triplet
+- `subject_slug`, `object_slug`, `subject_entity_id`, and `object_entity_id`:
+  endpoint links back to parsed entity artifacts
+- `relation_type`, `vsm_channel`, `evidence`, and `feedback_role`: semantic and
+  evaluation metadata
+- `is_feedback_member`: derived from whether `feedback_role` is present
+
+`## Subject`, `## Predicate`, and `## Object` are required. When relation
+listing is performed from an infospace manifest, subject and object slugs must
+resolve to entity artifacts or `unresolved_relation_endpoint` is raised.
+
+## CLI
+
+```bash
+python3 -m infospace_bench entities infospaces/bootstrap-pilot
+python3 -m infospace_bench relations infospaces/bootstrap-pilot
+```
+
+These commands emit JSON records for downstream evaluation, graphing, and
+inspection workflows.

docs/evaluation-history-and-metrics.md

@@ -0,0 +1,43 @@
+# Evaluation History And Metrics
+
+`infospace-bench` keeps evaluation history as committed, inspectable files under
+each infospace root. This replaces the legacy `markitect-project` history
+workflow while retaining the useful behaviors: Markdown evaluation files,
+append-only snapshot history, metric merging, and viability checks.
+
+## Files
+
+- `output/evaluations/*.md`: per-artifact evaluation files with YAML
+  frontmatter and a human-readable Markdown body.
+- `output/metrics/metrics.yaml`: latest merged metrics. Collection metrics,
+  evaluation-derived metrics, and structured non-numeric values are preserved.
+- `output/metrics/history.yaml`: append-only list of evaluation snapshots.
+- `output/metrics/snapshots/<snapshot-id>.yaml`: named snapshot copies for
+  reproducible diffs.
+- `output/metrics/viability.yaml`: structured viability report generated from
+  `infospace.yaml` thresholds and the current metrics file.
+
+## Replacement Mapping
+
+The old infospace history code used entity-oriented names such as
+`entity_count`, `entity_evaluations`, and `entity_slug`. The successor model
+uses artifact-oriented names:
+
+- `artifact_count` replaces `entity_count`
+- `artifact_evaluations` replaces `entity_evaluations`
+- `artifact_id` replaces `entity_slug`
+
+Readers accept the old snapshot aliases where practical so legacy fixtures can
+be inspected, but new files should use the artifact-oriented vocabulary.
+
+## CLI
+
+```bash
+python3 -m infospace_bench metrics infospaces/bootstrap-pilot
+python3 -m infospace_bench history infospaces/bootstrap-pilot
+python3 -m infospace_bench history infospaces/bootstrap-pilot --metric coverage_ratio
+python3 -m infospace_bench history-diff infospaces/bootstrap-pilot snap-a snap-b
+```
+
+Snapshot references may be exact snapshot IDs or ISO-like dates such as
+`2026-05-14`. Date references resolve to the nearest snapshot in the history.

docs/generic-source-generator.md

@@ -0,0 +1,244 @@
+# Generic Source Generator
+
+Date: 2026-05-14
+
+## Purpose
+
+`infospace-bench generate` turns a local article, ebook-like file, or folder of
+knowledge sources into a manifest-backed infospace. It generalizes the
+Wealth/VSM pilot into an explicit workflow path with deterministic fixture
+support and an optional OpenRouter provider.
+
+## Deterministic Run
+
+Use fixture responses for repeatable tests and demos:
+
+```bash
+infospace-bench generate from-source ./examples/article.md \
+  --workspace . \
+  --slug article-space \
+  --name "Article Space" \
+  --profile general-knowledge \
+  --fixture-responses ./examples/responses.yaml \
+  --apply
+```
+
+The command creates normalized source chunks, installs the selected profile,
+runs the declared workflows, writes entities, relations, evaluations, metrics,
+history, and a generation report, then registers artifacts in
+`artifacts/index.yaml`.
+
+## Stepwise Workflow
+
+```bash
+infospace-bench generate init ./book.epub \
+  --workspace . \
+  --slug book-space \
+  --name "Book Space" \
+  --profile general-knowledge \
+  --max-chunks 3
+
+infospace-bench generate plan ./infospaces/book-space --stage all
+infospace-bench generate run ./infospaces/book-space \
+  --fixture-responses ./responses.yaml
+infospace-bench generate status ./infospaces/book-space
+```
+
+`--max-chunks` caps early experiments and provider cost. `generate status`
+shows chunk counts, generated artifact counts, evaluations, metrics, history,
+and stale source/profile inputs.
+
+### Live OpenRouter runs (handle with care)
+
+A single-chapter live run is the only OpenRouter shape the test suite
+covers today. Use `--chapter` (or `--from-chapter` / `--to-chapter`) on
+`generate init` or `generate from-source` to scope what gets registered
+before any provider calls happen:
+
+```bash
+export OPENROUTER_API_KEY=...
+
+# Preview the cost first
+infospace-bench generate plan ./infospaces/foo --chapter I --cost-per-1k 0.30
+
+# Run only Chapter I against a cheap model
+infospace-bench generate from-source ./LEFEVRE.epub \
+  --workspace ./infospaces \
+  --slug reminiscences-ch1 \
+  --name "Reminiscences (Ch I)" \
+  --profile trading-literature \
+  --provider openrouter \
+  --model openai/gpt-4o-mini \
+  --chapter I \
+  --apply
+```
+
+`output/budget/plans.yaml`, `usage.yaml`, and `summary.yaml` record what
+was estimated, what was actually spent, and the plan-vs-actual delta.
+`output/workflows/runs/*.yaml` carry the OpenRouter request_id, model,
+token usage, retry count, and per-call duration; the same metadata
+reaches the entity/relation/evaluation artifacts via
+`provenance.provider_metadata`.
+
+Before scaling to the full book:
+
+- Inspect each chapter's outputs and `generation-summary.md`
+- Multiply the per-chapter `total_provider_calls_estimate` and
+  `estimated_cost_usd` by the chapter count and compare to your budget
+- Decide on a final model and confirm the rate-table entry exists in
+  `src/infospace_bench/model_rates.yaml` or your workspace override
+
+The optional live-smoke test in `tests/test_openrouter_live.py` is
+skipped unless both `OPENROUTER_API_KEY` and
+`INFOSPACE_BENCH_ENABLE_LIVE_OPENROUTER=1` are set. It runs a single
+chapter through the same path and asserts the provider metadata
+plumb-through.
+
+### Live runs with `--provider routing`
+
+When the routing CLI is what you want to exercise live, swap
+`--provider openrouter --model ...` for the routing pair:
+
+```bash
+infospace-bench generate from-source ./LEFEVRE.epub \
+  --workspace ./infospaces \
+  --slug reminiscences-routed \
+  --name "Reminiscences (Routed)" \
+  --profile trading-literature \
+  --provider routing \
+  --routing-config ./examples/routing/trading-literature.yaml \
+  --chapter I \
+  --apply
+```
+
+`examples/routing/trading-literature.yaml` is a checked-in starting
+config: cheap candidates for summary/evaluation, smart candidates for
+entity/relation, a `claude_code` baseline rule for future shadow
+sampling, and a workspace-relative `output/routing/quality.jsonl`
+ledger so adaptive observations stay with the workspace.
+
+`--quality-floor <float>` on the same command overrides the config's
+`default_quality_floor` for a single invocation — useful for
+tightening the bar for a specific run without editing the file. The
+ledger fills up as the `AdaptiveRoutingPolicy` records each
+observation; later runs against the same workspace get the benefit
+without re-grading from scratch.
+
+The parallel live-smoke test
+(`test_provider_routing_one_chapter_live_smoke`) is also gated on
+`INFOSPACE_BENCH_ENABLE_LIVE_OPENROUTER=1` + `OPENROUTER_API_KEY` and
+asserts the per-stage adapter-choices report section names the routed
+model.
+
+### Budget and usage registry
+
+Every `generate plan` invocation appends a compact snapshot to
+`output/budget/plans.yaml` (deterministic 12-char `snapshot_id`, 50-entry
+sliding retention). Every `generate run` invocation appends a usage
+rollup to `output/budget/usage.yaml`, bucketed by `(workflow_id,
+stage_id, provider, model)` with prompt and completion token counts,
+known cost (when the adapter returned it), and estimated cost (when a
+rate table entry matches the model).
+
+The default rate table is bundled at
+`src/infospace_bench/model_rates.yaml` and covers a handful of common
+OpenRouter models at list price (see the file for the captured-at
+timestamp). A workspace can override or extend entries by placing
+`model-rates.yaml` next to its `infospaces/` directory; the workspace
+file is overlaid on top of the package default so partial overrides
+are fine.
+
+Cost resolution order on each run: adapter-returned `cost` first, then
+the rate table, then `cost_status="unknown"` (recorded explicitly,
+never silently zeroed). The plan-vs-actual variance summary lands in
+follow-on task T04.
+
+### Profiles
+
+Two profiles ship today:
+
+- `general-knowledge` — durable concepts, claims, methods, people,
+  places, works, and objects across any source
+- `trading-literature` — trading memoirs and market-structure texts;
+  tunes entity categories (`trader`, `market`, `strategy`, `error`,
+  `psychological_pattern`, `institution`, `instrument`,
+  `evidence_bearing_claim`), relation types (`cause_effect`,
+  `lesson_evidence`, `risk_mitigation`, `actor_venue`,
+  `strategy_outcome`), and evaluation criteria (`groundedness`,
+  `lesson_clarity`, `historical_context`, `overgeneralization_risk`)
+
+Select via `--profile trading-literature` on `generate init` or
+`generate from-source`. The generic profile remains the default.
+
+### Scale-aware plan
+
+`generate plan` returns a compact estimate by default — counts of selected
+chunks, calls per workflow, prompt-word and token estimates, and a rough
+USD cost when `--cost-per-1k` is supplied. Long corpora no longer dump
+hundreds of full prompts unless `--full` is set.
+
+```bash
+infospace-bench generate plan ./infospaces/book-space \
+  --from-chapter 1 --to-chapter 3 \
+  --cost-per-1k 0.30 \
+  --max-calls 50 \
+  --cost-cap 2.00
+```
+
+Selection filters:
+
+- `--chapter LABEL` (repeatable) — match a chapter by roman/arabic label
+  or numeric value (e.g. `--chapter I` or `--chapter 2`)
+- `--from-chapter N` / `--to-chapter N` — numeric chapter range
+- `--chunk ID` (repeatable) — exact source chunk id (e.g.
+  `chapter-01-part-002`)
+
+Budget flags `--max-calls` and `--cost-cap` are reported as
+`exceeds_max_calls` / `exceeds_cost_cap` booleans in the summary, so a
+caller can fail fast before invoking `run`. Use `--full` to opt back into
+the full per-workflow plan with prompts for deep inspection.
+
+## OpenRouter
+
+Live model calls are explicit:
+
+```bash
+export OPENROUTER_API_KEY=...
+
+infospace-bench generate run ./infospaces/book-space \
+  --provider openrouter \
+  --model openai/gpt-4o-mini \
+  --stage all
+```
+
+Choose the `--model` value from OpenRouter model IDs. The API key is read from
+`OPENROUTER_API_KEY`; it is not written to `infospace.yaml`. Default tests never
+make live provider calls.
+
+## Resume
+
+Use resume for interrupted or reviewed runs:
+
+```bash
+infospace-bench generate resume ./infospaces/book-space \
+  --provider openrouter \
+  --model openai/gpt-4o-mini
+```
+
+Unchanged completed runs are skipped. Use `--force` when you intentionally want
+to rerun completed work. Stale status is reported when source artifact digests
+or installed profile/template files change.
+
+## Review Path
+
+After generation:
+
+- inspect `artifacts/sources/` for normalized input chunks
+- inspect `artifacts/entities/` and `artifacts/relations/` for generated claims
+- inspect `output/evaluations/` for rubric output
+- run `infospace-bench validate <root>` and `infospace-bench graph <root>`
+- review `reports/generation-summary.md`
+
+Move from the generic profile to a specialized profile when the source domain
+needs stricter terminology, narrower extraction granularity, or a discipline
+lens such as VSM.

docs/infospace-layout.md

@@ -22,9 +22,14 @@ infospace.
 
 ```text
 artifacts/sources/
+artifacts/entities/
+artifacts/relations/
 artifacts/generated/
+workflows/templates/
 output/evaluations/
 output/metrics/
+output/engine/sync-runs/
+output/workflows/runs/
 reports/
 exports/
 ```

docs/kontextual-engine-boundary.md

@@ -0,0 +1,100 @@
+# Kontextual Engine Boundary
+
+`infospace-bench` can use `kontextual-engine` for durable knowledge operations,
+but it must not become an engine itself. The default remains file-backed and
+fully inspectable.
+
+This boundary follows `kontextual-engine/INTENT.md`: the engine owns durable
+asset identity, persistence, provenance, relationships, retrieval, workflow
+runs, permissions, and audit. `infospace-bench` owns concrete infospaces,
+manifests, evaluation methodology, workflow declarations, and reference pilots.
+
+## Capability Contract
+
+The current contract is exposed by:
+
+```python
+from infospace_bench.engine import engine_capability_contract
+```
+
+File-backed application responsibilities:
+
+- `infospace.yaml`
+- `artifacts/index.yaml`
+- Markdown artifacts
+- evaluation history and metrics
+- workflow run records
+- dry-run sync plans
+
+Engine-backed future responsibilities:
+
+- durable asset identity and persistence
+- provenance graph and relationship index
+- retrieval
+- workflow run persistence
+- permissions and audit
+
+Explicit non-goals for the engine boundary:
+
+- Markdown syntax rules
+- infospace-specific methodology
+- repo identity
+- provider-specific LLM calls
+
+## Local Adapter
+
+`LocalAssetRepository` is the default adapter. It writes asset records to:
+
+```text
+output/engine/assets.yaml
+```
+
+This file is a local evidence store, not a replacement for the infospace
+manifest. The manifest remains authoritative for this repository.
+
+Each asset record includes:
+
+- `asset_id`
+- `artifact_id`
+- `infospace_slug`
+- `kind`
+- `path`
+- `digest`
+- `version`
+- artifact provenance and relationships
+
+## Sync Safety
+
+Sync is dry-run by default:
+
+```bash
+python3 -m infospace_bench engine plan-sync infospaces/bootstrap-pilot
+python3 -m infospace_bench engine sync infospaces/bootstrap-pilot
+```
+
+Mutation requires explicit apply:
+
+```bash
+python3 -m infospace_bench engine sync infospaces/bootstrap-pilot --apply
+```
+
+Apply writes the local adapter store and a sync run record under:
+
+```text
+output/engine/sync-runs/<run-id>.yaml
+```
+
+Future `kontextual-engine` client configuration, permission changes, and apply
+operations should be review-gated.
+
+## First Safe Integration Scenario
+
+The first safe scenario is one-way mirroring from file-backed infospace
+artifacts into an engine-backed asset store:
+
+1. Inspect the capability contract.
+2. Run a dry-run sync plan.
+3. Review creates, updates, unchanged assets, and digests.
+4. Apply only after review.
+5. Treat `artifacts/index.yaml` as the source of truth until a later workplan
+   explicitly changes that operational mode.

docs/lefevre-epub3-validation.md

@@ -0,0 +1,137 @@
+# Lefevre EPUB3 Validation
+
+Date: 2026-05-14
+
+## Source
+
+Local source file:
+
+`/mnt/c/Users/bernd.worsch/Downloads/LefevreEdwin-ReminiscencesOfAStockOperator.epub`
+
+The EPUB is Project Gutenberg edition 60979, EPUB package version 3.0. The OPF
+metadata identifies:
+
+- title: `Reminiscences of a Stock Operator`
+- creator: `Edwin Lefevre`
+- subjects: `Speculation`, `New York Stock Exchange`, `Investments`
+- rights: public domain in the USA
+
+## Current Infrastructure Result
+
+The current generic generator can initialize a disposable infospace from the
+file and run non-provider metrics:
+
+- disposable root:
+  `/tmp/infospace-bench-lefevre-583mopy_/infospaces/reminiscences-stock-operator`
+- source chunks: 155
+- entities: 0
+- relations: 0
+- evaluations: 0
+- stale status: false
+- metrics snapshot: `5978ece0`
+
+The source-only metrics were:
+
+- redundancy ratio: `0.9225806451612903`
+- coverage ratio: `1.0`
+- coherence components: `155.0`
+- consistency cycles: `0.0`
+- granularity entropy: `-0.0`
+
+## Findings
+
+The EPUB intake works mechanically, but it is not ready for a serious full-book
+OpenRouter generation run.
+
+- EPUB spine order is visible in `OEBPS/content.opf`, but current intake reads
+  XHTML files by archive-name sorting.
+- Current titles mostly collapse to the same long Gutenberg page title instead
+  of chapter labels such as `I`, `II`, and `III`.
+- Current intake includes non-body material such as cover/header/footer/license
+  candidates unless the caller manually filters after import.
+- `generate plan` is not yet a compact cost/risk plan for a long book; a full
+  all-stage run would imply hundreds of provider calls.
+- Resume state is run-level enough for the small generic path, but a long ebook
+  needs chunk-level retry, stale, and skip policy.
+- Cross-chunk entity deduplication and merge/review policy are needed before a
+  full narrative book becomes a coherent infospace.
+
+## Desired Readiness Bar
+
+Before building the real Lefevre infospace with OpenRouter, the CLI should be
+able to show:
+
+- book metadata and selected source sections
+- body-only chapter order
+- stable chapter/chunk IDs
+- estimated provider call count and token/cost budget
+- selected chapter or chunk filters for smoke runs
+- deterministic fixture acceptance on a small Lefevre-like subset
+- optional live one-chapter smoke run with explicit provider/model/cost caps
+
+## T01 Result (2026-05-17)
+
+Spine-aware EPUB3 intake landed. Re-running the local Lefevre EPUB through
+`normalize_source(...)` now yields:
+
+- 148 body chunks (default), down from the original 155 mixed chunks
+- Spine reading order: indices 0..27 in declared order, not archive-name sort
+- Full OPF metadata on every chunk's `book_metadata`:
+  title, creator, language, subjects, rights, identifier, source_url, modified
+- Section roles classified across the 154 spine items:
+  `body=148`, `footer=4`, `cover=1`, `header=1`
+- The four Gutenberg footer/license/notes sections and the `*** START OF…`
+  header section are now excluded from generation input by default and
+  available via `include_non_body=True` for inspection
+- The legacy zip-without-OPF fallback path is preserved for malformed EPUBs
+
+The remaining gap is title collapse: all body sections still share the
+Project Gutenberg page title because chapter headings are not yet read from
+in-document `<h1>` content. That collapse is T02's scope (chapter-aware
+chunking and stable IDs from in-document headings).
+
+## T02 Result (2026-05-17)
+
+Chapter-aware chunking and stable IDs landed. The same local Lefevre EPUB
+now produces:
+
+- 67 body chunks (default `max_words=800` collapses to 24 single-chunk
+  chapters once `max_words=2000`)
+- All 24 roman-numeral chapters detected and assigned stable IDs
+  `chapter-01` .. `chapter-24`; multi-part chapters get
+  `chapter-NN-part-001`, `chapter-NN-part-002`, ...
+- Chapter labels resolved from the EPUB nav doc (when present) and from
+  the first in-document `<h2>`/`<h1>` heading
+- Project Gutenberg page-title collapse is gone: each chunk's title is the
+  chapter label, not the shared book title
+- TOC body section ("Contents") reclassified to `toc`; transcriber's notes
+  section reclassified to `notes`; section-role histogram is now
+  `body=67, cover=1, header=1, toc=1, notes=1, footer=2`
+- Page anchors of the form `id="Page_N"` are preserved per chunk via the
+  `page_anchors` provenance field (e.g. chapter-01 carries
+  `Page_1..Page_14` distributed across its three parts)
+- Optional `overlap_words` parameter supports evidence-window context
+  between adjacent parts of the same chapter without duplicating headings
+
+## Fixture Smoke Run (2026-05-17)
+
+`generate from-source ... --fixture-responses ... --max-chunks 3 --apply`
+against the real EPUB produced a complete infospace:
+
+- 3 source chunks (`chapter-01-part-001..003`) and 3 entities/relations/
+  evaluations plus the generation-summary report
+- `artifacts/index.yaml` carries full T01/T02 provenance on every source
+  artifact (`chapter_label`, `chapter_number`, `page_anchors`, OPF
+  `book_metadata`)
+- Metrics viable: `coverage=1.0`, `redundancy=0.0`, `granularity_entropy
+  ≈ 1.79`; viability gates pass
+- Repeated same-title entities upserted to single artifact files — basic
+  exact-title dedupe works; near-duplicate dedupe is still open
+
+Gaps the smoke surfaced for follow-on tasks:
+
+- `generation-summary.md` is just counts + metrics; needs entity titles,
+  chapter coverage, page-anchor links for review (T07)
+- No `plan` cost preview, no chapter/cost cap selection — running the full
+  book at default `max_words` is ~335 provider calls (T03)
+- Generic profile shaped the output, not Lefevre's trading vocabulary (T04)

docs/lefevre-readiness.md

@@ -0,0 +1,164 @@
+# Lefevre Infospace — Final Readiness Report
+
+Date: 2026-05-17
+Workplan: IB-WP-0016
+Status: ready for a single-chapter live run; full-book run gated on
+human review of that first chapter's output
+
+This is the human-facing readiness summary that closes IB-WP-0016. It
+records what is wired, where generated outputs live, what gets
+committed, the review checks a reviewer must perform before scaling
+beyond one chapter, and a few load-bearing risks that should be
+re-checked before any full-book run.
+
+## What is wired (T01–T06)
+
+- **T01 spine-aware EPUB3 intake.** Parses `META-INF/container.xml` and
+  the OPF package document; iterates documents in spine order; tags
+  every spine entry with a section role (`body`, `cover`, `nav`, `toc`,
+  `header`, `footer`, `notes`, `license`, `auxiliary`); excludes
+  non-body sections by default with an `include_non_body=True` opt-in.
+  Full OPF book metadata (title, creator, language, subjects, rights,
+  identifier, source_url, modified) reaches every chunk.
+- **T02 chapter-aware chunking and stable IDs.** Resolves chapter
+  labels from the nav doc and from in-document headings; parses roman
+  numerals and "Chapter N" labels into numeric indices; emits stable
+  IDs `chapter-NN` with `-part-NNN` suffix on multi-part chapters.
+  `id="Page_*"` anchors are extracted upfront and distributed per
+  chunk; an `overlap_words` parameter supports an evidence window
+  between adjacent parts.
+- **T03 scale-aware planning.** `generate plan` returns a compact
+  summary by default (selected chunks, per-workflow calls, prompt
+  tokens, rough USD). Selection filters `--chapter`, `--from-chapter`,
+  `--to-chapter`, `--chunk` and budget caps `--max-calls`, `--cost-cap`,
+  `--cost-per-1k` are all wired. `--full` opts back into the full
+  per-workflow plan when needed.
+- **T04 trading-literature profile.** Eight entity categories (trader,
+  market, strategy, error, psychological_pattern, institution,
+  instrument, evidence_bearing_claim), five relation types
+  (cause_effect, lesson_evidence, risk_mitigation, actor_venue,
+  strategy_outcome), four evaluation criteria (groundedness,
+  lesson_clarity, historical_context, overgeneralization_risk).
+- **T05 deterministic Lefevre fixture.** A checked-in Lefevre-shaped
+  EPUB fixture under `tests/fixtures/lefevre/` plus a trading-tuned
+  responses YAML. Three tests prove the full pipeline produces a
+  manifest-backed infospace with stable `chapter-NN.md` source slugs
+  and that PG boilerplate is excluded by default.
+- **T06 OpenRouter live-run guardrails.** `--chapter` selection on
+  `init` and `from-source` so a one-chapter live run is a one-flag
+  command. Provider metadata (model, request_id, usage tokens,
+  retry_count, duration_seconds) lives in run records *and* in the
+  generated artifact provenance under `provider_metadata`. The optional
+  live smoke test in `tests/test_openrouter_live.py` is gated on
+  `OPENROUTER_API_KEY` plus `INFOSPACE_BENCH_ENABLE_LIVE_OPENROUTER=1`.
+
+The IB-WP-0019 budget registry rides along: every `generate plan`
+appends a snapshot, every `generate run` writes a usage rollup +
+variance summary + a state-hub token event with failure isolation.
+
+## Output policy
+
+Where things live, and what to commit:
+
+| Path | Status | Notes |
+|---|---|---|
+| `tests/fixtures/lefevre/sources/` | **Committed** | Inspectable XHTML; the smoke test rebuilds the EPUB at test time. |
+| `tests/fixtures/lefevre/responses.yaml` | **Committed** | Trading-tuned fixture responses. |
+| `docs/` | **Committed** | This file, the validation note, generator docs. |
+| `infospaces/<slug>/` | **Disposable** | Generated infospaces — do not commit. |
+| `infospaces/<slug>/output/budget/` | **Disposable but archive-relevant** | Carried into archive packages by IB-WP-0014 / IB-WP-0019-T07. |
+| Live-run outputs (entities, relations, evaluations, reports) | **Review then archive** | After a successful chapter review, archive via `infospace-bench archive` rather than commit. |
+
+The repo gitignore already excludes `infospaces/` content at the
+working-copy level; the only Lefevre input shape committed today is the
+small fixture under `tests/fixtures/lefevre/`. Archived outputs live in
+the artifact-store registry, not in git.
+
+## Reviewer checklist (per chapter)
+
+Run after each chapter's generation completes and before scaling:
+
+1. **Duplicate entities.** `artifacts/entities/` and the report's
+   `## Entities` list. Look for near-duplicates (e.g. `Larry
+   Livingston` vs `The narrator`, or `Bucket Shop` vs
+   `Cosmopolitan Stock Brokerage Company` when the latter is intended
+   as a specific instance). Merge or split before continuing.
+2. **Relation endpoints.** Every relation's `## Subject` and
+   `## Object` should match an existing entity title. Anything that
+   does not should either gain an entity or be dropped.
+3. **Weak evidence.** Open the `## Evidence` section of each relation
+   and confirm it quotes a concrete phrase from the source chunk, not
+   a paraphrase. Relations with evidence like "the chapter implies…"
+   should be downgraded or removed.
+4. **Overgeneralization.** For every entity whose category is
+   `strategy`, `error`, `psychological_pattern`, or
+   `evidence_bearing_claim`, check the evaluation's
+   `overgeneralization_risk` score and read the `## Review Notes` it
+   produced. Anything that silently universalises a chapter-local
+   claim ("traders always…", "every market does…") should be
+   re-scoped or dropped.
+5. **Page anchor coverage.** The report's `## Page anchors` section
+   should show anchors actually present in the source. If the anchor
+   count is zero for a chapter that should have them, intake mis-fired.
+6. **Unmapped source chunks.** The report's `## Unmapped source
+   chunks` section must be empty before a full-book run. Any chunk
+   listed there had its entity or relation stage skip silently — fix
+   the underlying workflow or re-run with a different selection.
+7. **Plan-vs-actual variance.** `output/budget/summary.yaml` and the
+   "Plan variance" line of the report. If actual is more than 1.5×
+   estimated for either calls or tokens, re-plan before scaling.
+
+## Scale-up plan
+
+To go from a reviewed one-chapter run to the full Lefevre book:
+
+1. Re-plan against the full book: `infospace-bench generate plan
+   <root> --cost-per-1k <rate>` and inspect
+   `total_provider_calls_estimate`, `total_prompt_tokens_estimate`,
+   and `estimated_cost_usd`. The current real-book numbers are 730
+   calls / ~518k tokens / ~$155 at $0.30/1k.
+2. Pick a defensible cost-cap. If the plan shows estimated cost above
+   the cap, narrow selection with `--from-chapter`/`--to-chapter`
+   before running.
+3. Pick the final model. Confirm an entry exists in
+   `src/infospace_bench/model_rates.yaml` (or a workspace override) so
+   `cost_usd_estimated` lines up with reality. List prices drift —
+   refresh `captured_at` if older than 90 days.
+4. Run one chapter, review per the checklist above, then either
+   continue chapter-by-chapter or batch via
+   `--from-chapter`/`--to-chapter`. Resume is whole-run-skip today
+   (see Risks); avoid relying on it for partial recovery.
+5. After each successful range, archive the infospace with
+   `infospace-bench archive` so the budget log, the metrics, and the
+   generated artifacts all land in a single content-addressed package.
+
+## Risks still load-bearing
+
+These do not block a one-chapter run but should be re-checked before a
+full-book run:
+
+- **Cross-chunk entity dedupe.** Exact-title upsert works (same entity
+  title across chunks collapses to one file), but near-duplicate dedup
+  is still a reviewer responsibility. Plan: only proceed to multi-
+  chapter once a chapter's entity list has been hand-pruned.
+- **Whole-run resume.** `generate resume` skips a completed run; it
+  does not skip just-completed-chunks. For a real 24-chapter run that
+  fails midway, the safest recovery today is a new infospace with the
+  remaining chapter range — not resume on the original.
+- **Adaptive routing.** The current single-model run is fine for one
+  chapter but expensive at full-book scale. The cost-quality routing
+  layer is parked in `llm-connect` `LLM-WP-0004`; the consumer wiring
+  is parked in `infospace-bench` `IB-WP-0018`. Either land that work
+  first or accept the single-model bill.
+- **Provider rate drift.** The default rate table in
+  `src/infospace_bench/model_rates.yaml` captured prices on 2026-05-17.
+  Refresh before a full-book run if the file is older than 90 days.
+
+## Sign-off
+
+IB-WP-0016 T01–T07 are done. The pipeline can plan a chapter, run it
+against OpenRouter, write a manifest-backed infospace with provider
+metadata, record budget and variance, archive the result, and surface
+the review-oriented sections that this checklist depends on. The full
+Lefevre book is not yet a committed artifact and should not become one
+until at least one chapter has cleared the reviewer checklist above.

docs/legacy-command-parity.md

@@ -0,0 +1,98 @@
+# Legacy Command Parity
+
+Date: 2026-05-14
+
+## Purpose
+
+This guide maps the legacy `markitect infospace` command surface to the
+successor shape in `infospace-bench`, `markitect-tool`, and
+`kontextual-engine`.
+
+The goal is replacement readiness for in-scope infospace work, not a
+name-for-name CLI clone. `infospace-bench` keeps concrete infospaces,
+application semantics, evaluation history, and file-backed workflow fixtures.
+`markitect-tool` owns markdown parsing and validation primitives.
+`kontextual-engine` owns durable asset, graph, retrieval, audit, and workflow
+runtime concerns when those move beyond file-backed operation.
+
+## Status Values
+
+- `replaced`: use the successor command directly.
+- `reframed`: the behavior exists, but the user flow has a cleaner successor
+  shape.
+- `delegated`: the behavior belongs in a sibling repo and is consumed through
+  an adapter or contract.
+- `deferred`: still in scope, but not required for the current replacement
+  gate.
+- `retired`: the legacy behavior should not be rebuilt.
+
+## Command Map
+
+| Legacy command | Status | Successor command or API | Notes |
+| --- | --- | --- | --- |
+| `markitect infospace init` | replaced | `infospace-bench create <workspace> <slug> --name "<name>" --topic-domain "<domain>"` | Creates the file-backed `infospaces/<slug>/` layout and manifest. |
+| `markitect infospace status` | replaced | `infospace-bench status <root>` | JSON summary of config, artifact counts, parsed entities/relations, metrics, viability, history, and graph counts. |
+| `markitect infospace entities` | replaced | `infospace-bench entities <root>` or `infospace_bench.semantics.list_entities(root)` | Entity semantics are bench-owned and markdown parsing is delegated to `markitect-tool`. |
+| `markitect infospace chapters` | reframed | `infospace-bench export <root>` plus workflow/source artifact inspection | The successor tracks sources as manifest artifacts instead of a chapter-only table. A richer source triage command is deferred. |
+| `markitect infospace evaluate` | reframed | `infospace-bench workflow plan <root> <workflow_id>` and explicit assisted adapters | Provider-specific LLM calls are no longer hidden in the app CLI. Assisted stages are auditable and require an explicit adapter. |
+| `markitect infospace eval-summary` | reframed | `infospace-bench history <root> --metric per_artifact_mean` and `infospace-bench status <root>` | Evaluation results are structured artifacts plus metrics history, not a one-off text table. |
+| `markitect infospace relations` | replaced | `infospace-bench relations <root>` | Relation triplets resolve endpoints against parsed entity artifacts. |
+| `markitect infospace classify` | deferred | `infospace-bench workflow plan/run <root> <classification_workflow>` | Classification remains in scope as an explicit workflow, but provider execution is not part of this readiness gate. |
+| `markitect infospace viability` | replaced | `infospace-bench viability <root>` | Evaluates configured thresholds from persisted metrics. |
+| `markitect infospace check` | replaced | `infospace-bench check <root>` | Runs deterministic collection checks, persists metrics, appends history, and writes viability output. |
+| `markitect infospace history` | replaced | `infospace-bench history <root>` or `infospace-bench history <root> --metric <name>` | Reads file-backed metric snapshots. |
+| `markitect infospace history-diff` | replaced | `infospace-bench history-diff <root> <before> <after>` | Diffs snapshots by ID or date reference. |
+| `markitect infospace bind-discipline` | deferred | Edit `infospace.yaml` `disciplines` or add a later composition command | The config model supports discipline bindings; operational composition checks are a follow-up in `infospace-bench`. |
+| `markitect infospace process` | reframed | `infospace-bench workflow inspect|plan|run <root> <workflow_id>` | Workflows are explicit declarations with deterministic template stages and auditable assisted stages. |
+| `markitect infospace stale-mappings` | deferred | Future workflow/engine provenance comparison | Digest and provenance data now exist; stale mapping policy needs a dedicated follow-up. |
+| `markitect infospace graph` | replaced | `infospace-bench graph <root> --format json` or `--format mermaid` | Exports the artifact relationship graph from manifest relationships. |
+
+## Retired Legacy Shapes
+
+- Direct provider-specific LLM execution hidden behind a generic app command.
+- Automatic git commits from infospace processing commands.
+- Legacy output-directory conventions that bypass the artifact manifest.
+- Parser and schema code duplicated inside the application repo.
+
+## Replacement Examples
+
+Create and inspect an infospace:
+
+```bash
+infospace-bench create . wealth-vsm --name "Wealth through VSM" --topic-domain "Classical Economics"
+infospace-bench status infospaces/wealth-vsm
+```
+
+Validate, check, and view viability:
+
+```bash
+infospace-bench validate infospaces/wealth-vsm-legacy-slice
+infospace-bench check infospaces/wealth-vsm-legacy-slice
+infospace-bench viability infospaces/wealth-vsm-legacy-slice
+```
+
+Inspect semantic artifacts and graph:
+
+```bash
+infospace-bench entities infospaces/wealth-vsm-legacy-slice
+infospace-bench relations infospaces/wealth-vsm-legacy-slice
+infospace-bench graph infospaces/wealth-vsm-legacy-slice --format mermaid
+```
+
+Run explicit workflows:
+
+```bash
+infospace-bench workflow inspect infospaces/bootstrap-pilot
+infospace-bench workflow plan infospaces/bootstrap-pilot bootstrap-readiness
+infospace-bench workflow run infospaces/bootstrap-pilot bootstrap-readiness
+```
+
+Run the Wealth/VSM one-chapter generation pilot with deterministic assisted
+fixtures:
+
+```bash
+infospace-bench workflow run infospaces/wealth-vsm-generation-pilot wealth-vsm-extract-entities --fixture-responses infospaces/wealth-vsm-generation-pilot/workflows/fixtures/wealth-vsm-fake-responses.yaml
+infospace-bench workflow run infospaces/wealth-vsm-generation-pilot wealth-vsm-map-and-analyze --fixture-responses infospaces/wealth-vsm-generation-pilot/workflows/fixtures/wealth-vsm-fake-responses.yaml
+infospace-bench workflow run infospaces/wealth-vsm-generation-pilot wealth-vsm-evaluate-entities --fixture-responses infospaces/wealth-vsm-generation-pilot/workflows/fixtures/wealth-vsm-fake-responses.yaml
+infospace-bench check infospaces/wealth-vsm-generation-pilot
+```

docs/legacy-infospace-feature-inventory.md

@@ -0,0 +1,88 @@
+# Legacy Infospace Feature Inventory
+
+Date: 2026-05-14
+
+## Purpose
+
+This inventory records the in-scope infospace functionality from the original
+`markitect-project` / `markitect-main` and assigns each feature to its successor
+home across the three orthogonal repos:
+
+- `markitect-tool`: Markdown syntax and structured document primitives
+- `kontextual-engine`: durable knowledge operations engine
+- `infospace-bench`: concrete applied infospaces and evaluation methodology
+
+## Classification Values
+
+- **migrate**: bring the behavior into `infospace-bench` as application logic
+- **delegate**: consume the behavior from `markitect-tool` or
+  `kontextual-engine`
+- **reimplement**: rebuild the behavior with cleaner boundaries
+- **defer**: keep out of the first replacement pass
+- **retire**: do not preserve as a successor feature
+
+## Module Inventory
+
+| Legacy area | Main behavior | Classification | Successor home | Notes |
+| --- | --- | --- | --- | --- |
+| `markitect/infospace/config.py` | `infospace.yaml`, topic, disciplines, schemas, viability, pipeline dirs | migrate | `infospace-bench` | Application project model. Keep syntax simple and file-backed first. |
+| `markitect/infospace/entity_parser.py` | Parse entity Markdown into entity metadata | reimplement + delegate | `infospace-bench` + `markitect-tool` | Bench owns entity semantics; tool owns Markdown parsing. |
+| `markitect/infospace/relation_parser.py` | Parse relation triplet Markdown | reimplement + delegate | `infospace-bench` + `markitect-tool` | Same split as entities. |
+| `markitect/infospace/schema.py` | Entity schema shape | delegate + migrate configs | `markitect-tool` + `infospace-bench` | Generic validation belongs in tool; selected schemas/contracts belong in bench pilots. |
+| `markitect/infospace/validator.py` | Entity compliance diagnostics | reimplement + delegate | `infospace-bench` + `markitect-tool` | Tool emits diagnostics; bench maps them to infospace artifacts. |
+| `markitect/infospace/evaluation.py` | Score/evaluation/snapshot/diff models | migrate | `infospace-bench` | Already started in baseline. |
+| `markitect/infospace/evaluation_io.py` | Read/write evaluations, snapshots, history | migrate | `infospace-bench` | Next parity step. |
+| `markitect/infospace/evaluate.py` | LLM evaluation prompts and batch execution | reimplement | `infospace-bench` + provider adapter | Bench owns evaluation contract; provider calls stay optional and auditable. |
+| `markitect/infospace/checks/*` | Redundancy, coverage, coherence, consistency, granularity | reimplement | `infospace-bench` | Bench owns methodology; can use tool/engine data. |
+| `markitect/infospace/history.py` | Metrics file, history snapshots, trends | migrate | `infospace-bench` | File-backed first, engine-backed later. |
+| `markitect/infospace/state.py` | Computed infospace state and viability | migrate | `infospace-bench` | Application-level state summary. |
+| `markitect/infospace/composition.py` | Bind one infospace as a discipline/lens | migrate | `infospace-bench` | Concrete infospace composition. |
+| `markitect/infospace/classification*` | Entity typing, VSM system labels, classification summaries | reimplement | `infospace-bench` | Application semantics, especially for reference pilots. |
+| `markitect/infospace/relation_models.py` | Relation metadata model | migrate | `infospace-bench` | Application graph semantics. |
+| `markitect/infospace/graph_export.py` | Entity/relation graph, Mermaid/DOT exports, filters | reimplement | `infospace-bench` | Bench owns semantic graph; output can remain file-backed. |
+| `markitect/infospace/pipeline.py` | Source-to-output processing stages and follow-ups | reimplement + delegate | all three | Bench defines workflows, tool transforms Markdown, engine eventually orchestrates/persists runs. |
+| `examples/infospace-with-history` | Wealth of Nations/VSM reference experiment | migrate pruned slice | `infospace-bench` | Full generated bulk is deferred; representative fixture comes first. |
+
+## Legacy CLI Inventory
+
+| Legacy command | Behavior | Classification | Target replacement |
+| --- | --- | --- | --- |
+| `infospace init` | Create a config file | migrate | `infospace-bench create` plus richer template support |
+| `infospace status` | Summarize config, entities, domains, evaluations | reimplement | `infospace-bench inspect/status` |
+| `infospace entities` | List parsed entities | reimplement | `IB-WP-0007` entity listing |
+| `infospace chapters` | Source/chapter triage | reimplement | `IB-WP-0009` workflow/source status |
+| `infospace evaluate` | Run per-entity LLM evaluation | reimplement | `IB-WP-0008`/`IB-WP-0009` evaluation workflow |
+| `infospace eval-summary` | Summarize evaluation scores | reimplement | `IB-WP-0008` metrics/evaluation report |
+| `infospace relations` | List and filter relations | reimplement | `IB-WP-0007` relation listing |
+| `infospace classify` | Classify entities | reimplement | `IB-WP-0007`/later classifier workflow |
+| `infospace classify-summary` | Summarize classifications | reimplement | `IB-WP-0007`/`IB-WP-0008` reports |
+| `infospace classify-links` | Assisted relation/classification linking | defer | Keep until entity/relation parity exists |
+| `infospace viability` | Check metrics against thresholds | migrate | Already started; expand in `IB-WP-0008` |
+| `infospace check` | Run collection checks | reimplement | Already started; expand in `IB-WP-0008` |
+| `infospace history` | Show metric history/trends | migrate | `IB-WP-0008` |
+| `infospace history-diff` | Diff snapshots | migrate | `IB-WP-0008` |
+| `infospace bind-discipline` | Bind reusable discipline infospace | migrate | `IB-WP-0007`/composition follow-up |
+| `infospace process` | Run source processing pipeline | reimplement + delegate | `IB-WP-0009` |
+| `infospace stale-mappings` | Identify stale generated mappings | defer | After workflow provenance and digests exist |
+| `infospace graph` | Export filtered semantic graph | reimplement | `IB-WP-0007`/`IB-WP-0008` |
+
+## Example And Output Inventory
+
+| Legacy artifact | Classification | Target |
+| --- | --- | --- |
+| `examples/infospace-with-history/infospace.yaml` | migrate pruned | `IB-WP-0011` |
+| Source chapter Markdown files | migrate pruned | `IB-WP-0011` |
+| Entity, relation, mapping, analysis schemas | delegate + migrate fixtures | `IB-WP-0006`, `IB-WP-0011` |
+| Prompt templates | reimplement | `IB-WP-0009` |
+| Generated analyses/entities/classifications | migrate minimal fixtures | `IB-WP-0011` |
+| Processing logs | reimplement | `IB-WP-0009` |
+| Metrics history | migrate minimal fixtures | `IB-WP-0008`, `IB-WP-0011` |
+| Tutorial/methodology docs | migrate selectively | `IB-WP-0011`, `IB-WP-0012` |
+
+## Retired Or Explicitly Not First-Pass
+
+- Legacy imports of `markitect.core.*` inside infospace modules.
+- Direct provider-specific LLM wiring inside application code.
+- Bulk generated output from the large reference experiment.
+- Any database-backed lifecycle behavior that belongs in `kontextual-engine`.
+- Rendering/plugin/asset subsystems unrelated to infospace evaluation.

docs/legacy-infospace-migration-guide.md

@@ -0,0 +1,78 @@
+# Legacy Infospace Migration Guide
+
+Date: 2026-05-14
+
+## Purpose
+
+Use this guide when moving an in-scope legacy MarkiTect infospace into
+`infospace-bench`.
+
+The successor split is intentionally orthogonal:
+
+- `markitect-tool`: markdown parsing, section extraction, contracts, templates.
+- `infospace-bench`: concrete infospace layout, manifests, semantic entity and
+  relation models, checks, viability, evaluation history, pilots, and reports.
+- `kontextual-engine`: durable assets, relationship indexes, retrieval,
+  workflow runtime, permissions, and audit when file-backed operation is no
+  longer enough.
+
+## Migration Path
+
+1. Create a successor workspace with `infospace-bench create`.
+2. Copy source material into `artifacts/sources/`.
+3. Register each source in `artifacts/index.yaml` with a stable artifact ID.
+4. Move only in-scope generated entities and relations into
+   `artifacts/entities/` and `artifacts/relations/`.
+5. Add markdown contracts under `contracts/` when validation is needed, then
+   point `infospace.yaml` `schemas` at those contracts.
+6. Convert legacy entity evaluation files to use `artifact_id` rather than
+   entity-only slugs.
+7. Move metrics snapshots into `output/metrics/history.yaml` and current values
+   into `output/metrics/metrics.yaml`.
+8. Express generation or review work as explicit workflow declarations in
+   `infospace.yaml`.
+9. Use `infospace-bench engine plan-sync` to check the optional engine asset
+   boundary before applying any durable sync.
+10. Write a migration report under `reports/` that names replaced, delegated,
+    deferred, and retired behavior.
+
+## Verification Commands
+
+```bash
+infospace-bench status <root>
+infospace-bench validate <root>
+infospace-bench entities <root>
+infospace-bench relations <root>
+infospace-bench check <root>
+infospace-bench viability <root>
+infospace-bench history <root>
+infospace-bench graph <root> --format mermaid
+infospace-bench engine plan-sync <root>
+```
+
+## What Moves Where
+
+| Legacy concern | Successor home | Migration note |
+| --- | --- | --- |
+| Markdown headings, frontmatter, contract checks | `markitect-tool` | Keep access through `infospace_bench.markdown_adapter`. |
+| Entity and relation semantics | `infospace-bench` | Keep domain concepts in file-backed artifacts and manifests. |
+| Evaluation files and metrics history | `infospace-bench` | Preserve history with `artifact_id` and deterministic metrics. |
+| LLM prompt execution | `infospace-bench` workflow boundary plus adapters | Plans must be dry-runnable; provider calls require explicit adapters. |
+| Durable asset identity and graph indexes | `kontextual-engine` | Use `engine plan-sync` and `engine sync --apply` when needed. |
+| Retrieval, permissions, audit | `kontextual-engine` | Do not recreate these inside `infospace-bench`. |
+
+## Non-Goals
+
+- Migrating every legacy generated file just because it exists.
+- Preserving legacy output directory names when manifest IDs are clearer.
+- Rebuilding provider-specific LLM wiring inside `infospace-bench`.
+- Recreating prompt/runtime infrastructure that belongs to `kontextual-engine`.
+- Treating `infospace-bench` as a markdown parser library.
+
+## Pilot Pattern
+
+The `infospaces/wealth-vsm-legacy-slice/` pilot is the reference pattern for a
+small legacy migration. It keeps a pruned source excerpt, two entities, one
+relation, one migrated evaluation, metrics/history fixtures, validation
+contracts, and a report that explains what was intentionally left behind.
+

docs/markitect-tool-adapter.md

@@ -0,0 +1,68 @@
+# Markitect Tool Adapter
+
+Date: 2026-05-14
+
+## Purpose
+
+`infospace-bench` delegates Markdown syntax work to `markitect-tool` through a
+single narrow adapter:
+
+```text
+src/infospace_bench/markdown_adapter.py
+```
+
+This keeps the repos orthogonal:
+
+- `markitect-tool` parses and validates Markdown.
+- `infospace-bench` interprets parsed/validated artifacts as parts of concrete
+  infospaces.
+
+## Current Adapter Surface
+
+- `parse_markdown_artifact(path)`
+- `extract_section_text(parsed, heading)`
+- `validate_markdown_artifact(artifact_id, path, contract_path)`
+- `validate_infospace_artifacts(root)`
+
+The adapter normalizes `markitect-tool` diagnostics into
+`MarkdownDiagnostic`, preserving severity, code, message, source, contract,
+rule, guidance, and details.
+
+## Contract Selection
+
+`validate_infospace_artifacts()` reads `infospace.yaml` and uses the `schemas`
+mapping as artifact-kind contract references:
+
+```yaml
+schemas:
+  source: contracts/source.contract.md
+  generated: contracts/generated.contract.md
+```
+
+If no contract is configured for an artifact kind, validation skips that
+artifact. If a configured contract path is missing, validation raises a
+structured `InfospaceError`.
+
+## CLI
+
+```bash
+python3 -m infospace_bench validate infospaces/bootstrap-pilot
+```
+
+The command emits JSON:
+
+```json
+{
+  "valid": true,
+  "results": []
+}
+```
+
+It exits with `0` when all checked artifacts are valid and `1` when any checked
+artifact fails validation.
+
+## Boundary Rule
+
+Only `src/infospace_bench/markdown_adapter.py` should import `markitect_tool`.
+Other modules should consume adapter results so `infospace-bench` remains an
+application layer, not a Markdown toolkit.

docs/orthogonal-successor-roadmap.md

@@ -60,6 +60,12 @@ The following `infospace-bench` workplans establish the path:
 7. `IB-WP-0011` — Pruned legacy reference pilot migration
 8. `IB-WP-0012` — Replacement readiness and CLI parity gate
 
+Supporting architecture artifacts:
+
+- `docs/legacy-infospace-feature-inventory.md`
+- `docs/successor-boundary-interface-map.md`
+- `docs/replacement-acceptance-matrix.md`
+
 ## Sequencing
 
 ```text

docs/replacement-acceptance-matrix.md

@@ -0,0 +1,98 @@
+# Replacement Acceptance Matrix
+
+Date: 2026-05-14
+
+## Purpose
+
+This matrix defines what evidence is required before `infospace-bench` can be
+considered a replacement for each in-scope legacy infospace behavior from
+`markitect-project`.
+
+## Matrix
+
+| Legacy behavior | Successor behavior | Evidence required | Workplan | Status |
+| --- | --- | --- | --- | --- |
+| Create an infospace config | File-backed `infospaces/<slug>/infospace.yaml` and manifest | Lifecycle tests, CLI create/inspect docs | `IB-WP-0002` | baseline done |
+| Load and inspect an infospace | Structured config/artifact model and JSON CLI | Tests for load, missing config, structured errors | `IB-WP-0002` | baseline done |
+| Add/list artifacts | Manifest-backed artifact registration | Tests for add, duplicate rejection, inspect output | `IB-WP-0002` | baseline done |
+| Parse entity Markdown | Entity parser built on `markitect-tool` document sections | Entity fixture tests, diagnostics for missing sections | `IB-WP-0006`, `IB-WP-0007` | done |
+| Validate entity/relation shape | Contract/schema validation through `markitect-tool` | Valid/invalid fixture tests, diagnostic mapping | `IB-WP-0006`, `IB-WP-0007` | baseline done |
+| List entities | Entity listing from parsed artifact model | CLI/API example and fixture tests | `IB-WP-0007` | done |
+| Parse and list relations | Relation triplet model and endpoint checks | Relation fixture tests, graph edge tests | `IB-WP-0007` | done |
+| Export semantic graph | Infospace graph model with Mermaid/DOT output | Graph output tests and pilot report | `IB-WP-0007`, `IB-WP-0008` | partial baseline |
+| Run collection checks | Methodology-owned metrics in `infospace-bench` | Deterministic metric tests and fixture output | `IB-WP-0008` | partial baseline |
+| Check viability | Threshold report from metrics | Viability tests and CLI/report output | `IB-WP-0008` | partial baseline |
+| Write evaluation results | Evaluation files with structured metadata | Round-trip tests and pilot fixture | `IB-WP-0008` | done |
+| Maintain metrics history | Snapshot history append/read/diff | History and history-diff tests | `IB-WP-0008` | done |
+| Evaluate with LLM assistance | Provider-neutral assisted evaluation workflow | Dry-run plan, adapter contract, audited output | `IB-WP-0009` | boundary done |
+| Process source chapters | Explicit infospace workflow stages | Deterministic runner tests, generated artifact provenance | `IB-WP-0009` | deterministic baseline done |
+| Track stale outputs | Digest/provenance comparison | Tests after workflow provenance exists | `IB-WP-0009` | deferred |
+| Persist durable assets | Optional engine-backed repository adapter | Dry-run sync tests and integration design | `IB-WP-0010` | boundary done |
+| Run a legacy-derived pilot | Pruned `infospace-with-history` migration | Pilot corpus, migration report, parity comparison | `IB-WP-0011` | done |
+| Provide command migration path | Legacy command parity guide | Command table, examples, migration guide, decision record, acceptance tests | `IB-WP-0012` | done |
+| Regenerate Wealth/VSM pilot | Explicit assisted workflows and deterministic fixtures | One-chapter generation tests, bundle splitting, evaluation metrics, scale-up docs | `IB-WP-0013` | done |
+
+## Replacement Gates
+
+### Gate A: Syntax Delegation
+
+Passes when all Markdown parsing and validation in `infospace-bench` goes
+through the `markitect-tool` adapter.
+
+Required workplans:
+
+- `IB-WP-0006`
+
+### Gate B: Application Semantics
+
+Passes when entities, relations, metrics, viability, evaluation history, and
+graphs work over real fixtures.
+
+Required workplans:
+
+- `IB-WP-0007`
+- `IB-WP-0008`
+
+### Gate C: Workflow Parity
+
+Passes when deterministic source-to-output workflows replace the old `process`
+command shape and assisted stages are explicit, dry-runnable, and auditable.
+
+Required workplans:
+
+- `IB-WP-0009`
+
+### Gate D: Engine Boundary
+
+Passes when file-backed operation remains the default and `kontextual-engine`
+integration is available through an explicit adapter contract.
+
+Required workplans:
+
+- `IB-WP-0010`
+
+### Gate E: Legacy Pilot Proof
+
+Passes when a pruned legacy pilot demonstrates the successor stack on migrated
+content.
+
+Required workplans:
+
+- `IB-WP-0011`
+- `IB-WP-0012`
+
+## Non-Goals
+
+- Full CLI name-for-name compatibility with legacy `markitect infospace`.
+- Moving low-level Markdown parser code into `infospace-bench`.
+- Recreating legacy prompt/provider code directly.
+- Committing the full generated Wealth of Nations/VSM output tree as the first
+  pilot.
+- Building a database or workflow engine inside `infospace-bench`.
+
+## Readiness Statement
+
+`infospace-bench` is replacement-ready for new in-scope infospace work. It is
+not a name-for-name clone of the old `markitect infospace` CLI; remaining gaps
+are explicitly owned by `infospace-bench`, `markitect-tool`, or
+`kontextual-engine` in `docs/replacement-readiness-decision.md`.

docs/replacement-readiness-decision.md

@@ -0,0 +1,52 @@
+---
+id: IB-DR-0012
+title: Replacement Readiness Decision
+date: "2026-05-14"
+decision: replacement-ready-for-new-in-scope-infospace-work
+status: accepted
+workplan: IB-WP-0012
+---
+
+# Replacement Readiness Decision
+
+## Decision
+
+`infospace-bench` is replacement-ready for new in-scope infospace work that was
+previously attempted inside `markitect-project` / `markitect-main`.
+
+Not a name-for-name CLI clone: replacement readiness means the successor stack
+has an evidence-backed migration path, tests, pilots, and explicit ownership for
+remaining gaps.
+
+## Evidence
+
+- Lifecycle, manifest, validation, entity/relation parsing, checks, viability,
+  history, workflows, engine sync planning, and CLI behavior are covered by the
+  test suite.
+- `infospaces/bootstrap-pilot/` proves the repo-native lifecycle and workflow
+  baseline.
+- `infospaces/wealth-vsm-legacy-slice/` proves a pruned legacy migration from
+  the old Wealth/VSM experiment.
+- `docs/legacy-command-parity.md` gives users a command and API migration path.
+- `docs/legacy-infospace-migration-guide.md` gives a repeatable migration
+  process.
+
+## Residual Gaps And Owners
+
+| Gap | Owner | Decision |
+| --- | --- | --- |
+| Rich source/chapter triage view | `infospace-bench` | Deferred; use manifest export and workflows meanwhile. |
+| Classification workflow fixtures | `infospace-bench` | Deferred; implement as explicit workflows, not hidden provider calls. |
+| Discipline composition command | `infospace-bench` | Deferred; config support exists, operational checks need a focused follow-up. |
+| Stale mapping detection | `infospace-bench` + `kontextual-engine` | Deferred until provenance policy and durable asset comparison are settled. |
+| Durable graph/retrieval/runtime | `kontextual-engine` | Delegated by design. |
+| Markdown parser/schema engine | `markitect-tool` | Delegated by design. |
+
+## Consequences
+
+- New in-scope infospace work should start in `infospace-bench`.
+- Low-level markdown behavior should be added to `markitect-tool`.
+- Durable runtime concerns should be integrated through `kontextual-engine`
+  boundaries rather than built into this repo.
+- Legacy bulk generated output should be migrated only when it has a current,
+  scoped use and can be covered by tests.

docs/routing-config.md

@@ -0,0 +1,131 @@
+# Routing Config Schema
+
+Workplan: IB-WP-0020 (T01 schema, T02 loader)
+Module: `src/infospace_bench/routing_config.py`
+
+A routing config is a small YAML file that names the candidate adapters
+per task type and (optionally) the quality floor, the
+`QualityLedger` path, and a stage-to-task-type override map. The file
+is the consumer side of llm-connect `LLM-WP-0004`'s routing primitives:
+it does not embed model selection logic, just declares the universe
+the policy can choose from.
+
+The schema_version is pinned to `1`. Bump it (and the parser) before
+making backward-incompatible changes.
+
+## Top-level fields
+
+| Field | Type | Notes |
+|---|---|---|
+| `schema_version` | int (required) | Currently `1`. Mismatch fails fast. |
+| `task_types` | mapping (required) | At least one entry. Each entry has `candidates` and an optional `quality_floor`. |
+| `default_quality_floor` | float (optional) | Falls back when a task type does not name its own. Must be 0..1. |
+| `ledger_path` | string (optional) | Path to a `QualityLedger` JSONL. Relative paths resolve against the workspace by default. Required when any `quality_floor` is non-null. |
+| `stage_to_task_type` | mapping (optional) | Caller-supplied mapping from infospace-bench stage ids to task types. Falls through to identity when omitted. |
+
+## Candidate fields
+
+Each entry under `task_types.<task_type>.candidates[]`:
+
+| Field | Type | Notes |
+|---|---|---|
+| `id` | string (required) | Stable adapter id used for the `QualityLedger` and the per-stage adapter-choice line of the generation report. |
+| `provider` | string (required) | One of `openrouter`, `claude_code`, `openai`, `gemini`. |
+| `model` | string (required) | Provider-specific model id, e.g. `openai/gpt-4o-mini`. |
+| `api_key_env` | string (optional) | Env var that holds the API key. Defaults to a provider-specific name (`OPENROUTER_API_KEY` etc.) in the T02 loader. |
+| `max_cost_per_1k` | float (optional) | Static cost cap. Static `RoutingPolicy` falls back to a cheaper candidate when the caller-supplied estimate exceeds this. |
+
+## Example A — OpenRouter-only, two-tier
+
+A pragmatic Lefevre-style config. Cheap model for summaries, mid model
+for entities/relations, cheap again for evaluation. No adaptive
+routing, no ledger.
+
+```yaml
+schema_version: 1
+
+stage_to_task_type:
+  summarize-source: cheap
+  extract-entities: smart
+  extract-relations: smart
+  evaluate-entity: cheap
+  synthesize-report: smart
+
+task_types:
+  cheap:
+    candidates:
+      - id: openrouter:gpt-4o-mini
+        provider: openrouter
+        model: openai/gpt-4o-mini
+        api_key_env: OPENROUTER_API_KEY
+  smart:
+    candidates:
+      - id: openrouter:claude-3.5-sonnet
+        provider: openrouter
+        model: anthropic/claude-3.5-sonnet
+        api_key_env: OPENROUTER_API_KEY
+```
+
+## Example B — Adaptive with a ClaudeCode baseline
+
+A two-candidate-per-stage adaptive config. The `QualityLedger`
+accumulates observations; over time, the cheaper qualifying model is
+preferred per stage. `ClaudeCodeAdapter` is wired into a separate
+`task_types.baseline` rule so it can be referenced by a
+`ShadowingAdapter` builder (T05).
+
+```yaml
+schema_version: 1
+default_quality_floor: 0.80
+ledger_path: output/routing/quality.jsonl
+
+task_types:
+  summarize-source:
+    quality_floor: 0.70
+    candidates:
+      - id: openrouter:gpt-4o-mini
+        provider: openrouter
+        model: openai/gpt-4o-mini
+        api_key_env: OPENROUTER_API_KEY
+        max_cost_per_1k: 0.001
+      - id: openrouter:claude-3.5-haiku
+        provider: openrouter
+        model: anthropic/claude-3.5-haiku
+        api_key_env: OPENROUTER_API_KEY
+        max_cost_per_1k: 0.003
+
+  extract-entities:
+    quality_floor: 0.85
+    candidates:
+      - id: openrouter:claude-3.5-haiku
+        provider: openrouter
+        model: anthropic/claude-3.5-haiku
+        api_key_env: OPENROUTER_API_KEY
+      - id: openrouter:claude-3.5-sonnet
+        provider: openrouter
+        model: anthropic/claude-3.5-sonnet
+        api_key_env: OPENROUTER_API_KEY
+
+  baseline:
+    candidates:
+      - id: claude-code
+        provider: claude_code
+        model: claude-opus-4-7
+```
+
+## What fails fast
+
+The parser refuses, before any network or workspace work, when:
+
+- `schema_version` is missing or not `1`
+- `task_types` is missing or empty
+- Any `task_type` has no `candidates`
+- A candidate is missing `id`, `provider`, or `model`
+- A `provider` is not one of the supported names
+- `max_cost_per_1k` is non-numeric or negative
+- Any `quality_floor` (top-level or per-task) is outside 0..1
+- A `task_type` has duplicate candidate `id`s
+- `ledger_path` or `stage_to_task_type` has the wrong YAML shape
+
+`api_key_env` resolution and live adapter construction happen in T02.
+This file only validates the declarative shape.

docs/routing-task-types.md

@@ -0,0 +1,78 @@
+# Task-Type Taxonomy for Routing
+
+Workplan: IB-WP-0018 (T01)
+Depends on: llm-connect LLM-WP-0004 (RoutingPolicy, AdaptiveRoutingPolicy)
+
+This file names the task types that infospace-bench emits when it routes
+each generation stage through llm-connect. The names are the consumer
+side of LLM-WP-0004's scope guardrail: llm-connect ships the routing
+primitives, infospace-bench owns the taxonomy.
+
+## Default identity mapping
+
+`RoutingAssistedGenerationAdapter` (see `src/infospace_bench/routing.py`)
+maps stage ids to task types using the identity mapping below by
+default. Callers override individual entries via
+`RoutingAssistedGenerationAdapter(..., stage_to_task_type={...})`.
+
+| Stage id | Task type | Notes |
+|---|---|---|
+| `summarize-source` | `summarize-source` | One call per source chunk. Cheap, high-volume; small models usually clear the bar. |
+| `extract-entities` | `extract-entities` | One call per source chunk. Quality matters most here — bad extractions cascade. |
+| `extract-relations` | `extract-relations` | One call per source chunk. Quality close to extraction; relations rely on entity titles being stable. |
+| `evaluate-entity` | `evaluate-entity` | One call per generated entity. Cheap, often a different model than extraction to avoid self-grading. |
+| `synthesize-report` | `synthesize-report` | One call at the end. Volume-of-one; quality matters; cost negligible. |
+
+## Quality expectations
+
+`AdaptiveRoutingPolicy.resolve(task_type, quality_floor=...)` picks the
+cheapest adapter whose ledger-observed mean quality clears the floor.
+The recommended starting floors:
+
+| Task type | Quality floor | Rationale |
+|---|---|---|
+| `summarize-source` | 0.70 | Summaries are intermediate. Slight quality loss is recoverable downstream. |
+| `extract-entities` | 0.85 | Entities are the durable output. Be strict. |
+| `extract-relations` | 0.80 | Relations depend on entities; slightly looser is OK as long as evidence is intact. |
+| `evaluate-entity` | 0.80 | Judge-level reliability. Self-grading bias is more of a concern than absolute score. |
+| `synthesize-report` | 0.70 | The report is a review surface; tolerate looser language for cheaper models. |
+
+These are starting points. Bind them at the calling site
+(`RoutingAssistedGenerationAdapter(..., quality_floor=0.85)` for
+extraction stages) — they are not enforced by this taxonomy.
+
+## Common overrides
+
+Callers may want to **collapse** task types to share observations across
+related stages, or **split** a task type to pin a specific model to a
+narrow workload. Two illustrative overrides:
+
+```python
+# Collapse extraction stages so a single ledger drives both
+stage_to_task_type = {
+    "extract-entities": "extraction",
+    "extract-relations": "extraction",
+}
+```
+
+```python
+# Split entity evaluation by category — useful when a profile has very
+# different quality bars for different entity categories (e.g.
+# trading-literature's `evidence_bearing_claim` is harder to judge than
+# `instrument`).
+stage_to_task_type = {
+    "evaluate-entity": "judge",
+}
+```
+
+Anything not in the override map falls through to the identity mapping.
+
+## What this taxonomy does NOT decide
+
+- **Which adapter ships per task type.** That belongs to the caller's
+  `RoutingPolicy` rule list.
+- **Where the quality ledger lives.** Caller-supplied path on the
+  `AdaptiveRoutingPolicy`.
+- **When to refresh observations.** Caller decides via the ledger's TTL
+  helpers in llm-connect.
+- **What a quality score means.** Each judge defines its own.

docs/successor-boundary-interface-map.md

@@ -0,0 +1,150 @@
+# Successor Boundary And Interface Map
+
+Date: 2026-05-14
+
+## Purpose
+
+This document defines the operational boundary between `infospace-bench`,
+`markitect-tool`, and `kontextual-engine` for the infospace successor effort.
+
+## Direction Of Dependency
+
+```text
+infospace-bench
+  uses markitect-tool for Markdown syntax capabilities
+  optionally uses kontextual-engine for durable operational state
+
+markitect-tool
+  does not depend on infospace-bench
+  does not depend on kontextual-engine for core syntax behavior
+
+kontextual-engine
+  may call syntax adapters such as markitect-tool for Markdown ingestion
+  does not depend on infospace-bench for engine identity
+```
+
+## What `infospace-bench` Expects From `markitect-tool`
+
+`infospace-bench` should consume a narrow adapter over `markitect-tool`.
+
+Required capabilities:
+
+- Parse Markdown files into structured document objects.
+- Expose headings, sections, frontmatter, source locations, and blocks.
+- Validate Markdown files against schemas/contracts.
+- Return structured diagnostics with source locations.
+- Resolve references and deterministic transformations where workflows need
+  Markdown-native composition.
+- Provide stable CLI/library behavior that can be used in tests and agents.
+
+`infospace-bench` should not:
+
+- Reimplement Markdown tokenization or section-tree parsing.
+- Re-export the entire `markitect-tool` API.
+- Add infospace-specific concepts to `markitect-tool`.
+
+## What `infospace-bench` Expects From `kontextual-engine`
+
+`kontextual-engine` is optional at first. File-backed behavior remains the
+default until engine integration is explicitly implemented.
+
+Expected future capabilities:
+
+- Durable asset identity for source and generated artifacts.
+- Metadata and provenance storage.
+- Relationship storage and retrieval.
+- Search, filtering, and query access over knowledge assets.
+- Workflow run records and operational audit trails.
+- Permission and review gates for agent-safe operations.
+- Transform records that link inputs, configuration, actor, and outputs.
+
+`infospace-bench` should not:
+
+- Become a persistence engine.
+- Build its own general retrieval platform.
+- Own generic permissions, audit, or workflow orchestration primitives.
+
+## What Remains File-Backed In `infospace-bench`
+
+File-backed behavior is part of the application contract and should remain
+first-class:
+
+- `infospaces/<slug>/infospace.yaml`
+- `artifacts/index.yaml`
+- source and generated artifact fixtures
+- evaluation files
+- metrics and history files
+- inspection reports
+- exports
+- reference pilot corpora
+
+The file-backed implementation is the testable baseline. Engine-backed
+operation should behave like a durable backend for the same application model,
+not a replacement for inspectable project artifacts.
+
+## Adapter Boundaries
+
+### Markdown Adapter
+
+Planned module:
+
+```text
+src/infospace_bench/markdown_adapter.py
+```
+
+Responsibilities:
+
+- call `markitect_tool.parse_markdown_file`
+- extract named sections by heading
+- call `markitect_tool` validation APIs
+- normalize diagnostics into `infospace-bench` result/error objects
+
+### Repository Adapter
+
+Current module:
+
+```text
+src/infospace_bench/engine.py
+```
+
+Responsibilities:
+
+- provide local file-backed artifact reads/writes
+- expose an `AssetRepository` protocol
+- provide `LocalAssetRepository` as the default adapter
+- later provide `kontextual-engine` backed asset lookup/sync
+- expose dry-run sync plans before mutation
+- keep provenance and digest handling explicit
+
+### Workflow Adapter
+
+Planned module:
+
+```text
+src/infospace_bench/workflow.py
+```
+
+Responsibilities:
+
+- load workflow definitions from `infospace.yaml`
+- run deterministic file-backed stages
+- delegate Markdown operations to `markitect-tool`
+- define assisted-stage contracts without binding to a provider
+- later submit or mirror workflow runs to `kontextual-engine`
+
+## Cross-Repo Non-Goals
+
+- `markitect-tool` should not learn about concrete infospaces.
+- `kontextual-engine` should not become a Markdown-specific runtime.
+- `infospace-bench` should not become a general platform or engine.
+- No repo should reproduce the old `markitect-project` monolith by accretion.
+
+## First Integration Slice
+
+The first implementation slice after this architecture workplan is
+`IB-WP-0006`:
+
+1. Add `markitect-tool` as a local dependency.
+2. Add a narrow Markdown adapter.
+3. Validate real infospace artifacts through `markitect-tool`.
+4. Keep all tests deterministic and file-backed.

docs/wealth-vsm-generation-pipeline.md

@@ -0,0 +1,76 @@
+# Wealth VSM Generation Pipeline
+
+Date: 2026-05-14
+
+## Purpose
+
+This document defines how `infospace-bench` regenerates the Adam Smith
+`Wealth of Nations` / VSM infospace through explicit workflows.
+
+The successor path is workflow-first. It does not reuse the legacy
+`process_chapters.py` entrypoint, hide provider calls in a broad command, or
+write generated files outside the artifact manifest.
+
+## Legacy pipeline decomposition
+
+The old Wealth/VSM experiment in `markitect-main` processed source chapters
+through these conceptual stages:
+
+| Legacy stage | Successor workflow shape | Notes |
+| --- | --- | --- |
+| `extract-entities` | `wealth-vsm-extract-entities` assisted stage plus `split_entities` stage | Assisted output is a chapter entity bundle; bench splits and registers stable entity artifacts. |
+| `map-to-vsm` | `wealth-vsm-map-and-analyze` assisted relation stage | Relation artifacts use the successor relation parser and manifest IDs. |
+| `synthesize-analysis` | `wealth-vsm-map-and-analyze` assisted analysis stage | Analysis remains a generated artifact with source provenance. |
+| `evaluate-entity` | `wealth-vsm-evaluate-entities` assisted stage | Evaluation files use successor `artifact_id` frontmatter. |
+| `assess-metrics` | `infospace-bench check` | Deterministic checks merge generated evaluations into metrics and history. |
+
+The first golden target is Book I Chapter III because it grounds the existing
+`wealth-vsm-legacy-slice` pilot and exercises the market-extent relation.
+
+## One-chapter pilot
+
+`infospaces/wealth-vsm-generation-pilot/` contains:
+
+- one source excerpt: `book-1-chapter-03.md`
+- explicit workflow declarations for extraction, VSM mapping/analysis, and
+  entity evaluation
+- deterministic fixture responses for tests
+- markdown contracts for generated entity and relation artifacts
+- a pilot report comparing the successor workflow shape with the legacy
+  process script
+
+Default tests use fixture responses so they do not require network access,
+provider credentials, or live model output.
+
+## Live provider-backed generation
+
+Any live provider-backed generation should use the same workflow declarations and
+the same assisted request records. Provider adapters must be selected
+explicitly by the caller and should record provider metadata in workflow run
+records and artifact provenance.
+
+Live runs should document:
+
+- provider and model
+- prompt/template version
+- source corpus selection
+- retry and rate-limit settings
+- expected cost range
+- resume strategy
+- generated artifact review status
+
+## Full corpus scale-up
+
+Scale-up should proceed only after the one-chapter pilot is green.
+
+Recommended sequence:
+
+1. Run Book I Chapter III with fixture responses.
+2. Run Book I Chapter III with a live provider in a disposable copy.
+3. Review generated entities, relations, evaluations, and metrics.
+4. Add a small Book I batch with explicit cost and resume notes.
+5. Only then run the full corpus.
+
+The full corpus should not be committed wholesale until it has a current scoped
+use, deterministic acceptance coverage, and a migration report explaining what
+was generated, reviewed, deferred, or retired.

docs/workflow-generation-pipeline.md

@@ -0,0 +1,84 @@
+# Workflow Generation Pipeline
+
+`infospace-bench` replaces the old `markitect infospace process` concept with
+explicit workflow declarations in `infospace.yaml`.
+
+The boundary is intentionally narrow:
+
+- `infospace-bench` owns concrete workflow declarations, source artifact
+  selection, generated artifact provenance, run records, and CLI behavior.
+- `markitect-tool` owns deterministic Markdown rendering and parsing. The
+  workflow layer calls it only through `infospace_bench.markdown_adapter`.
+- Assisted generation is represented as provider-neutral requests. Actual
+  model/provider calls must arrive through an explicit adapter, not through the
+  workflow definition itself.
+
+## Declaration Shape
+
+```yaml
+workflows:
+  - id: source-summary
+    description: Render deterministic summaries for source artifacts.
+    inputs:
+      source:
+        kind: source
+    static_macros:
+      discipline: Viable System Model
+    stages:
+      - id: render-summary
+        kind: template
+        input: source
+        template: workflows/templates/summary.md
+        output:
+          path: artifacts/generated/{{ input.slug }}-summary.md
+          artifact_id: generated/{{ input.slug }}-summary.md
+          kind: generated
+          title: "{{ input.title }} Summary"
+    expected_evaluations:
+      - metrics
+```
+
+Workflow template files use the `markitect-tool` `{{ variable.path }}` template
+syntax. Current deterministic stage data includes:
+
+- `input`: selected artifact metadata and content
+- `macros`: workflow-level plus stage-level static macros
+- `workflow`: the workflow declaration
+- `stage`: the current stage declaration
+- `stages`: previous deterministic stage outputs, keyed by stage ID
+
+## Deterministic Runs
+
+`kind: template` stages render Markdown and write generated artifacts. Each
+generated artifact is registered in `artifacts/index.yaml` with provenance:
+
+- `workflow_id`
+- `stage_id`
+- `input_artifact_id`
+
+Runs write trace records under:
+
+```text
+output/workflows/runs/<run-id>.yaml
+```
+
+These records are file-backed evidence for later `kontextual-engine` integration
+without making this repo a workflow engine.
+
+## Assisted Boundary
+
+`kind: assisted` stages render a provider-neutral prompt request during planning.
+Running an assisted stage requires an explicit `AssistedGenerationAdapter`.
+Without one, the runner raises `assisted_stage_requires_adapter`, which keeps
+provider behavior optional, auditable, and outside the application workflow
+declaration.
+
+## CLI
+
+```bash
+python3 -m infospace_bench workflow inspect infospaces/bootstrap-pilot
+python3 -m infospace_bench workflow plan infospaces/bootstrap-pilot source-summary
+python3 -m infospace_bench workflow run infospaces/bootstrap-pilot source-summary
+```
+
+All commands emit JSON for scripted migration and parity checks.

examples/routing/trading-literature.yaml

@@ -0,0 +1,81 @@
+# Example routing config for a trading-literature Lefevre-style run.
+#
+# Captures the IB-WP-0018 task-type taxonomy from docs/routing-task-types.md:
+#   summarize-source  → cheap model (volume-heavy, recoverable downstream)
+#   extract-entities  → smart model (durable output; be strict)
+#   extract-relations → smart model (depends on entities)
+#   evaluate-entity   → judge model (different family from extraction)
+#   synthesize-report → smart model (volume-of-one, quality matters, cheap)
+#
+# Quality floors are the recommended starting points from
+# docs/routing-task-types.md. With a ledger configured, AdaptiveRoutingPolicy
+# will pick the cheapest *qualifying* adapter per task type as observations
+# accumulate; until then it falls back to the static prefer/fallback order.
+#
+# Refresh the model rates in src/infospace_bench/model_rates.yaml before any
+# full-book run — list prices drift, and the rough USD estimate in the budget
+# log depends on them.
+
+schema_version: 1
+
+# Workspace-relative ledger so QualityLedger observations from this workspace
+# stay with this workspace. Drop this line to run pure static routing.
+ledger_path: output/routing/quality.jsonl
+
+# Floors apply when --quality-floor is not passed at the call site. The CLI
+# flag wins, then the per-task quality_floor below, then this default.
+default_quality_floor: 0.80
+
+stage_to_task_type:
+  summarize-source: cheap
+  extract-entities: smart
+  extract-relations: smart
+  evaluate-entity: judge
+  synthesize-report: smart
+
+task_types:
+
+  cheap:
+    quality_floor: 0.70
+    candidates:
+      - id: openrouter:gpt-4o-mini
+        provider: openrouter
+        model: openai/gpt-4o-mini
+        api_key_env: OPENROUTER_API_KEY
+        max_cost_per_1k: 0.001
+      - id: openrouter:claude-3.5-haiku
+        provider: openrouter
+        model: anthropic/claude-3.5-haiku
+        api_key_env: OPENROUTER_API_KEY
+        max_cost_per_1k: 0.003
+
+  smart:
+    quality_floor: 0.85
+    candidates:
+      - id: openrouter:claude-3.5-haiku
+        provider: openrouter
+        model: anthropic/claude-3.5-haiku
+        api_key_env: OPENROUTER_API_KEY
+      - id: openrouter:claude-3.5-sonnet
+        provider: openrouter
+        model: anthropic/claude-3.5-sonnet
+        api_key_env: OPENROUTER_API_KEY
+
+  judge:
+    quality_floor: 0.80
+    candidates:
+      # Evaluation goes through a different family than extraction to limit
+      # self-preference bias.
+      - id: openrouter:gpt-4o-mini
+        provider: openrouter
+        model: openai/gpt-4o-mini
+        api_key_env: OPENROUTER_API_KEY
+
+  # Baseline is wired here so a follow-up T05 ShadowingAdapter step can
+  # reference `claude-code` as the grading oracle without editing the
+  # task_types stanza.
+  baseline:
+    candidates:
+      - id: claude-code
+        provider: claude_code
+        model: claude-opus-4-7

infospaces/agentic-memory-profile-pilot/artifacts/index.yaml

@@ -0,0 +1,88 @@
+artifacts:
+  - id: source/memory-pilot-brief.md
+    path: artifacts/sources/memory-pilot-brief.md
+    kind: source
+    title: Agentic Memory Profile Pilot Brief
+    provenance:
+      workplan: IB-WP-0017
+      selected_corpus: infospaces/wealth-vsm-legacy-slice
+      created_at: "2026-05-15T00:00:00Z"
+    relationships: []
+  - id: generated/memory-profile.yaml
+    path: output/memory/memory-profile.yaml
+    kind: generated
+    title: Agentic Memory Pilot Profile
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: validate-memory-fixtures
+      contract: markitect.memory.profile.v1
+    relationships:
+      - type: generated_from
+        target: source/memory-pilot-brief.md
+  - id: generated/memory-graph.yaml
+    path: output/memory/memory-graph.yaml
+    kind: generated
+    title: Agentic Memory Pilot Graph
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: validate-memory-fixtures
+      contract: markitect.memory.graph.v1
+    relationships:
+      - type: generated_from
+        target: source/memory-pilot-brief.md
+      - type: governed_by
+        target: generated/memory-profile.yaml
+  - id: generated/restart-context-selection.yaml
+    path: output/memory/restart-context-selection.yaml
+    kind: generated
+    title: Restart Context Selection
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: evaluate-restart-package
+      contract: markitect.memory.selection.v1
+    relationships:
+      - type: selects_from
+        target: generated/memory-graph.yaml
+      - type: governed_by
+        target: generated/memory-profile.yaml
+  - id: generated/restart-context-package.expected.yaml
+    path: output/memory/restart-context-package.expected.yaml
+    kind: generated
+    title: Expected Restart Context Package
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: evaluate-restart-package
+      expectation: compiled-by-markitect-memory-graph-pack
+    relationships:
+      - type: generated_from
+        target: generated/restart-context-selection.yaml
+  - id: generated/context-package-evaluation.yaml
+    path: output/memory/context-package-evaluation.yaml
+    kind: generated
+    title: Context Package Usefulness Evaluation
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: evaluate-restart-package
+    relationships:
+      - type: evaluates
+        target: generated/restart-context-package.expected.yaml
+  - id: generated/generation-plan-decision-trace.yaml
+    path: output/memory/traces/generation-plan-decision.yaml
+    kind: generated
+    title: Generation Plan Decision Trace
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: applied-workflow-traces
+    relationships:
+      - type: generated_from
+        target: source/memory-pilot-brief.md
+  - id: generated/entity-review-restart-trace.yaml
+    path: output/memory/traces/entity-review-restart.yaml
+    kind: generated
+    title: Entity Review Restart Trace
+    provenance:
+      workflow_id: memory-profile-pilot
+      stage_id: applied-workflow-traces
+    relationships:
+      - type: generated_from
+        target: source/memory-pilot-brief.md

infospaces/agentic-memory-profile-pilot/artifacts/sources/memory-pilot-brief.md

@@ -0,0 +1,33 @@
+# Agentic Memory Profile Pilot Brief
+
+## Pilot Corpus
+
+The pilot uses `infospaces/wealth-vsm-legacy-slice` as the concrete corpus. It
+is small enough to inspect by hand, already contains a source, entities,
+relations, evaluations, metrics, history, and an engine sync plan, and it
+exercises the same restart and review questions that a memory package should
+help with.
+
+The fixture also references the generic source generator because that workflow
+is the likely producer of future memory events. The pilot does not create a
+durable memory store; it records file-backed evidence and Markitect-compatible
+contracts only.
+
+## Memory Questions
+
+| Question | Fixture Coverage | Acceptance Signal |
+| --- | --- | --- |
+| Which reasoning decisions should become durable memory? | `decision.file-backed-pilot` and `constraint.no-durable-runtime` | A restart package can recover the boundary without reading every workplan. |
+| Which workflow events are useful later? | `turn.review-handoff`, `tool_call.generator-status`, and `observation.restart-risk` | Trace events explain why the package contains both decisions and artifact neighborhoods. |
+| Which knowledge graph neighborhoods improve review? | `entity.division-of-labour`, `entity.market-extent`, and `artifact.wealth-source` | The package ties the decision path to the concrete Wealth/VSM artifacts. |
+| Which context package shape helps agents? | `restart-context-selection.yaml` | The package stays within eight items and 1200 tokens. |
+| Which profile parameters are misplaced or missing? | `context-package-evaluation.yaml` | Feedback separates Markitect contracts, engine runtime needs, and infospace evaluation knobs. |
+
+## Acceptance Targets
+
+- Memory profile and graph fixtures validate with `markitect-tool`.
+- Context package compilation is deterministic aside from runtime timestamps.
+- Every selected package item has a source span or a Markitect synthetic memory
+  span.
+- No provider credentials, secrets, or durable user memory are stored.
+- Runtime persistence remains delegated to `kontextual-engine`.

infospaces/agentic-memory-profile-pilot/infospace.yaml

@@ -0,0 +1,38 @@
+slug: agentic-memory-profile-pilot
+name: Agentic Memory Profile Pilot
+topic:
+  name: Agentic Memory Profile Pilot
+  domain: Agentic Memory Evaluation
+  sources: artifacts/sources
+disciplines:
+  - name: Markitect Memory Graph Contract
+    path: output/memory/memory-profile.yaml
+schemas: {}
+workflows:
+  - id: memory-profile-pilot
+    description: File-backed pilot for Markitect-compatible agentic memory profile fixtures.
+    inputs:
+      source:
+        kind: source
+    stages:
+      - id: select-pilot-corpus
+        kind: manual
+        input: source
+        template: reports/memory-profile-pilot.md
+      - id: validate-memory-fixtures
+        kind: manual
+        input: source
+        template: output/memory/memory-graph.yaml
+      - id: evaluate-restart-package
+        kind: manual
+        input: source
+        template: output/memory/context-package-evaluation.yaml
+viability:
+  provenance_coverage_ratio:
+    min: 1.0
+  restart_quality_score:
+    min: 4.0
+  selected_node_count:
+    min: 6
+  context_package_budget_max_tokens:
+    max: 1200

infospaces/agentic-memory-profile-pilot/output/archives/index.yaml

@@ -0,0 +1,17 @@
+archives:
+- package_id: d3c1ff32-2eed-4b9c-9868-dbff0af723b4
+  manifest_digest: blake3:5ff7fc5d7974d5f4fd4b66a181cda729f61d399f7b3c8e7dea2aa9af8fd2025b
+  retention_class: release-evidence
+  created_at: '2026-05-17T10:03:17'
+  included_paths:
+  - infospace.yaml
+  - artifacts
+  - workflows
+  - output
+  - reports
+  - exports
+  file_count: 13
+  note: 'First archive: memory profile pilot v1 (post IB-WP-0014 close-out)'
+  producer: infospace-bench
+  subject: agentic-memory-profile-pilot
+  store_root: infospaces/agentic-memory-profile-pilot/output/archives/.store

infospaces/agentic-memory-profile-pilot/output/memory/context-package-evaluation.yaml

@@ -0,0 +1,51 @@
+schema_version: infospace-bench.memory-context-evaluation.v1
+evaluated_at: "2026-05-15T00:20:00Z"
+workplan: IB-WP-0017
+profile_id: infospace-agentic-memory-pilot
+graph_id: infospace-agentic-memory-graph
+selection: restart-context-selection.yaml
+questions:
+  - id: restart-quality
+    prompt: Can a later agent resume Wealth/VSM review with the selected package?
+    score: 4.2
+    max_score: 5.0
+    result: pass
+  - id: provenance-review
+    prompt: Can a reviewer see why each memory item exists?
+    score: 5.0
+    max_score: 5.0
+    result: pass
+  - id: budget-realism
+    prompt: Does the selection fit a compact restart budget?
+    score: 4.0
+    max_score: 5.0
+    result: pass
+  - id: noise-control
+    prompt: Does the package omit low-value trace detail?
+    score: 3.8
+    max_score: 5.0
+    result: watch
+metrics:
+  restart_quality_score: 4.2
+  provenance_coverage_ratio: 1.0
+  selected_node_count: 7
+  expected_item_count: 8
+  context_package_budget_max_tokens: 1200
+  live_llm_required: false
+findings:
+  - id: finding.restart-risk
+    summary: Decision-only memory is not enough; restart packages need the active source/entity neighborhood.
+  - id: finding.neighborhood-improves-review
+    summary: The Division of Labour source and entity references make the boundary decision actionable for review.
+  - id: finding.profile-gap
+    summary: Profile retention intent is useful, but acceptance thresholds remain application-level metrics in infospace-bench.
+recommended_contract_changes:
+  markitect-tool:
+    - Add an option for timestamp-stable context package fixture output to simplify cross-repo golden files.
+    - Document when selected events should become package items versus metadata.
+  kontextual-engine:
+    - Import Markitect graph/profile envelopes and persist runtime audit events separately from contract events.
+    - Keep durable write plans review-gated and export Markitect-compatible package input envelopes.
+  infospace-bench:
+    - Keep memory quality metrics and pilot corpora here.
+    - Do not store user memory, credentials, or runtime graph state in an infospace.

infospaces/agentic-memory-profile-pilot/output/memory/memory-graph.yaml

@@ -0,0 +1,273 @@
+schema_version: markitect.memory.graph.v1
+id: infospace-agentic-memory-graph
+title: Infospace Agentic Memory Pilot Graph
+intent: Preserve the reviewed memory decisions, workflow events, and Wealth/VSM artifact neighborhood used to evaluate restart context packages.
+namespace:
+  project: infospace-bench
+  task: IB-WP-0017
+nodes:
+  - id: question.memory-decisions
+    kind: question
+    text: Which infospace generation and review decisions are useful enough to reactivate for later agent work?
+    source_spans:
+      - path: workplans/IB-WP-0017-agentic-memory-profile-pilot.md
+        unit_kind: section
+        selector: tasks[id=IB-WP-0017-T01]
+        engine: selector
+    metadata:
+      title: Memory question
+      summary: The pilot starts from concrete restart questions, not a runtime feature request.
+  - id: decision.file-backed-pilot
+    kind: decision
+    text: Keep the pilot file-backed in infospace-bench and use Markitect contracts for validation and package compilation.
+    source_spans:
+      - path: docs/agentic-memory-profile-pilot.md
+        unit_kind: section
+        selector: heading[Decision]
+        engine: selector
+    metadata:
+      title: File-backed pilot boundary
+      summary: Infospace-bench owns evidence and evaluation while Markitect owns contract compilation.
+  - id: constraint.no-durable-runtime
+    kind: constraint
+    text: Do not implement graph or event persistence in infospace-bench; durable runtime state belongs behind kontextual-engine.
+    source_spans:
+      - path: workplans/IB-WP-0017-agentic-memory-profile-pilot.md
+        unit_kind: section
+        selector: heading[Non-Goals]
+        engine: selector
+    metadata:
+      title: No durable memory runtime
+  - id: evidence.workplan-non-goal
+    kind: evidence
+    text: Workplan 17 explicitly forbids graph/event persistence, schema redefinition, live LLM requirements, and secrets in the infospace.
+    source_spans:
+      - path: workplans/IB-WP-0017-agentic-memory-profile-pilot.md
+        unit_kind: section
+        selector: heading[Non-Goals]
+        engine: selector
+    metadata:
+      title: Workplan non-goal evidence
+  - id: plan.restart-context-package
+    kind: plan
+    text: Evaluate a restart package that activates the boundary decision, one workflow trace, and the Wealth/VSM artifact neighborhood under a tight budget.
+    source_spans:
+      - path: infospaces/agentic-memory-profile-pilot/output/memory/restart-context-selection.yaml
+        unit_kind: mapping
+        selector: node_ids
+        engine: yaml
+    metadata:
+      title: Restart package plan
+      summary: The package should improve restart quality without becoming noisy.
+  - id: turn.review-handoff
+    kind: turn
+    text: Reviewer asks whether a later agent can resume entity and relation review without rereading every generated report.
+    source_spans:
+      - path: infospaces/agentic-memory-profile-pilot/output/memory/traces/entity-review-restart.yaml
+        unit_kind: trace
+        selector: events[0]
+        engine: yaml
+    metadata:
+      title: Review handoff turn
+  - id: tool_call.generator-status
+    kind: tool_call
+    text: The workflow status check reports one source, two entities, one relation, one evaluation snapshot, and no stale source artifacts.
+    source_spans:
+      - path: infospaces/wealth-vsm-legacy-slice/output/metrics/metrics.yaml
+        unit_kind: mapping
+        selector: metrics
+        engine: yaml
+    metadata:
+      title: Generator status check
+  - id: observation.restart-risk
+    kind: observation
+    text: Restart context is incomplete if it contains only decisions and omits the source/entity neighborhood under review.
+    source_spans:
+      - path: infospaces/agentic-memory-profile-pilot/output/memory/context-package-evaluation.yaml
+        unit_kind: mapping
+        selector: findings[0]
+        engine: yaml
+    metadata:
+      title: Restart risk observation
+  - id: artifact.wealth-source
+    kind: artifact
+    text: The Wealth/VSM legacy slice source is Book I Chapter III, used as the bounded corpus for the memory profile pilot.
+    source_spans:
+      - path: infospaces/wealth-vsm-legacy-slice/artifacts/sources/book-1-chapter-03.md
+        unit_kind: document
+        selector: path
+        engine: filesystem
+    metadata:
+      title: Book I Chapter III source
+      artifact_id: source/book-1-chapter-03.md
+  - id: entity.division-of-labour
+    kind: entity
+    text: Division of Labour is the generated entity whose review quality depends on preserving the source relation to market extent.
+    source_spans:
+      - path: infospaces/wealth-vsm-legacy-slice/artifacts/entities/division-of-labour.md
+        unit_kind: document
+        selector: path
+        engine: filesystem
+    metadata:
+      title: Division of Labour
+      artifact_id: entity/division-of-labour.md
+  - id: entity.market-extent
+    kind: entity
+    text: Market Extent is the paired entity in the Wealth/VSM relation neighborhood.
+    source_spans:
+      - path: infospaces/wealth-vsm-legacy-slice/artifacts/entities/market-extent.md
+        unit_kind: document
+        selector: path
+        engine: filesystem
+    metadata:
+      title: Market Extent
+      artifact_id: entity/market-extent.md
+  - id: finding.neighborhood-improves-review
+    kind: finding
+    text: The useful restart package combines the boundary decision with the concrete source and entity neighborhood being reviewed.
+    source_spans:
+      - path: infospaces/agentic-memory-profile-pilot/output/memory/context-package-evaluation.yaml
+        unit_kind: mapping
+        selector: findings[1]
+        engine: yaml
+    metadata:
+      title: Neighborhood improves review
+  - id: profile.agentic-memory-pilot
+    kind: profile
+    text: The profile enables reasoning, conversation, knowledge, and package memory kinds with review-gated durable writes.
+    source_spans:
+      - path: infospaces/agentic-memory-profile-pilot/output/memory/memory-profile.yaml
+        unit_kind: mapping
+        selector: $
+        engine: yaml
+    metadata:
+      title: Agentic memory pilot profile
+  - id: context_package.restart-package
+    kind: context_package
+    text: The restart package selection is capped at eight items and must preserve selected nodes, implied edges, events, policy metadata, and provenance.
+    source_spans:
+      - path: infospaces/agentic-memory-profile-pilot/output/memory/restart-context-selection.yaml
+        unit_kind: mapping
+        selector: $
+        engine: yaml
+    metadata:
+      title: Restart context package
+      package_id: memory:package:agentic-memory-profile-restart
+  - id: policy.review-gate
+    kind: policy
+    text: Any future durable memory write must be planned, reviewed, and applied through an explicit runtime gate.
+    source_spans:
+      - path: docs/agentic-memory-profile-pilot.md
+        unit_kind: section
+        selector: heading[Engine Integration Plan]
+        engine: selector
+    metadata:
+      title: Durable write review gate
+edges:
+  - id: edge.evidence-supports-boundary
+    kind: supports
+    source: evidence.workplan-non-goal
+    target: decision.file-backed-pilot
+  - id: edge.constraint-supports-boundary
+    kind: supports
+    source: constraint.no-durable-runtime
+    target: decision.file-backed-pilot
+  - id: edge.question-led-to-boundary
+    kind: led_to
+    source: question.memory-decisions
+    target: decision.file-backed-pilot
+  - id: edge.boundary-led-to-package-plan
+    kind: led_to
+    source: decision.file-backed-pilot
+    target: plan.restart-context-package
+  - id: edge.turn-led-to-observation
+    kind: led_to
+    source: turn.review-handoff
+    target: observation.restart-risk
+  - id: edge.tool-call-led-to-observation
+    kind: led_to
+    source: tool_call.generator-status
+    target: observation.restart-risk
+  - id: edge.observation-supports-finding
+    kind: supports
+    source: observation.restart-risk
+    target: finding.neighborhood-improves-review
+  - id: edge.division-derived-from-source
+    kind: derived_from
+    source: entity.division-of-labour
+    target: artifact.wealth-source
+  - id: edge.market-derived-from-source
+    kind: derived_from
+    source: entity.market-extent
+    target: artifact.wealth-source
+  - id: edge.finding-references-division
+    kind: references
+    source: finding.neighborhood-improves-review
+    target: entity.division-of-labour
+  - id: edge.finding-references-market
+    kind: references
+    source: finding.neighborhood-improves-review
+    target: entity.market-extent
+  - id: edge.profile-governs-package
+    kind: governs
+    source: profile.agentic-memory-pilot
+    target: context_package.restart-package
+  - id: edge.policy-governs-package
+    kind: governs
+    source: policy.review-gate
+    target: context_package.restart-package
+  - id: edge.package-activates-plan
+    kind: activates
+    source: context_package.restart-package
+    target: plan.restart-context-package
+events:
+  - id: event.memory-questions-recorded
+    kind: recorded
+    timestamp: "2026-05-15T00:00:00Z"
+    actor: infospace-bench
+    task: IB-WP-0017-T01
+    node_updates:
+      - node_id: question.memory-decisions
+        operation: create
+      - node_id: decision.file-backed-pilot
+        operation: create
+  - id: event.workflow-restart-trace
+    kind: recorded
+    timestamp: "2026-05-15T00:05:00Z"
+    actor: infospace-bench
+    thread: agentic-memory-profile-pilot
+    task: IB-WP-0017-T05
+    node_updates:
+      - node_id: turn.review-handoff
+        operation: create
+      - node_id: tool_call.generator-status
+        operation: create
+      - node_id: observation.restart-risk
+        operation: create
+  - id: event.restart-package-activated
+    kind: activated
+    timestamp: "2026-05-15T00:10:00Z"
+    actor: infospace-bench
+    task: IB-WP-0017-T03
+    package_refs:
+      - memory:package:agentic-memory-profile-restart
+    activation_refs:
+      - activation:agentic-memory-profile-restart-review
+    metadata:
+      selected_node_count: 7
+      expected_item_count: 8
+  - id: event.review-gate-policy
+    kind: policy_decision
+    timestamp: "2026-05-15T00:15:00Z"
+    actor: infospace-bench
+    task: IB-WP-0017-T04
+    node_updates:
+      - node_id: policy.review-gate
+        operation: create
+    policy:
+      durable_writes: review_required
+      decision: allow_fixture_only
+metadata:
+  pilot_corpus: infospaces/wealth-vsm-legacy-slice
+  workplan: IB-WP-0017
+  lower_layer_contract: markitect.memory.graph.v1

infospaces/agentic-memory-profile-pilot/output/memory/memory-profile.yaml

@@ -0,0 +1,70 @@
+schema_version: markitect.memory.profile.v1
+id: infospace-agentic-memory-pilot
+title: Infospace Agentic Memory Pilot Profile
+intent: Compile selected reasoning decisions, workflow events, and artifact neighborhoods into restart context packages for infospace evaluation.
+memory_kinds:
+  - reasoning
+  - conversation
+  - knowledge
+  - package
+stores:
+  reasoning: markitect-memory-graph-fixture
+  conversation: infospace-workflow-trace-fixtures
+  knowledge: infospace-artifact-neighborhood
+  package: markitect-context-package
+limits:
+  reasoning:
+    max_nodes: 40
+  conversation:
+    max_nodes: 20
+  knowledge:
+    max_nodes: 80
+  package:
+    max_items: 8
+latency:
+  reasoning:
+    target_ms: 50
+  conversation:
+    target_ms: 50
+  knowledge:
+    target_ms: 120
+retention:
+  reasoning:
+    strategy: keep-reviewed-decisions
+    review_gate: required
+  conversation:
+    strategy: keep-accepted-handoff-events
+    window_events: 12
+  knowledge:
+    strategy: supersede-with-artifact-version
+  package:
+    strategy: regenerate-from-selection
+refresh:
+  cadence: manual
+  trigger: source-artifact-or-profile-digest-change
+compaction:
+  strategy: summarize-trace-after-review
+  owner: markitect-tool-contract-output
+activation:
+  max_items: 8
+  max_tokens: 1200
+  reserve_tokens: 150
+policy:
+  required_labels:
+    - project-local
+  durable_writes: review-gated
+  secrets_allowed: false
+observability:
+  emit_events: true
+  metrics:
+    - restart_quality_score
+    - provenance_coverage_ratio
+    - context_package_budget_max_tokens
+failure:
+  missing_runtime_store: degrade-to-file-backed-fixture
+  stale_profile: require-regeneration
+metadata:
+  workplan: IB-WP-0017
+  contract_owner: markitect-tool
+  runtime_owner: kontextual-engine
+  evaluation_owner: infospace-bench

infospaces/agentic-memory-profile-pilot/output/memory/restart-context-package.expected.yaml

@@ -0,0 +1,44 @@
+schema_version: infospace-bench.memory-context-expectation.v1
+package_id: memory:package:agentic-memory-profile-restart
+title: Agentic Memory Profile Restart Package
+intent: Activate the minimum useful context for resuming Wealth/VSM entity and relation review under the memory pilot boundary.
+profile_id: infospace-agentic-memory-pilot
+graph_id: infospace-agentic-memory-graph
+expected_item_count: 8
+expected_selected_nodes:
+  - decision.file-backed-pilot
+  - constraint.no-durable-runtime
+  - plan.restart-context-package
+  - artifact.wealth-source
+  - entity.division-of-labour
+  - finding.neighborhood-improves-review
+  - policy.review-gate
+expected_selected_edges:
+  - edge.constraint-supports-boundary
+  - edge.boundary-led-to-package-plan
+  - edge.division-derived-from-source
+  - edge.finding-references-division
+expected_selected_events:
+  - event.restart-package-activated
+budget:
+  max_items: 8
+  max_tokens: 1200
+  reserve_tokens: 150
+  strategy: first-fit
+acceptance:
+  requires_source_spans: true
+  max_token_estimate: 1200
+  required_node_kinds:
+    - decision
+    - constraint
+    - plan
+    - artifact
+    - entity
+    - finding
+    - policy
+  deterministic_fields:
+    - package_id
+    - title
+    - selected_nodes
+    - selected_edges
+    - selected_events

infospaces/agentic-memory-profile-pilot/output/memory/restart-context-selection.yaml

@@ -0,0 +1,27 @@
+schema_version: markitect.memory.selection.v1
+graph: memory-graph.yaml
+profile: memory-profile.yaml
+title: Agentic Memory Profile Restart Package
+intent: Activate the minimum useful context for resuming Wealth/VSM entity and relation review under the memory pilot boundary.
+package_id: memory:package:agentic-memory-profile-restart
+namespace:
+  project: infospace-bench
+  task: IB-WP-0017
+node_ids:
+  - decision.file-backed-pilot
+  - constraint.no-durable-runtime
+  - plan.restart-context-package
+  - artifact.wealth-source
+  - entity.division-of-labour
+  - finding.neighborhood-improves-review
+  - policy.review-gate
+event_ids:
+  - event.restart-package-activated
+budget:
+  max_items: 8
+  max_tokens: 1200
+  reserve_tokens: 150
+  strategy: first-fit
+metadata:
+  purpose: restart-quality-evaluation
+  expected_task: resume Wealth/VSM review without rereading all workplans

infospaces/agentic-memory-profile-pilot/output/memory/traces/entity-review-restart.yaml

@@ -0,0 +1,31 @@
+schema_version: infospace-bench.memory-trace.v1
+id: trace.entity-review-restart
+title: Entity Review Restart Trace
+workplan: IB-WP-0017
+source_workflow: wealth-vsm-legacy-slice-review
+events:
+  - id: trace-event.review-handoff
+    kind: conversation_turn
+    timestamp: "2026-05-15T00:05:00Z"
+    actor: reviewer
+    summary: A later agent needs to resume review of the Division of Labour relation without rereading every report.
+    memory_nodes:
+      - turn.review-handoff
+  - id: trace-event.status-check
+    kind: tool_call
+    timestamp: "2026-05-15T00:06:00Z"
+    actor: infospace-bench
+    summary: The slice is compact and coherent enough for package evaluation.
+    memory_nodes:
+      - tool_call.generator-status
+  - id: trace-event.restart-risk
+    kind: observation
+    timestamp: "2026-05-15T00:07:00Z"
+    actor: infospace-bench
+    summary: Decision-only context would miss the actual source/entity neighborhood under review.
+    memory_nodes:
+      - observation.restart-risk
+      - finding.neighborhood-improves-review
+review_notes:
+  - The selected package should include source and entity nodes, not only planning decisions.
+  - Relation review improves when the active artifact neighborhood is visible.

infospaces/agentic-memory-profile-pilot/output/memory/traces/generation-plan-decision.yaml

@@ -0,0 +1,25 @@
+schema_version: infospace-bench.memory-trace.v1
+id: trace.generation-plan-decision
+title: Generation Plan Decision Trace
+workplan: IB-WP-0017
+source_workflow: generic-source-generator
+events:
+  - id: trace-event.select-corpus
+    kind: planning_decision
+    timestamp: "2026-05-15T00:00:00Z"
+    actor: infospace-bench
+    summary: Selected the Wealth/VSM legacy slice because it has source, entities, relation, evaluation, metrics, and engine sync evidence.
+    memory_nodes:
+      - question.memory-decisions
+      - decision.file-backed-pilot
+  - id: trace-event.boundary-check
+    kind: review_gate
+    timestamp: "2026-05-15T00:02:00Z"
+    actor: infospace-bench
+    summary: Confirmed the pilot should create fixtures and metrics, not reusable graph/event persistence.
+    memory_nodes:
+      - constraint.no-durable-runtime
+      - policy.review-gate
+review_notes:
+  - Keep this as a trace fixture until a runtime store exists behind kontextual-engine.
+  - Convert only reviewed decisions and useful restart evidence into memory graph nodes.

infospaces/agentic-memory-profile-pilot/output/metrics/memory-profile-history.yaml

@@ -0,0 +1,17 @@
+history:
+  - snapshot_id: memory-profile-pilot-20260515
+    recorded_at: "2026-05-15T00:25:00Z"
+    workplan: IB-WP-0017
+    metrics:
+      memory_profile_contract_valid: true
+      memory_graph_contract_valid: true
+      selection_contract_valid: true
+      restart_quality_score: 4.2
+      provenance_coverage_ratio: 1.0
+      selected_node_count: 7
+      expected_item_count: 8
+      selected_edge_count: 4
+      context_package_budget_max_tokens: 1200
+    notes:
+      - First deterministic fixture snapshot for the agentic memory profile pilot.
+      - Context package token estimate is checked in tests because Markitect computes it during compilation.

infospaces/agentic-memory-profile-pilot/output/metrics/metrics.yaml

@@ -0,0 +1,11 @@
+memory_profile_contract_valid: true
+memory_graph_contract_valid: true
+selection_contract_valid: true
+restart_quality_score: 4.2
+provenance_coverage_ratio: 1.0
+selected_node_count: 7
+expected_item_count: 8
+selected_edge_count: 4
+context_package_budget_max_tokens: 1200
+live_llm_required: false
+durable_runtime_required: false

infospaces/agentic-memory-profile-pilot/reports/memory-profile-pilot.md

@@ -0,0 +1,34 @@
+# Agentic Memory Profile Pilot Report
+
+## Decision
+
+The pilot validates agentic memory profiles through file-backed evidence in
+`infospace-bench`. The durable runtime remains out of scope. Markitect owns the
+memory graph/profile/selection contracts and context package compiler, while
+`kontextual-engine` owns future runtime state, audit, permissions, retention,
+refresh, compaction, and durable write review gates.
+
+## Fixture Set
+
+- `output/memory/memory-profile.yaml`: Markitect-compatible memory profile.
+- `output/memory/memory-graph.yaml`: reviewed decision, trace, and artifact
+  neighborhood graph.
+- `output/memory/restart-context-selection.yaml`: graph selection for a restart
+  package.
+- `output/memory/restart-context-package.expected.yaml`: deterministic
+  expectations for compiled package shape.
+- `output/memory/context-package-evaluation.yaml`: package usefulness evidence
+  and contract feedback.
+- `output/memory/traces/*.yaml`: applied workflow traces showing where memory
+  records arise.
+
+## Result
+
+The selected restart package combines three kinds of useful context:
+
+- the boundary decision that keeps this repo as the evaluation layer
+- the review gate that prevents hidden durable memory writes
+- the Wealth/VSM source and entity neighborhood needed to resume artifact review
+
+This is enough to answer the Workplan 17 pilot questions without turning the
+infospace into a memory runtime.

infospaces/bootstrap-pilot/infospace.yaml

@@ -9,8 +9,31 @@ disciplines:
     path: artifacts/generated/lifecycle-baseline.md
 schemas: {}
 workflows:
-  - name: baseline-inspection
-    report: reports/baseline-inspection.md
+  - id: baseline-inspection
+    description: Existing committed inspection report for the bootstrap pilot.
+    inputs: {}
+    stages: []
+    expected_evaluations:
+      - metrics
+  - id: bootstrap-readiness
+    description: Deterministically render replacement-readiness summaries for source artifacts.
+    inputs:
+      source:
+        kind: source
+    static_macros:
+      successor_role: application-layer successor for in-scope infospace work
+    stages:
+      - id: render-readiness-summary
+        kind: template
+        input: source
+        template: workflows/templates/bootstrap-readiness.md
+        output:
+          path: artifacts/generated/{{ input.slug }}-readiness.md
+          artifact_id: generated/{{ input.slug }}-readiness.md
+          kind: generated
+          title: "{{ input.title }} Readiness Summary"
+    expected_evaluations:
+      - metrics
 viability:
   redundancy_ratio:
     max: 0

infospaces/bootstrap-pilot/output/archives/index.yaml

@@ -0,0 +1,17 @@
+archives:
+- package_id: fb31721e-710c-4b20-8cdd-75c779e879e1
+  manifest_digest: blake3:2e2a32a54d5b4cb30d28a61adc9737ddb1230a040455736526af236baaa66bff
+  retention_class: release-evidence
+  created_at: '2026-05-17T10:14:25'
+  included_paths:
+  - infospace.yaml
+  - artifacts
+  - workflows
+  - output
+  - reports
+  - exports
+  file_count: 9
+  note: "Bootstrap pilot \u2014 initial repo scaffold reference"
+  producer: infospace-bench
+  subject: bootstrap-pilot
+  store_root: infospaces/bootstrap-pilot/output/archives/.store

infospaces/bootstrap-pilot/workflows/templates/bootstrap-readiness.md

@@ -0,0 +1,9 @@
+# {{ input.title }} Readiness Summary
+
+Role: {{ macros.successor_role }}
+
+Source artifact: {{ input.artifact_id }}
+
+## Source
+
+{{ input.content }}

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-bryan-panic-of-96.md

@@ -0,0 +1,5 @@
+# Entity Title: Bryan Panic of ’96
+## Definition
+The Bryan Panic of 1896 was a financial crisis characterized by significant volatility and manipulation in the markets, leading to widespread impact on traders, including those in bucket shops.
+## Category
+event

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-bucket-shop-drive.md

@@ -0,0 +1,5 @@
+# Entity Title: Bucket-Shop Drive
+## Definition
+A bucket-shop drive refers to a situation where the prices of stocks are manipulated downwards in a coordinated effort to force clients who are long on those stocks to incur losses or be wiped out.
+## Category
+strategy

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-bucket-shop.md

@@ -0,0 +1,5 @@
+# Entity Title: Bucket Shop
+## Definition
+A bucket shop is a type of brokerage that allows speculative trading in stocks without actually buying shares. These shops often manipulate market prices to exploit their clients, leading to significant losses for traders.
+## Category
+market

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-bull-tips.md

@@ -0,0 +1,5 @@
+# Entity Title: Bull Tips
+## Definition
+Bull tips are recommendations or information suggesting that a stock's price will rise, encouraging traders to buy. These were used strategically to influence market movements in the discussed scenario.
+## Category
+evidence_bearing_claim

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-cosmopolitan.md

@@ -0,0 +1,5 @@
+# Entity Title: Cosmopolitan
+## Definition
+The Cosmopolitan is identified as a bucket shop that engaged in manipulative practices, specifically targeting short positions in Sugar by artificially inflating stock prices.
+## Category
+institution

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-dollar-manipulation.md

@@ -0,0 +1,11 @@
+# Entity Title: Dollar Manipulation  
+## Definition  
+The practice of manipulating stock prices to extract profits from the market, often at the expense of average investors.  
+## Category  
+error  
+## Context  
+It underscores the dangers of participating in manipulative market practices without adequate knowledge.  
+## Source Evidence  
+"Their brokers in New York ran up the price to 108. Of course it fell right back, but Henry and a lot of others were wiped out."  
+
+---

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-market-drive.md

@@ -0,0 +1,11 @@
+# Entity Title: Market Drive  
+## Definition  
+A tactic employed to artificially inflate or deflate stock prices in a way that leads to trader losses and profits for others.  
+## Category  
+strategy  
+## Context  
+Refers to the strategy used by operators to manipulate stock prices causing losses for long holders.  
+## Source Evidence  
+"whenever there was an unexplained sharp drop which was followed by instant recovery, the newspapers in those days used to call it a bucket-shop drive."  
+
+---

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-market-factor.md

@@ -0,0 +1,5 @@
+# Entity Title: Market Factor
+## Definition
+A market factor is an operator or trader who significantly influences trading conditions or stock prices within the market. In the text, a certain trader is identified as a market factor due to his previous successes in market manipulation.
+## Category
+trader

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-new-york-stock-exchange.md

@@ -0,0 +1,5 @@
+# Entity Title: New York Stock Exchange
+## Definition
+The New York Stock Exchange (NYSE) is a major stock exchange where trading of stocks occurs, serving as a venue for some of the trading activities mentioned in the context of market manipulation.
+## Category
+market

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-short-position.md

@@ -0,0 +1,5 @@
+# Entity Title: Short Position
+## Definition
+A short position refers to the practice of selling stocks that a trader does not own, with the intention of buying them back at a lower price to profit from the decline. It was a significant factor in the losses suffered by the traders in the context.
+## Category
+strategy

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-sugar-commodity.md

@@ -0,0 +1,5 @@
+# Entity Title: Sugar (Commodity)
+## Definition
+Sugar refers to a specific commodity that is traded on the market, in this case, associated with the incident involving Tom and Henry Williams, where their positions were affected by market manipulation.
+## Category
+instrument

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-sugar.md

@@ -0,0 +1,11 @@
+# Entity Title: Sugar  
+## Definition  
+A specific stock that traders engage with, which is central to the narratives involving trading strategies and market manipulation.  
+## Category  
+instrument  
+## Context  
+Sugar is referenced in the context of a market manipulation scheme executed by bucket shops.  
+## Source Evidence  
+"Henry Williams and I together were short six thousand shares of Sugar."  
+
+---

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-western-union-stock.md

@@ -0,0 +1,5 @@
+# Entity Title: Western Union (Stock)
+## Definition
+Western Union is a stock that was frequently manipulated by traders due to its relative ease of movement within the market, making it a favored target for speculative trading schemes.
+## Category
+instrument

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/entities/entity-title-western-union.md

@@ -0,0 +1,9 @@
+# Entity Title: Western Union  
+## Definition  
+A specific stock favored for trading due to its liquidity and ease of price manipulation.  
+## Category  
+instrument  
+## Context  
+Referencing a stock used strategically to execute manipulative trades benefiting the instigator.  
+## Source Evidence  
+"One of his favorite stocks was Western Union, because it was so easy to move a semiactive stock like that a few points up or down."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-001-entities.md

@@ -0,0 +1,29 @@
+# Entity Title: Quotation-Board Boy
+## Definition
+A role in a stock-brokerage office responsible for updating and displaying stock prices on a quotation board for customers.
+## Category
+trader
+
+# Entity Title: Tape
+## Definition
+A method of recording and displaying stock price fluctuations over time, used as a tool for traders to anticipate price movements based on historical behavior.
+## Category
+instrument
+
+# Entity Title: Stock Prices Behavior
+## Definition
+The patterns and tendencies that stock prices display during various market conditions, which can be observed and analyzed to anticipate future movements.
+## Category
+strategy
+
+# Entity Title: Observation Journal
+## Definition
+A personal record maintained by a trader, documenting stock price movements, anticipated fluctuations, and the accuracy of past observations.
+## Category
+strategy
+
+# Entity Title: Wall Street Speculation
+## Definition
+The practice of buying and selling stocks with the aim of profiting from changes in price, based on the belief that historical patterns will repeat.
+## Category
+strategy

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-001-summary.md

@@ -0,0 +1,24 @@
+# Summary of "I Part 1"
+
+## Narrator's Actions & Market Events
+- Narrator begins working as a quotation-board boy in a stock-brokerage at a young age, quickly engaged with mental arithmetic and the constant flux of stock prices.
+- He focuses on the changing numbers, developing an interest in price behavior without understanding why they change.
+
+## Strategies, Instruments, Venues, Institutions
+- Instruments: Stocks
+- Venue: Stock market, brokerage office
+- Strategy: The narrator observes historical price behaviors to anticipate future movements, creating a personal record of stock performance.
+
+## Explicit Lessons, Rules of Thumb, Warnings
+- The tape reflects the market's real-time state, offering crucial insights for trading decisions.
+- Early lesson: "There is nothing new in Wall Street;" past patterns guide future predictions.
+- Importance of observing and recording fluctuations to refine anticipation of price movements.
+
+## Evidence Phrases
+- "seven out of ten cases"
+- "I got a little book" for tracking observations
+- Monitoring fluctuations, e.g., "behaving as it always did before it broke eight or ten points"
+
+## Ambiguities or Anachronisms
+- Lack of detail on what specific stocks were being monitored.
+- No clear time references for certain behaviors, potentially leading to confusion about the immediacy of events.

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-002-entities.md

@@ -0,0 +1,45 @@
+# Entity Title: Burlington  
+## Definition  
+Burlington is a specific security mentioned in the context of trading, which the narrator's acquaintance believed would increase in value.  
+## Category  
+instrument  
+
+---
+
+# Entity Title: bucket shop  
+## Definition  
+A bucket shop is a trading venue where individuals bet on fluctuations in stock prices as indicated by the ticker tape, often with minimal capital.  
+## Category  
+market  
+
+---
+
+# Entity Title: trading on tips  
+## Definition  
+The practice of making trading decisions based on informal tips or advice from others, typically seen as a strategy employed by amateur traders.  
+## Category  
+strategy  
+
+---
+
+# Entity Title: speculative trading  
+## Definition  
+A method of trading where the focus is on making profit from price fluctuations rather than holding investments based on strong fundamentals or long-term growth prospects.  
+## Category  
+strategy  
+
+---
+
+# Entity Title: arithmetic trading  
+## Definition  
+A trading approach based on mathematical calculations and patterns observed in market behavior rather than on emotional or opinion-based decisions.  
+## Category  
+strategy  
+
+---
+
+# Entity Title: office-boy  
+## Definition  
+A term referring to a young individual employed in a brokerage office, in this context representing the narrator's initial role and perspective in the trading environment.  
+## Category  
+trader

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-002-summary.md

@@ -0,0 +1,26 @@
+# I Part 2 Summary
+
+## Narrator's Actions and Market Events
+- The narrator observes market fluctuations, particularly noting Hollow Tube's three-point drop amidst a market rally.
+- He records data in a memorandum book to analyze stock behavior patterns, focusing on reading the tape.
+- Encouraged by an older office boy, he engages in trading Burlington stocks at a bucket shop to test his analytical methods.
+
+## Named Strategies, Instruments, Venues, and Institutions
+- **Trading Instruments**: Shares of Burlington.
+- **Trading Venue**: Bucket shop.
+- **Strategy**: Testing analytical accuracy through speculative trading based on observed patterns and tape behavior.
+
+## Explicit Lessons, Rules of Thumb, or Warnings
+- The narrator emphasizes the importance of testing hypotheses against real-world outcomes ("if my dope didn’t work in practice, there was nothing in the theory").
+- Encourages understanding market behavior through practice rather than mere speculation on favorites.
+
+## Evidence Phrases
+- **Market Movements**: "Hollow Tube went down three points."
+- **Trade Outcome**: "I made a profit of $3.12."
+- **First Profit Milestone**: "I was fifteen when I had my first thousand."
+- **Leniency in Experience**: "I had never bought or sold anything in my life."
+
+## Ambiguities or Anachronisms
+- The term "bucket shop" may need clarification as the concept has evolved.
+- The ambiguity of "old jiggers with oodles of dough" raises questions about the socio-economic context of the trading environment.
+- The narrator’s age and level of experience in trading might be viewed with skepticism regarding the realism of earnings figures.

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-003-entities.md

@@ -0,0 +1,37 @@
+# Entity Title: Bucket Shops  
+## Definition  
+Bucket shops are facilities where individuals could trade stocks in small quantities, often with unscrupulous practices focused on exploiting customer behavior rather than genuine trading.  
+## Category  
+market  
+
+# Entity Title: Larry Livingston  
+## Definition  
+Larry Livingston is a pseudonym used by the narrator, who became well-known for successfully trading and defeating bucket shops.  
+## Category  
+trader  
+
+# Entity Title: Boy Plunger  
+## Definition  
+The nickname "Boy Plunger" was given to the narrator due to his aggressive trading style and ability to beat the bucket shops.  
+## Category  
+trader  
+
+# Entity Title: Cosmopolitan Stock Brokerage Company  
+## Definition  
+The Cosmopolitan Stock Brokerage Company is depicted as a large, reputable brokerage firm where the narrator eventually found a place to trade, known for its extensive business and numerous branches.  
+## Category  
+institution  
+
+# Entity Title: Margin  
+## Definition  
+Margin refers to the funds required to open and maintain a trading position, influencing the level of risk associated with trades. In this context, it reflects the narrator's experience with different amounts of capital and the behavior of risk.  
+## Category  
+evidence_bearing_claim  
+## Source Evidence  
+"If all I have is ten dollars and I risk it, I am much braver than when I risk a million..."  
+
+# Entity Title: Trading Strategy  
+## Definition  
+The narrator's approach involves starting with small positions in stocks and escalating his trades as he gains confidence, often using deception to outmaneuver brokers.  
+## Category  
+strategy  

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-003-summary.md

@@ -0,0 +1,28 @@
+# Summary of I Part 3
+
+## Narrator's Actions and Market Events
+- The narrator reflects on their experiences trading in stock markets, particularly in bucket shops.
+- They started with a small amount of capital (e.g., fifteen dollars) and built a successful trading practice independently.
+- Initially traded with various bucket shops, switching brokers frequently due to being labeled as a successful trader ("Boy Plunger").
+- Attempted to evade detection by adopting fictitious names while trading.
+- Experienced a shutdown from a bucket shop after winning considerable amounts, prompting further attempts to trade at other branches.
+
+## Named Strategies, Instruments, Venues, and Institutions
+- Strategies: Independent trading, switching brokers to avoid limits.
+- Instruments: Stocks traded in bucket shops.
+- Venues: Various bucket shops, Cosmopolitan Stock Brokerage Company (the largest broker encountered).
+
+## Explicit Lessons, Rules of Thumb, or Warnings
+- Margin trading is risky; small fluctuations can wipe out investments.
+- Avoid sharing trading strategies or business details to maintain an edge.
+- Be mindful of reputations within trading venues; successful traders can be barred from conducting business.
+
+## Evidence Phrases
+- "I made a good living out of the stock market."
+- "Trim us out of $700!" (indicating substantial gain against the bucket shop).
+- "Cosmopolitan Stock Brokerage Company" (the largest brokerage).
+- "A-1" rating of Cosmopolitan.
+
+## Ambiguities or Anachronisms
+- The narrator’s psychological perspective on "bravery" in trading relative to their capital is subjective and should be examined critically.
+- Dates and specific events leading to changes in broker acceptance are not well defined, necessitating further inquiry into context and timelines.

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-004-entities.md

@@ -0,0 +1,33 @@
+# Entity: Cosmopolitan Bucket Shop
+## Definition
+A trading venue characterized as the richest bucket shop in New England, offering extensive trading options including stocks, commodities, and more. It served as a last resort for traders and implemented strict margin and premium requirements that affected trading capacity.
+## Category
+market
+## Context
+The Cosmopolitan bucket shop imposed a three-point margin and a premium on trades, limiting the trading capacity of its customers. It was notable for its comprehensive quotation board and handling of various instruments across multiple exchanges.
+## Source Evidence
+"It was the richest bucket shop in New England... they put no limit on a trade... it had thousands of patrons and I really think I was the only man they were afraid of."
+
+---
+
+# Entity: Trading Premium
+## Definition
+An additional cost imposed by a broker or trading venue that increases the entry price of a security, effectively raising the breakeven point for the trader and diminishing potential profits.
+## Category
+error
+## Context
+The requirement of a premium added to the price a trader paid for a stock exaggerated the losses even when the stock increased in value.
+## Source Evidence
+"It meant that if the price was 90 when I bought... instead of making my ticket: ' Bot Steel at 90⅛ ,' it read: ' Bot Steel at 91⅛ .'"
+
+---
+
+# Entity: Margin Requirement
+## Definition
+A prerequisite where traders must deposit a certain percentage of the total trade value, reducing their capacity to trade by limiting the amount they can leverage on their balances.
+## Category
+error
+## Context
+The requirement of a three-point margin significantly reduced the trader's ability to maintain positions and limited the size of trades he could execute.
+## Source Evidence
+"they reduced my trading capacity by two-thirds."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-004-summary.md

@@ -0,0 +1,25 @@
+# Summary of Trading Literature - I Part 4
+
+### Narrator's Actions and Market Events
+- The narrator experienced restrictive trading conditions at the Cosmopolitan bucket shop, which imposed a three-point margin and increasing premiums on trades.
+- The narrator navigated the challenges of trading under these terms, continuing to buy and sell shares despite the limitations.
+
+### Named Strategies, Instruments, Venues, and Institutions
+- **Strategy:** Trading in bucket shops, specifically under unfavorable terms (three-point margin, increasing premium).
+- **Instruments:** Stocks (e.g., Steel).
+- **Venue:** Cosmopolitan bucket shop, the largest in New England.
+  
+### Explicit Lessons, Rules of Thumb, or Warnings
+- Beware of high premiums and margin requirements that can significantly handicap trading capacity.
+- Understand that bucket shops operate differently from traditional brokerage, often resulting in less favorable conditions for the trader.
+- Note that rapid market movements can impact trades negatively, especially when margins are tight.
+
+### Evidence Phrases
+- Mention of “Steel at 90⅛” and margins impacting ticket prices.
+- "Three-point margin" and the introduction of "a half point, then a point, and finally, a point and a half" premiums.
+- References to a “fine office” and the “largest and completest quotation board” at the Cosmopolitan.
+- The narrator alludes to being potentially the “heaviest individual trader” at the Cosmopolitan.
+
+### Ambiguities or Anachronisms
+- The terminology and practices of bucket shops may not be familiar or applicable in modern trading contexts, requiring a review for historical accuracy and relevance.
+- Clarification needed on operational specifics of the "fine office" and how it distinguishes itself from other bucket shops.

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-005-entities.md

@@ -0,0 +1,41 @@
+# Entity: Sugar Market
+## Definition
+The Sugar Market refers to the trading environment where Sugar shares are bought and sold, particularly in the context of the trades and prices discussed.
+## Category
+market
+
+# Entity: Margin Trading
+## Definition
+Margin Trading is a practice where traders borrow funds from a broker to trade financial assets, allowing them to leverage their investments and amplify potential returns.
+## Category
+strategy
+
+# Entity: Emotional Uncertainty
+## Definition
+Emotional Uncertainty describes a psychological state where a trader feels discomfort and indecision about market conditions, leading to a withdrawal from trades despite the absence of concrete reasons.
+## Category
+psychological_pattern
+
+# Entity: The Cosmopolitan
+## Definition
+The Cosmopolitan is identified as a specific trading venue or bucket shop where informal trading of shares takes place, characterized by its unique ticketing and margin policies.
+## Category
+institution
+
+# Entity: Closing Trades
+## Definition
+Closing Trades refer to the action of finalizing a position in the trading market, in this context executed by submitting tickets to a clerk to sell shares at the prevailing market price.
+## Category
+strategy
+
+# Entity: Dave Wyman
+## Definition
+Dave Wyman is a fellow trader mentioned in the narrative who assists by calling out prices while a primary trader decides to exit a market position.
+## Category
+trader
+
+# Entity: Tommy Burnham
+## Definition
+Tommy Burnham is the clerk at the trading venue responsible for marking trade tickets, noted for his attentiveness to market signals during the trading discussion.
+## Category
+trader

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-005-summary.md

@@ -0,0 +1,29 @@
+# Summary of I Part 5
+
+## Narrator's Actions and Market Events
+- The narrator initially had 3,500 shares of Sugar, margining with big pink tickets (five hundred shares each).
+- Market condition was soft; narrator observed price behavior and noted Sugar's decline.
+- Feeling uncomfortable with Sugar's hesitating price, the narrator decided to exit the market.
+- He delegated price calling to Dave Wyman and attempted to close his position before a potential price drop.
+
+## Named Strategies, Instruments, Venues, and Institutions
+- **Instruments**: Sugar (commodity).
+- **Venue**: Cosmopolitan bucket shop.
+- **Strategies**: Tactics for margining and early exit from trades based on price behavior and discomfort in market conditions.
+
+## Explicit Lessons, Rules of Thumb, or Warnings
+- Trust your instincts when market conditions change; discomfort can signal the need to exit a trade.
+- Observe market behavior closely and be aware of the psychological aspects of trading.
+- Do not remain in a trade without a clear understanding of why, especially when feeling uncertain.
+
+## Evidence Phrases
+- Margin amount: over **$10,000**.
+- Shares traded: **3,500 shares** of Sugar.
+- Price points: trade executed at **105¼**, sold at **103**.
+- Notable market participant: **Henry Williams** (shorting **2,500 shares** of Sugar).
+- Date and time not explicitly stated, but indicator of intra-day trading dynamics.
+
+## Ambiguities or Anachronisms
+- Vague reference to "something crooked" occurring without explicit details.
+- The term "bucket shop" might require contextual historical understanding for contemporary readers.
+- No clear timestamp or date is given for the events, which may affect chronology in relation to overall market trends or specific historical occurrences.

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-006-entities.md

@@ -0,0 +1,59 @@
+# Entity Title: Bucket Shop
+## Definition
+A bucket shop is a type of brokerage that allows speculative trading in stocks without actually buying shares. These shops often manipulate market prices to exploit their clients, leading to significant losses for traders.
+## Category
+market
+
+# Entity Title: Sugar (Commodity)
+## Definition
+Sugar refers to a specific commodity that is traded on the market, in this case, associated with the incident involving Tom and Henry Williams, where their positions were affected by market manipulation.
+## Category
+instrument
+
+# Entity Title: Cosmopolitan
+## Definition
+The Cosmopolitan is identified as a bucket shop that engaged in manipulative practices, specifically targeting short positions in Sugar by artificially inflating stock prices.
+## Category
+institution
+
+# Entity Title: Western Union (Stock)
+## Definition
+Western Union is a stock that was frequently manipulated by traders due to its relative ease of movement within the market, making it a favored target for speculative trading schemes.
+## Category
+instrument
+
+# Entity Title: Bucket-Shop Drive
+## Definition
+A bucket-shop drive refers to a situation where the prices of stocks are manipulated downwards in a coordinated effort to force clients who are long on those stocks to incur losses or be wiped out.
+## Category
+strategy
+
+# Entity Title: New York Stock Exchange
+## Definition
+The New York Stock Exchange (NYSE) is a major stock exchange where trading of stocks occurs, serving as a venue for some of the trading activities mentioned in the context of market manipulation.
+## Category
+market
+
+# Entity Title: Market Factor
+## Definition
+A market factor is an operator or trader who significantly influences trading conditions or stock prices within the market. In the text, a certain trader is identified as a market factor due to his previous successes in market manipulation.
+## Category
+trader
+
+# Entity Title: Bryan Panic of ’96
+## Definition
+The Bryan Panic of 1896 was a financial crisis characterized by significant volatility and manipulation in the markets, leading to widespread impact on traders, including those in bucket shops.
+## Category
+event
+
+# Entity Title: Short Position
+## Definition
+A short position refers to the practice of selling stocks that a trader does not own, with the intention of buying them back at a lower price to profit from the decline. It was a significant factor in the losses suffered by the traders in the context.
+## Category
+strategy
+
+# Entity Title: Bull Tips
+## Definition
+Bull tips are recommendations or information suggesting that a stock's price will rise, encouraging traders to buy. These were used strategically to influence market movements in the discussed scenario.
+## Category
+evidence_bearing_claim

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/generated/chapter-01-part-006-summary.md

@@ -0,0 +1,29 @@
+# Summary of Trading-Literature Source: I Part 6
+
+## Narrator's Actions and Market Reactions
+- The narrator interacts with Tom, marking tickets “Closed at 103” for seven shares.
+- The narrator reacts to market movements when Dave Wyman yells about Sugar reaching 108, indicating a run on the bucket shop.
+- The narrator comments on the market manipulation by noting the price drop following the peak.
+
+## Named Strategies, Instruments, Venues, and Institutions
+- **Strategies**: Market manipulation via bucket shop tactics and coordinated buying.
+- **Instruments**: Shares of Sugar and Western Union stock.
+- **Venues**: Bucket shops, New York Stock Exchange.
+- **Institutions**: Cosmopolitan bucket shop; Tom (an employee of the shop); Dave Wyman (ticker announcer); an unnamed New York operator.
+
+## Explicit Lessons, Rules of Thumb, or Warnings
+- A run on a bucket shop can be triggered by customer suspicion, similar to a bank run.
+- Bucket shops often manipulate stock prices to eliminate losing positions of their customers.
+- Unexplained sharp price drops followed by quick recoveries are indicative of bucket-shop drives.
+
+## Evidence Phrases
+- “six thousand shares of Sugar”
+- “$20,000 in Sugar margins”
+- “doubled-cross me” and “seventy thousand dollars” (gain from the intermediary operator’s manipulation).
+- Mention of "bought as much of a certain stock" and "sold at two points profit".
+- Reference to “the Bryan panic of ’96” for context on market events.
+
+## Ambiguities or Anachronisms
+- The identity of the unnamed New York operator and his specific techniques remains vague.
+- The transition from the operator's profitable ploy to his eventual obscurity lacks clarity—why he fell into obscurity is ambiguous.
+- The term "bucket-shop drive" may need explanation or may be outdated for contemporary readers.

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/relations/chapter-01-part-001-relations.md

@@ -0,0 +1,82 @@
+## Subject
+quotation-board boy
+
+## Predicate
+operates in
+
+## Object
+stock-brokerage office
+
+## Relation Type
+actor_venue
+
+## Evidence
+"I got a job as quotation-board boy in a stock-brokerage office."
+
+---
+
+## Subject
+stock prices
+
+## Predicate
+show
+
+## Object
+certain habits
+
+## Relation Type
+cause_effect
+
+## Evidence
+"I noticed that in advances as well as declines, stock prices were apt to show certain habits."
+
+---
+
+## Subject
+past performances
+
+## Predicate
+guide
+
+## Object
+anticipation of movements in prices
+
+## Relation Type
+risk_mitigation
+
+## Evidence
+"My only guide, as I say, was their past performances."
+
+---
+
+## Subject
+tape
+
+## Predicate
+is
+
+## Object
+telescope
+
+## Relation Type
+lesson_evidence
+
+## Evidence
+"A battle goes on in the stock market and the tape is your telescope."
+
+---
+
+## Subject
+observations
+
+## Predicate
+determine
+
+## Object
+probable movements
+
+## Relation Type
+lesson_evidence
+
+## Evidence
+"I was most interested in verifying whether I had observed accurately; in other words, whether I was right."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/relations/chapter-01-part-002-relations.md

@@ -0,0 +1,82 @@
+## Subject
+Hollow Tube
+
+## Predicate
+went down
+
+## Object
+three points
+
+## Relation Type
+cause_effect
+
+## Evidence
+"Hollow Tube went down three points the other day while the rest of the market rallied sharply."
+
+---
+
+## Subject
+directors
+
+## Predicate
+passed
+
+## Object
+the dividend
+
+## Relation Type
+cause_effect
+
+## Evidence
+"On the following Monday you saw that the directors passed the dividend."
+
+---
+
+## Subject
+Burlington
+
+## Predicate
+was acting as it usually did before it went up
+
+## Object
+n/a
+
+## Relation Type
+lesson_evidence
+
+## Evidence
+"Sure enough, Burlington, according to my figuring, was acting as it usually did before it went up."
+
+---
+
+## Subject
+trader
+
+## Predicate
+operates in
+
+## Object
+bucket shops
+
+## Relation Type
+actor_venue
+
+## Evidence
+"it was the ideal way to operate in a bucket shop."
+
+---
+
+## Subject
+speculating
+
+## Predicate
+produced
+
+## Object
+profit
+
+## Relation Type
+strategy_outcome
+
+## Evidence
+"I made a profit of $3.12."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/relations/chapter-01-part-003-relations.md

@@ -0,0 +1,48 @@
+## Subject
+Larry Livingston
+
+## Predicate
+operates in
+
+## Object
+bucket shops
+
+## Relation Type
+actor_venue
+
+## Evidence
+"He began in the smaller bucket shops, where the man who traded in twenty shares at a clip was suspected of being John W. Gates in disguise or J. P. Morgan traveling incognito."
+
+---
+
+## Subject
+bucket shops
+
+## Predicate
+cause
+
+## Object
+loss of customer funds
+
+## Relation Type
+cause_effect
+
+## Evidence
+"There were other ways of parting customers from their money, even when they guessed right."
+
+---
+
+## Subject
+Larry Livingston
+
+## Predicate
+risked
+
+## Object
+trading in the stock market
+
+## Relation Type
+strategy_outcome
+
+## Evidence
+"Anyhow, at fifteen I was making a good living out of the stock market."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/relations/chapter-01-part-004-relations.md

@@ -0,0 +1,82 @@
+## Subject
+Cosmopolitan
+
+## Predicate
+imposed
+
+## Object
+three-point margin
+
+## Relation Type
+risk_mitigation
+
+## Evidence
+"They made me put up a three-point margin and compelled me to pay a premium at first of a half point, then a point, and finally, a point and a half."
+
+---
+
+## Subject
+Cosmopolitan
+
+## Predicate
+reduced
+
+## Object
+trading capacity
+
+## Relation Type
+risk_mitigation
+
+## Evidence
+"they reduced my trading capacity by two-thirds."
+
+---
+
+## Subject
+trader
+
+## Predicate
+operates_in
+
+## Object
+bucket shop
+
+## Relation Type
+actor_venue
+
+## Evidence
+"the only bucket shop that would take my business at all"
+
+---
+
+## Subject
+trader
+
+## Predicate
+experienced
+
+## Object
+ups and downs
+
+## Relation Type
+strategy_outcome
+
+## Evidence
+"Of course I had my ups and downs, but was a winner on balance."
+
+---
+
+## Subject
+Cosmopolitan
+
+## Predicate
+attempted
+
+## Object
+double-cross
+
+## Relation Type
+cause_effect
+
+## Evidence
+"They tried to double-cross me."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/relations/chapter-01-part-005-relations.md

@@ -0,0 +1,82 @@
+## Subject
+Sugar
+
+## Predicate
+was sold at
+
+## Object
+103
+
+## Relation Type
+strategy_outcome
+
+## Evidence
+"I slapped my tickets on the counter in front of the clerk and yelled, 'Close Sugar!' ... turned out to be 103 again."  
+
+---
+
+## Subject
+Margin
+
+## Predicate
+was accumulated by
+
+## Object
+trader
+
+## Relation Type
+actor_venue
+
+## Evidence
+"I was only twenty when I first accumulated ten thousand dollars in cash."  
+
+---
+
+## Subject
+thinner shoestring
+
+## Predicate
+causes
+
+## Object
+profit for bucket shops
+
+## Relation Type
+cause_effect
+
+## Evidence
+"The thinner the shoestring the better for them, for their profit lies in your being wiped."  
+
+---
+
+## Subject
+risk of trading
+
+## Predicate
+was mitigated by
+
+## Object
+leaving the market
+
+## Relation Type
+risk_mitigation
+
+## Evidence
+"I thought I ought to get out of the market ... I couldn’t spot it exactly."  
+
+---
+
+## Subject
+Cosmopolitan
+
+## Predicate
+operated in
+
+## Object
+bucket shop
+
+## Relation Type
+actor_venue
+
+## Evidence
+"the Cosmopolitan used big slips with a blank space on them where they could write down additional margin."  

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/relations/chapter-01-part-006-relations.md

@@ -0,0 +1,65 @@
+## Subject
+Bucket shop practices
+
+## Predicate
+cause
+
+## Object
+Market manipulation
+
+## Relation Type
+cause_effect
+
+## Evidence
+"If one customer gets suspicious the others follow suit... a common practice to get some broker to wash down the price of that particular stock far enough to wipe out all the customers that were long of it."
+
+---
+
+## Subject
+Cosmopolitan
+
+## Predicate
+performed
+
+## Object
+Market manipulation
+
+## Relation Type
+actor_venue
+
+## Evidence
+"That was what the Cosmopolitan did to get me and Henry Williams and the other Sugar shorts."
+
+---
+
+## Subject
+Agent operations
+
+## Predicate
+produced
+
+## Object
+Profit
+
+## Relation Type
+strategy_outcome
+
+## Evidence
+"A fellow told me the originator cleaned up seventy thousand dollars net, and his agents made their expenses and their pay besides."
+
+---
+
+## Subject
+New York operator
+
+## Predicate
+engaged in
+
+## Object
+Market strategies
+
+## Relation Type
+actor_venue
+
+## Evidence
+"He made a great name for himself as a bear during the Bryan panic of ’96."

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/sources/chapter-01-part-001.md

@@ -0,0 +1,3 @@
+# I
+
+I went to work when I was just out of grammar school. I got a job as quotation-board boy in a stock-brokerage office. I was quick at figures. At school I did three years of arithmetic in one. I was particularly good at mental arithmetic. As quotation-board boy I posted the numbers on the big board in the customers’ room. One of the customers usually sat by the ticker and called out the prices. They couldn’t come too fast for me. I have always remembered figures. No trouble at all. There were plenty of other employes in that office. Of course I made friends with the other fellows, but the work I did, if the market was active, kept me too busy from ten A.M. to three P.M. to let me do much talking. I don’t care for it, anyhow, during business hours. But a busy market did not keep me from thinking about the work. Those quotations did not represent prices of stocks to me, so many dollars per share. They were numbers. Of course, they meant something. They were always changing. It was all I had to be interested in—the changes. Why did they change? I didn’t know. I didn’t care. I didn’t think about that. I simply saw that they changed. That was all I had to think about five hours every day and two on Saturdays: that they were always changing. That is how I first came to be interested in the behaviour of prices. I had a very good memory for figures. I could remember in detail how the prices had acted on the previous day, just before they went up or down. My fondness for mental arithmetic came in very handy. I noticed that in advances as well as declines, stock prices were apt to show certain habits, so to speak. There was no end of parallel cases and these made precedents to guide me. I was only fourteen, but after I had taken hundreds of observations in my mind I found myself testing their accuracy, comparing the behaviour of stocks to-day with other days. It was not long before I was anticipating movements in prices. My only guide, as I say, was their past performances. I carried the “dope sheets” in my mind. I looked for stock prices to run on form. I had “clocked” them. You know what I mean. You can spot, for instance, where the buying is only a trifle better than the selling. A battle goes on in the stock market and the tape is your telescope. You can depend upon it seven out of ten cases. Another lesson I learned early is that there is nothing new in Wall Street. There can’t be because speculation is as old as the hills. Whatever happens in the stock market to-day has happened before and will happen again. I’ve never forgotten that. I suppose I really manage to remember when and how it happened. The fact that I remember that way is my way of capitalizing experience. I got so interested in my game and so anxious to anticipate advances and declines in all the active stocks that I got a little book. I put down my observations in it. It was not a record of imaginary transactions such as so many people keep merely to make or lose millions of dollars without getting the swelled head or going to the poorhouse. It was rather a sort of record of my hits and misses, and next to the determination of probable movements I was most interested in verifying whether I had observed accurately; in other words, whether I was right. Say that after studying every fluctuation of the day in an active stock I would conclude that it was behaving as it always did before it broke eight or ten points. Well, I would jot down the stock and the price on Monday, and remembering past performances I would write down what it ought to do on Tuesday and Wednesday. Later I would check up with actual transcriptions from the tape. That is how I first came to take an interest in the message of the tape. The fluctuations were from the first associated in my mind with upward or downward movements. Of course there is always a reason for fluctuations, but the tape does not concern itself with the why and wherefore. It doesn’t go into explanations. I didn’t ask the tape why when I was fourteen, and I don’t ask it to-day, at forty. The reason for what a certain stock does to-day may not be known for two or three days, or weeks, or months. But what the dickens does that matter? Your business with the tape is now—not to-morrow. The reason can wait. But you must act

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/sources/chapter-01-part-002.md

@@ -0,0 +1,3 @@
+# I
+
+instantly or be left. Time and again I see this happen. You’ll remember that Hollow Tube went down three points the other day while the rest of the market rallied sharply. That was the fact. On the following Monday you saw that the directors passed the dividend. That was the reason. They knew what they were going to do, and even if they didn’t sell the stock themselves they at least didn’t buy it. There was no inside buying; no reason why it should not break. Well, I kept up my little memorandum book perhaps six months. Instead of leaving for home the moment I was through with my work, I’d jot down the figures I wanted and would study the changes, always looking for the repetitions and parallelisms of behaviour—learning to read the tape, although I was not aware of it at the time. One day one of the office boys—he was older than I—came to me where I was eating my lunch and asked me on the quiet if I had any money. “Why do you want to know?” I said. “Well,” he said, “I’ve got a dandy tip on Burlington. I’m going to play it if I can get somebody to go in with me.” “How do you mean, play it?” I asked. To me the only people who played or could play tips were the customers—old jiggers with oodles of dough. Why, it cost hundreds, even thousands of dollars, to get into the game. It was like owning your private carriage and having a coachman who wore a silk hat. “That’s what I mean; play it!” he said. “How much you got?” “How much you need?” “Well, I can trade in five shares by putting up $5.” “How are you going to play it?” “I’m going to buy all the Burlington the bucket shop will let me carry with the money I give him for margin,” he said. “It’s going up sure. It’s like picking up money. We’ll double ours in a jiffy.” “Hold on!” I said to him, and pulled out my little dope book. I wasn’t interested in doubling my money, but in his saying that Burlington was going up. If it was, my note-book ought to show it. I looked. Sure enough, Burlington, according to my figuring, was acting as it usually did before it went up. I had never bought or sold anything in my life, and I never gambled with the other boys. But all I could see was that this was a grand chance to test the accuracy of my work, of my hobby. It struck me at once that if my dope didn’t work in practice there was nothing in the theory of it to interest anybody. So I gave him all I had, and with our pooled resources he went to one of the near-by bucket shops and bought some Burlington. Two days later we cashed in. I made a profit of $3.12. After that first trade, I got to speculating on my own hook in the bucket shops. I’d go during my lunch hour and buy or sell—it never made any difference to me. I was playing a system and not a favorite stock or backing opinions. All I knew was the arithmetic of it. As a matter of fact, mine was the ideal way to operate in a bucket shop, where all that a trader does is to bet on fluctuations as they are printed by the ticker on the tape. It was not long before I was taking much more money out of the bucket shops than I was pulling down from my job in the brokerage office. So I gave up my position. My folks objected, but they couldn’t say much when they saw what I was making. I was only a kid and office-boy wages were not very high. I did mighty well on my own hook. I was fifteen when I had my first thousand and laid the cash in front of my mother—all made in the bucket shops in a few months, besides what I had taken home. My mother carried on something awful. She wanted me to put it away in the savings bank out of reach of temptation. She said it was more money than she ever heard any boy of fifteen had made, starting with nothing. She didn’t quite believe it was real money. She used to worry and fret about it. But I didn’t think of anything except that I could keep on proving my figuring was right. That’s all the fun there is—being right by using your head. If I was right when I tested my convictions with ten shares I would be ten times more right if I traded in a hundred shares. That is

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/sources/chapter-01-part-003.md

@@ -0,0 +1,3 @@
+# I
+
+all that having more margin meant to me—I was right more emphatically. More courage? No! No difference! If all I have is ten dollars and I risk it, I am much braver than when I risk a million, if I have another million salted away. Anyhow, at fifteen I was making a good living out of the stock market. I began in the smaller bucket shops, where the man who traded in twenty shares at a clip was suspected of being John W. Gates in disguise or J. P. Morgan traveling incognito. Bucket shops in those days seldom lay down on their customers. They didn’t have to. There were other ways of parting customers from their money, even when they guessed right. The business was tremendously profitable. When it was conducted legitimately—I mean straight, as far as the bucket shop went—the fluctuations took care of the shoestrings. It doesn’t take much of a reaction to wipe out a margin of only three quarters of a point. Also, no welsher could ever get back in the game. Wouldn’t have any trade. I didn’t have a following. I kept my business to myself. It was a one-man business, anyhow. It was my head, wasn’t it? Prices either were going the way I doped them out, without any help from friends or partners, or they were going the other way, and nobody could stop them out of kindness to me. I couldn’t see where I needed to tell my business to anybody else. I’ve got friends, of course, but my business has always been the same—a one-man affair. That is why I have always played a lone hand. As it was, it didn’t take long for the bucket shops to get sore on me for beating them. I’d walk in and plank down my margin, but they’d look at it without making a move to grab it. They’d tell me there was nothing doing. That was the time they got to calling me the Boy Plunger. I had to be changing brokers all the time, going from one bucket shop to another. It got so that I had to give a fictitious name. I’d begin light, only fifteen or twenty shares. At times, when they got suspicious, I’d lose on purpose at first and then sting them proper. Of course after a while they’d find me too expensive and they’d tell me to take myself and my business elsewhere and not interfere with the owners’ dividends. Once, when the big concern I’d been trading with for months shut down on me I made up my mind to take a little more of their money away from them. That bucket shop had branches all over the city, in hotel lobbies, and in near-by towns. I went to one of the hotel branches and asked the manager a few questions and finally got to trading. But as soon as I played an active stock my especial way he began to get messages from the head office asking who it was that was operating. The manager told me what they asked him and I told him my name was Edward Robinson, of Cambridge. He telephoned the glad news to the big chief. But the other end wanted to know what I looked like. When the manager told me that I said to him, “Tell him I am a short fat man with dark hair and a bushy beard!” But he described me instead, and then he listened and his face got red and he hung up and told me to beat it. “What did they say to you?” I asked him politely. “They said, ‘You blankety-blank fool, didn’t we tell you to take no business from Larry Livingston? And you deliberately let him trim us out of $700!’” He didn’t say what else they told him. I tried the other branches one after another, but they all got to know me, and my money wasn’t any good in any of their offices. I couldn’t even go in to look at the quotations without some of the clerks making cracks at me. I tried to get them to let me trade at long intervals by dividing my visits among them all. But that didn’t work. Finally there was only one left to me and that was the biggest and richest of all—the Cosmopolitan Stock Brokerage Company. The Cosmopolitan was rated as A-1 and did an enormous business. It had branches in every manufacturing town in New England. They took my trading all right, and I bought and sold stocks and made and lost money for months, but in the end it happened with them as usual. They didn’t refuse my business point-blank, as the small concerns had. Oh, not because it wasn’t sportsmanship, but because they knew

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/sources/chapter-01-part-004.md

@@ -0,0 +1,3 @@
+# I
+
+it would give them a black eye to publish the news that they wouldn’t take a fellow’s business just because that fellow happened to make a little money. But they did the next worse thing—that is, they made me put up a three-point margin and compelled me to pay a premium at first of a half point, then a point, and finally, a point and a half. Some handicap, that! How? Easy! Suppose Steel was selling at 90 and you bought it. Your ticket read, normally: “ Bot ten Steel at 90⅛. ” If you put up a point margin it meant that if it broke 89¼ you were wiped out automatically. In a bucket shop the customer is not importuned for more margin or put to the painful necessity of telling his broker to sell for anything he can get. But when the Cosmopolitan tacked on that premium they were hitting below the belt. It meant that if the price was 90 when I bought, instead of making my ticket: “ Bot Steel at 90⅛ ,” it read: “ Bot Steel at 91⅛ .” Why, that stock could advance a point and a quarter after I bought it and I’d still be losing money if I closed the trade. And by also insisting that I put up a three-point margin at the very start they reduced my trading capacity by two-thirds. Still, that was the only bucket shop that would take my business at all, and I had to accept their terms or quit trading. Of course I had my ups and downs, but was a winner on balance. However, the Cosmopolitan people were not satisfied with the awful handicap they had tacked on me, which should have been enough to beat anybody. They tried to double-cross me. They didn’t get me. I escaped because of one of my hunches. The Cosmopolitan, as I said, was my last resort. It was the richest bucket shop in New England, and as a rule they put no limit on a trade. I think I was the heaviest individual trader they had—that is, of the steady, every-day customers. They had a fine office and the largest and completest quotation board I have ever seen anywhere. It ran along the whole length of the big room and every imaginable thing was quoted. I mean stocks dealt in on the New York and Boston Stock Exchanges, cotton, wheat, provisions, metals—everything that was bought and sold in New York, Chicago, Boston and Liverpool. You know how they traded in bucket shops. You gave your money to a clerk and told him what you wished to buy or sell. He looked at the tape or the quotation board and took the price from there—the last one, of course. He also put down the time on the ticket so that it almost read like a regular broker’s report—that is, that they had bought or sold for you so many shares of such a stock at such a price at such a time on such a day and how much money they received from you. When you wished to close your trade you went to the clerk—the same or another, it depended on the shop—and you told him. He took the last price or if the stock had not been active he waited for the next quotation that came out on the tape. He wrote that price and the time on your ticket, O.K.’d it and gave it back to you, and then you went to the cashier and got whatever cash it called for. Of course, when the market went against you and the price went beyond the limit set by your margin, your trade automatically closed itself and your ticket became one more scrap of paper. In the humbler bucket shops, where people were allowed to trade in as little as five shares, the tickets were little slips—different colors for buying and selling—and at times, as for instance in boiling bull markets, the shops would be hard hit because all the customers were bulls and happened to be right. Then the bucket shop would deduct both buying and selling commissions and if you bought a stock at 20 the ticket would read 20¼. You thus had only ¾, of a point’s run for your money. But the Cosmopolitan was the finest in New England. It had thousands of patrons and I really think I was the only man they were afraid of. Neither the killing premium nor the three-point margin they made me put up reduced my trading much. I kept on buying and selling as much as they’d let me. I sometimes had a line of 5000 shares. Well, on the day the thing happened that I am going to tell you, I was short

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/sources/chapter-01-part-005.md

@@ -0,0 +1,3 @@
+# I
+
+thirty-five hundred shares of Sugar. I had seven big pink tickets for five hundred shares each. The Cosmopolitan used big slips with a blank space on them where they could write down additional margin. Of course, the bucket shops never ask for more margin. The thinner the shoestring the better for them, for their profit lies in your being wiped. In the smaller shops if you wanted to margin your trade still further they’d make out a new ticket, so they could charge you the buying commission and only give you a run of ¾ of a point on each point’s decline, for they figured the selling commission also exactly as if it were a new trade. Well, this day I remember I had up over $10,000 in margins. I was only twenty when I first accumulated ten thousand dollars in cash. And you ought to have heard my mother. You’d have thought that ten thousand dollars in cash was more than anybody carried around except old John D., and she used to tell me to be satisfied and go into some regular business. I had a hard time convincing her that I was not gambling, but making money by figuring. But all she could see was that ten thousand dollars was a lot of money and all I could see was more margin. I had put out my 3500 shares of Sugar at 105¼. There was another fellow in the room, Henry Williams, who was short 2500 shares. I used to sit by the ticker and call out the quotations for the board boy. The price behaved as I thought it would. It promptly went down a couple of points and paused a little to get its breath before taking another dip. The general market was pretty soft and everything looked promising. Then all of a sudden I didn’t like the way Sugar was doing its hesitating. I began to feel uncomfortable. I thought I ought to get out of the market. Then it sold at 103—that was low for the day—but instead of feeling more confident I felt more uncertain. I knew something was wrong somewhere, but I couldn’t spot it exactly. But if something was coming and I didn’t know where from, I couldn’t be on my guard against it. That being the case I’d better be out of the market. You know, I don’t do things blindly. I don’t like to. I never did. Even as a kid I had to know why I should do certain things. But this time I had no definite reason to give to myself, and yet I was so uncomfortable that I couldn’t stand it. I called to a fellow I knew, Dave Wyman, and said to him: “Dave, you take my place here. I want you to do something for me. Wait a little before you call out the next price of Sugar, will you?” He said he would, and I got up and gave him my place by the ticker so he could call out the prices for the boy. I took my seven Sugar tickets out of my pocket and walked over to the counter, to where the clerk was who marked the tickets when you closed your trades. But I didn’t really know why I should get out of the market, so I just stood there, leaning against the counter, my tickets in my hand so that the clerk couldn’t see them. Pretty soon I heard the clicking of a telegraph instrument and I saw Tom Burnham, the clerk, turn his head quickly and listen. Then I felt that something crooked was hatching, and I decided not to wait any longer. Just then Dave Wyman by the ticker, began: “Su—” and quick as a flash I slapped my tickets on the counter in front of the clerk and yelled, “Close Sugar!” before Dave had finished calling the price. So, of course, the house had to close my Sugar at the last quotation. What Dave called turned out to be 103 again. According to my dope Sugar should have broken 103 by now. The engine wasn’t hitting right. I had the feeling that there was a trap in the neighbourhood. At all events, the telegraph instrument was now going like mad and I noticed that Tom Burnham, the clerk, had left my tickets unmarked where I laid them, and was listening to the clicking as if he were waiting for something. So I yelled at him: “Hey, Tom, what in hell are you waiting for? Mark the price on these tickets—103! Get a gait on!” Everybody in the room heard me and began to look toward us and ask what was the trouble, for, you see, while the Cosmopolitan had never laid down, there was no telling,

infospaces/lefevre-reminiscences-of-a-stock-operator/artifacts/sources/chapter-01-part-006.md

@@ -0,0 +1,3 @@
+# I
+
+and a run on a bucket shop can start like a run on a bank. If one customer gets suspicious the others follow suit. So Tom looked sulky, but came over and marked my tickets “Closed at 103” and shoved the seven of them over toward me. He sure had a sour face. Say, the distance from Tom’s place to the cashier’s cage wasn’t over eight feet. But I hadn’t got to the cashier to get my money when Dave Wyman by the ticker yelled excitedly: “Gosh! Sugar, 108!” But it was too late; so I just laughed and called over to Tom, “It didn’t work that time, did it, old boy?” Of course, it was a put-up job. Henry Williams and I together were short six thousand shares of Sugar. That bucket shop had my margin and Henry’s, and there may have been a lot of other Sugar shorts in the office; possibly eight or ten thousand shares in all. Suppose they had $20,000 in Sugar margins. That was enough to pay the shop to thimblerig the market on the New York Stock Exchange and wipe us out. In the old days whenever a bucket shop found itself loaded with too many bulls on a certain stock it was a common practice to get some broker to wash down the price of that particular stock far enough to wipe out all the customers that were long of it. This seldom cost the bucket shop more than a couple of points on a few hundred shares, and they made thousands of dollars. That was what the Cosmopolitan did to get me and Henry Williams and the other Sugar shorts. Their brokers in New York ran up the price to 108. Of course it fell right back, but Henry and a lot of others were wiped out. Whenever there was an unexplained sharp drop which was followed by instant recovery, the newspapers in those days used to call it a bucket-shop drive. And the funniest thing was that not later than ten days after the Cosmopolitan people tried to double-cross me a New York operator did them out of over seventy thousand dollars. This man, who was quite a market factor in his day and a member of the New York Stock Exchange, made a great name for himself as a bear during the Bryan panic of ’96. He was forever running up against Stock Exchange rules that kept him from carrying out some of his plans at the expense of his fellow members. One day he figured that there would be no complaints from either the Exchange or the police authorities if he took from the bucket shops of the land some of their ill-gotten gains. In the instance I speak of he sent thirty-five men to act as customers. They went to the main office and to the bigger branches. On a certain day at a fixed hour the agents all bought as much of a certain stock as the managers would let them. They had instructions to sneak out at a certain profit. Of course what he did was to distribute bull tips on that stock among his cronies and then he went in to the floor of the Stock Exchange and bid up the price, helped by the room traders, who thought he was a good sport. Being careful to pick out the right stock for that work, there was no trouble in putting up the price three or four points. His agents at the bucket shops cashed in as prearranged. A fellow told me the originator cleaned up seventy thousand dollars net, and his agents made their expenses and their pay besides. He played that game several times all over the country, punishing the bigger bucket shops of New York, Boston, Philadelphia, Chicago, Cincinnati and St. Louis. One of his favorite stocks was Western Union, because it was so easy to move a semiactive stock like that a few points up or down. His agents bought it at a certain figure, sold at two points profit, went short and took three points more. By the way, I read the other day that that man died, poor and obscure. If he had died in 1896 he would have got at least a column on the first page of every New York paper. As it was he got two lines on the fifth.

infospaces/lefevre-reminiscences-of-a-stock-operator/infospace.yaml

@@ -0,0 +1,91 @@
+slug: lefevre-reminiscences-of-a-stock-operator
+name: Reminiscences of a Stock Operator
+topic:
+  name: Reminiscences of a Stock Operator
+  domain: ''
+  sources: artifacts/sources
+disciplines: []
+schemas:
+  entity: profiles/trading-literature/contracts/entity.contract.md
+  relation: profiles/trading-literature/contracts/relation.contract.md
+  evaluation: profiles/trading-literature/contracts/evaluation.contract.md
+workflows:
+- id: generic-source-summary
+  description: Summarize normalized source chunks.
+  inputs:
+    source:
+      kind: source
+  static_macros:
+    profile: trading-literature
+  stages:
+  - id: summarize-source
+    kind: assisted
+    input: source
+    template: workflows/templates/trading-literature/summarize-source.md
+    provider_hint: openrouter
+    output:
+      path: artifacts/generated/{{ input.slug }}-summary.md
+      artifact_id: generated/{{ input.slug }}-summary.md
+      kind: generated
+      title: '{{ input.title }} Summary'
+- id: generic-source-entities
+  description: Extract reusable entity artifacts from source chunks.
+  inputs:
+    source:
+      kind: source
+  static_macros:
+    profile: trading-literature
+  stages:
+  - id: extract-entities
+    kind: assisted
+    input: source
+    template: workflows/templates/trading-literature/extract-entities.md
+    provider_hint: openrouter
+    output:
+      path: artifacts/generated/{{ input.slug }}-entities.md
+      artifact_id: generated/{{ input.slug }}-entities.md
+      kind: generated
+      title: '{{ input.title }} Entity Bundle'
+  - id: split-entities
+    kind: split_entities
+    input: source
+    template: ''
+    static_macros:
+      bundle_stage: extract-entities
+- id: generic-source-relations
+  description: Extract relation artifacts from source chunks.
+  inputs:
+    source:
+      kind: source
+  static_macros:
+    profile: trading-literature
+  stages:
+  - id: extract-relations
+    kind: assisted
+    input: source
+    template: workflows/templates/trading-literature/extract-relations.md
+    provider_hint: openrouter
+    output:
+      path: artifacts/relations/{{ input.slug }}-relations.md
+      artifact_id: relation/{{ input.slug }}-relations.md
+      kind: relation
+      title: '{{ input.title }} Relations'
+- id: generic-source-evaluations
+  description: Evaluate generated entities with the profile rubric.
+  inputs:
+    entity:
+      kind: entity
+  static_macros:
+    profile: trading-literature
+  stages:
+  - id: evaluate-entity
+    kind: assisted
+    input: entity
+    template: workflows/templates/trading-literature/evaluate-entity.md
+    provider_hint: openrouter
+    output:
+      path: output/evaluations/{{ input.slug }}.md
+      artifact_id: generated/evaluation-{{ input.slug }}.md
+      kind: generated
+      title: '{{ input.title }} Evaluation'
+viability: {}

infospaces/lefevre-reminiscences-of-a-stock-operator/output/budget/plans.yaml

@@ -0,0 +1,85 @@
+schema_version: 1
+pruned_count: 0
+snapshots:
+- snapshot_id: 0edf2ef6f38d
+  recorded_at: '2026-05-18T22:49:30.614317+00:00'
+  stage: all
+  filters:
+    stage: all
+    chapter_filter: null
+    chunk_filter: null
+    from_chapter: null
+    to_chapter: null
+  selected_chunk_count: 6
+  selected_chunk_ids:
+  - chapter-01-part-001
+  - chapter-01-part-002
+  - chapter-01-part-003
+  - chapter-01-part-004
+  - chapter-01-part-005
+  - chapter-01-part-006
+  selected_chapter_numbers:
+  - 1
+  per_workflow:
+  - workflow_id: generic-source-summary
+    calls: 6
+    prompt_words_estimate: 5437
+  - workflow_id: generic-source-entities
+    calls: 6
+    prompt_words_estimate: 6193
+  - workflow_id: generic-source-relations
+    calls: 6
+    prompt_words_estimate: 5965
+  - workflow_id: generic-source-evaluations
+    calls: 12
+    prompt_words_estimate: 3408
+  total_provider_calls_estimate: 30
+  total_prompt_tokens_estimate: 28004
+  total_prompt_words_estimate: 21003
+  estimated_cost_usd: 8.4012
+  cost_per_1k_tokens: 0.3
+  max_calls: null
+  cost_cap: null
+  exceeds_max_calls: false
+  exceeds_cost_cap: false
+- snapshot_id: b3cb7e662a4d
+  recorded_at: '2026-05-19T02:01:09.129797+00:00'
+  stage: all
+  filters:
+    stage: all
+    chapter_filter: null
+    chunk_filter: null
+    from_chapter: null
+    to_chapter: null
+  selected_chunk_count: 6
+  selected_chunk_ids:
+  - chapter-01-part-001
+  - chapter-01-part-002
+  - chapter-01-part-003
+  - chapter-01-part-004
+  - chapter-01-part-005
+  - chapter-01-part-006
+  selected_chapter_numbers:
+  - 1
+  per_workflow:
+  - workflow_id: generic-source-summary
+    calls: 6
+    prompt_words_estimate: 5437
+  - workflow_id: generic-source-entities
+    calls: 6
+    prompt_words_estimate: 6193
+  - workflow_id: generic-source-relations
+    calls: 6
+    prompt_words_estimate: 5965
+  - workflow_id: generic-source-evaluations
+    calls: 12
+    prompt_words_estimate: 3408
+  total_provider_calls_estimate: 30
+  total_prompt_tokens_estimate: 28004
+  total_prompt_words_estimate: 21003
+  estimated_cost_usd: 0.007561
+  cost_per_1k_tokens: null
+  max_calls: null
+  cost_cap: null
+  exceeds_max_calls: false
+  exceeds_cost_cap: false

infospaces/lefevre-reminiscences-of-a-stock-operator/output/budget/summary.yaml

@@ -0,0 +1,61 @@
+schema_version: 1
+recorded_at: '2026-05-18T23:17:35.435576+00:00'
+run_index: 2
+snapshot_id: 0edf2ef6f38d
+snapshot_resolved: true
+calls:
+  estimated: 30
+  actual: 32
+  delta: 2
+  ratio: 1.0667
+prompt_tokens:
+  estimated: 28004
+  actual: 28188
+  delta: 184
+  ratio: 1.0066
+total_tokens:
+  estimated: 28004
+  actual: 35749
+  delta: 7745
+  ratio: 1.2766
+cost_usd:
+  estimated: 8.4012
+  actual_known: 0.008766
+  actual_estimated_from_rates: 0.0
+  actual_total: 0.008766
+  delta: -8.392434
+  ratio: 0.001
+per_workflow:
+- workflow_id: generic-source-entities
+  calls:
+    estimated: 6
+    actual: 6
+    delta: 0
+    ratio: 1.0
+  prompt_tokens_actual: 8044
+  prompt_words_estimate: 6193
+- workflow_id: generic-source-evaluations
+  calls:
+    estimated: 12
+    actual: 14
+    delta: 2
+    ratio: 1.1667
+  prompt_tokens_actual: 5796
+  prompt_words_estimate: 3408
+- workflow_id: generic-source-relations
+  calls:
+    estimated: 6
+    actual: 6
+    delta: 0
+    ratio: 1.0
+  prompt_tokens_actual: 7570
+  prompt_words_estimate: 5965
+- workflow_id: generic-source-summary
+  calls:
+    estimated: 6
+    actual: 6
+    delta: 0
+    ratio: 1.0
+  prompt_tokens_actual: 6778
+  prompt_words_estimate: 5437
+duration_seconds: 315.207

infospaces/lefevre-reminiscences-of-a-stock-operator/output/budget/usage.yaml

@@ -0,0 +1,158 @@
+schema_version: 1
+runs:
+- run_index: 1
+  started_at: '2026-05-18T22:49:38.943612+00:00'
+  completed_at: '2026-05-18T22:53:11.667930+00:00'
+  duration_seconds: 218.606
+  snapshot_id: 0edf2ef6f38d
+  workflows:
+  - run_id: c845a568d7fb
+    workflow_id: generic-source-summary
+    status: completed
+    stage_count: 6
+  - run_id: da0c6e77da98
+    workflow_id: generic-source-entities
+    status: completed
+    stage_count: 12
+  - run_id: 16a4a9fe0ff5
+    workflow_id: generic-source-relations
+    status: completed
+    stage_count: 6
+  - run_id: a25fbeed2ef7
+    workflow_id: generic-source-evaluations
+    status: completed
+    stage_count: 7
+  rollup:
+    total_calls: 25
+    total_prompt_tokens: 25501
+    total_completion_tokens: 7149
+    total_tokens: 32650
+    total_cost_usd_known: 0.008116
+    total_cost_usd_estimated: null
+  per_bucket:
+  - workflow_id: generic-source-summary
+    stage_id: summarize-source
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 6
+    prompt_tokens: 6778
+    completion_tokens: 2301
+    total_tokens: 9079
+    cost_usd_known: 0.002397
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+  - workflow_id: generic-source-entities
+    stage_id: extract-entities
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 6
+    prompt_tokens: 8044
+    completion_tokens: 2199
+    total_tokens: 10243
+    cost_usd_known: 0.002527
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+  - workflow_id: generic-source-relations
+    stage_id: extract-relations
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 6
+    prompt_tokens: 7570
+    completion_tokens: 1314
+    total_tokens: 8884
+    cost_usd_known: 0.001924
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+  - workflow_id: generic-source-evaluations
+    stage_id: evaluate-entity
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 7
+    prompt_tokens: 3109
+    completion_tokens: 1335
+    total_tokens: 4444
+    cost_usd_known: 0.001268
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+- run_index: 2
+  started_at: '2026-05-18T23:12:29.783882+00:00'
+  completed_at: '2026-05-18T23:17:35.315574+00:00'
+  duration_seconds: 315.207
+  snapshot_id: 0edf2ef6f38d
+  workflows:
+  - run_id: c02bba00267b
+    workflow_id: generic-source-summary
+    status: completed
+    stage_count: 6
+  - run_id: 7fbe533bf5c7
+    workflow_id: generic-source-entities
+    status: completed
+    stage_count: 12
+  - run_id: 48c9faaae70e
+    workflow_id: generic-source-relations
+    status: completed
+    stage_count: 6
+  - run_id: f4732c7504fc
+    workflow_id: generic-source-evaluations
+    status: completed
+    stage_count: 14
+  rollup:
+    total_calls: 32
+    total_prompt_tokens: 28188
+    total_completion_tokens: 7561
+    total_tokens: 35749
+    total_cost_usd_known: 0.008766
+    total_cost_usd_estimated: null
+  per_bucket:
+  - workflow_id: generic-source-summary
+    stage_id: summarize-source
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 6
+    prompt_tokens: 6778
+    completion_tokens: 2081
+    total_tokens: 8859
+    cost_usd_known: 0.002265
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+  - workflow_id: generic-source-entities
+    stage_id: extract-entities
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 6
+    prompt_tokens: 8044
+    completion_tokens: 1987
+    total_tokens: 10031
+    cost_usd_known: 0.002399
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+  - workflow_id: generic-source-relations
+    stage_id: extract-relations
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 6
+    prompt_tokens: 7570
+    completion_tokens: 1368
+    total_tokens: 8938
+    cost_usd_known: 0.001956
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0
+  - workflow_id: generic-source-evaluations
+    stage_id: evaluate-entity
+    provider: openrouter
+    model: openai/gpt-4o-mini
+    calls: 14
+    prompt_tokens: 5796
+    completion_tokens: 2125
+    total_tokens: 7921
+    cost_usd_known: 0.002146
+    cost_usd_estimated: null
+    cost_status: known
+    cost_estimated_for_calls: 0

infospaces/lefevre-reminiscences-of-a-stock-operator/output/evaluations/entity-title-bryan-panic-of-96.md

@@ -0,0 +1,16 @@
+```yaml
+artifact_id: entity/entity-title-bryan-panic-of-96.md
+evaluator: trading-literature
+evaluated_at: 2023-10-03
+scores:
+  groundedness: 4
+  lesson_clarity: 3
+  historical_context: 5
+  overgeneralization_risk: 4
+```
+
+## Review Notes
+- **Groundedness (4)**: While the definition provides a historical context, there is some imprecision in the use of "manipulation" without specific examples.
+- **Lesson Clarity (3)**: The lesson conveyed regarding the impact on traders could be clearer; it lacks a structured takeaway for future application.
+- **Historical Context (5)**: The event is accurately placed in the 1890s financial landscape.
+- **Overgeneralization Risk (4)**: The term "bucket shops" may imply broader applicability, but the scope remains mostly focused on the specific event.