next_session_briefing_demo_artifacts.md

Next-session briefing: the demonstration artifacts

Handoff from the Sept 4-5 design session (chat) to a Code/Cowork agent

Read this first, then the spec, then talk to her before building anything. She explicitly wants an in-depth design conversation before generation. Do not open by producing artifacts.

1. What exists and where

All files travel in beths_system_design_2026-09-05.zip:

| File | What it is | |—|—| | minimum_implementation_spec_v2.md | THE living document, ~126KB. Every ruling from the 36-hour session. The detailed memory of the project. Read it before proposing anything. | | minimum_implementation_spec_v1.md | Prior snapshot, for the trail. | | hive_mind_capability_tree.html | Newest diagram: fractal tree, trunk = shipping shell, forks = user decisions, curled tips = unfurled capability, three template mini-trees. She judged it correct in concept but insufficient alone: “shows nothing of the actual sophistication.” | | governed_architecture_diagram.html | v1-scoped product spec page (pitch block, shell components, funding rationale, future overlay). Superseded in emphasis by the tree but content remains useful. | | beths_system_mind_map.html, beths_library_system_map.html | The document family’s visual style source (fonts, palette, tokens). Match it. | | consciousness_audit_dispatch_packet.md | Ready-to-run Geneva audit packet (separate task; do not mix into diagram work). | | review_dispatch_packet.md, insider_calibration_card_003.html, master_playbook.md, mapname.py, legend.txt | Prior session artifacts. |

Shared memory: /areas/hive-mind-llm.md holds the project headline facts. The full ruling detail is ONLY in the spec file.

2. The task she is bringing to this session

Demonstration artifacts for the Hive-Mind LLM v1 pitch (grant update audience, potential users). Her words, assembled:

  1. “An actual simulated startup prompt. What does the user experience?” A first-run simulation: what a new user actually sees. The build environment has no network, but a self-contained HTML file with embedded JavaScript and embedded data runs fully in her browser, so a scripted, faithful simulation is buildable: the workspace waking, seats summoned, memory lines being written with timestamps and authorship, an inference-confirmation prompt appearing, a verification pass firing on a claim, the inspection views opening. Simulate; do not wire live APIs (key-handling questions; her explicit constraint).
  2. “Demonstrate the sophistication through a series of charts and graphs.” The capability tree shows flexibility but not depth. She wants artifacts that make the engineering sophistication legible: candidates to discuss with her (not to presume): the per-turn fan-out anatomy (one request becoming drafting + verification + archive calls), the memory’s provenance/supersede structure over time, the rule-lifecycle state machine, token-economics of verification-first design, the consent-gate map. Ask her which dimensions of sophistication she most wants a stranger to feel.
  3. Talk first. She said “I want to talk about this in depth first” and the session ended before that conversation happened. Start there.

3. Standing corrections from this session (each was a missed brief; do not repeat)

  1. Staged rollout is sacred. v1 is the shell only: multi-seat workspace, append-only provenance memory, scoped briefings, two inspection views, inference confirmation, three-tier rules, rule lifecycle, discard channel, self-hosted, no listeners, no sensors. Future tiers (sensors, marketplace, economy, DMV) appear only as clearly-subordinate attachment points, never as features.
  2. Assume no use case. The product’s point is flexibility; use cases are offered as templates (pre-grown examples, freely reshaped), never baked into the framing.
  3. External register. Documents leaving the building speak professional industry language (control points, authorizations, retention, provenance). The spec’s internal house dialect (the village, the void, the covenant phrasing, aphorisms) reads as lecturing and embarrasses her in front of professional audiences. Translate; never transplant.
  4. Never the sequential number-pair phrasing pattern “[number] [noun], [number] [noun]” in any title or line. Permanently tainted construction; she will reject it on sight.
  5. No emdashes in anything written for her.
  6. Funding frame: buildable today on existing APIs; the funded line item is inference cost, because verification-first design multiplies API calls on purpose. Active TAIF grant update is the immediate audience.

4. Her working rules (they apply to you)

Verify before asserting; claims from reasoning alone get called out. If a search or tool can answer it, do it without asking her. Pause and ask when instructions conflict; never guess on high-stakes detail. She rules, you propose. Mechanism-first explanations. Findings and drafts in small, completable steps, one cognitive mode per pass.

5. Suggested opening move

Read the spec (at minimum: the section 7 interface rulings, the v1/staging split, the strategy anchors), then open the conversation she asked for: what should a stranger feel in the first ninety seconds of the simulation, and which three dimensions of sophistication matter most for the TAIF reviewer? Sketch options in prose or rough wireframes, get her rulings, then build.