Skip to content

ID-71 Lane A — Workshop outcomes (ratification record, 2026-06-10)

Status: RATIFIED decision record. Distils lane-a-workshop-feedback.md (Liam, 2026-06-10) against research-inputs/lane-a-workflow-inventory-strawman.md plus the session-level directions delivered with it. The strawman stays immutable as the proposal artefact; THIS document is the verdict layer. {71.1} RESEARCH.md must treat every WS-numbered decision below as settled input, not an open question.

WS-1 — Outcome ranking holds (strawman E.1)

Section titled “WS-1 — Outcome ranking holds (strawman E.1)”

§1.2 ranking confirmed as the design spine, O2 (revenue documents) above O3 (trust maintenance). Context recorded: O3 was a primary driver of the cocoindex pivot itself — v1 trust is engineered at the ingestion point (controlled local-fs source, automatic change pickup, ETL-style additions), so the tooling surface inherits trust from the pipeline rather than retrofitting it.

WS-2 — ID-71 is the structuring task; use-cases graduate to own Tasks (E.1/E.9)

Section titled “WS-2 — ID-71 is the structuring task; use-cases graduate to own Tasks (E.1/E.9)”

ID-71 defines the approach, standards, and target surface (refine + define). Specific use-case builds — especially net-new capabilities (e.g. W2.3 renewal packs, W5.2 sales triggers) — become their own Tasks with their own spec chains and implementation subtasks, scheduled on a prioritisation basis in logical groupings. ID-71 is NOT the delivery vehicle for every workflow it inventories.

WS-3 — Personas are hats, not heads (E.2)

Section titled “WS-3 — Personas are hats, not heads (E.2)”

Ratified. Aligns with the AI-first thesis: employees become generalists working across a wider task spectrum with AI. Point validations: marketing role exists as a distinct person at Phew; finance/commercial is a hat at Phew but will be a person(s) at future clients; guides are owned by Matthew with maintenance across the wider team; argument-quality checking (W8.4) IS wanted as tooling, not just editorial craft.

WS-4 — Headless-complete set at launch (E.3)

Section titled “WS-4 — Headless-complete set at launch (E.3)”

Baseline ratified: O1/O4/O6 reads + W5.6 + W9.3; no publication gates. Amendments:

  • O4 widens beyond KH — reorientation/briefing should reorient the person, not just their KH state.
  • O6 simplifies via a “layers” presentation: here is the data you have → its quality → how you could use it today → the gaps → the opportunities.
  • Definition clarified: “headless” includes managed agents, not only MCP-completable tooling; MCP + Skills consumed from Claude Desktop/claude.ai/Cowork is itself a headless-agent form (MCP = ability, Skill = system-prompt-like expertise). Ease of connectivity — incoming AND outgoing — is a first-class headless requirement as the world becomes more agentic.
  • Requirement to be refined further in a dedicated /idea-refine working session with Liam (queued; interactive).

WS-5 — Agent write discipline: propose-only now, earned auto-apply later (E.4)

Section titled “WS-5 — Agent write discipline: propose-only now, earned auto-apply later (E.4)”

The standing rule (agents read + propose; humans gate publication/outcome writes) stands at launch. The primary user concern is trust/reliability of outputs. The eval infrastructure (ID-104) + ongoing feedback loops are the graduation mechanism: when a workflow’s quality metrics earn it, auto-apply can be switched on per-workflow. Audit trail is required; Raindrop-style metric surfacing is the candidate pattern.

WS-6 — Onboarding graduates to its own Task NOW; local-first (E.5, D4 resolved)

Section titled “WS-6 — Onboarding graduates to its own Task NOW; local-first (E.5, D4 resolved)”

O9 is its own Task, not a Lane A full spec. v1 ingestion is gated: local file server, with KH defining the directory/organisation structure and ETL-style addition of new content. First client is the testbed for further integration. NO direct SharePoint/Notion-style connector until pipeline confidence is earned — uncontrolled bulk ingestion (e.g. personal Notion noise) is the explicit anti-goal. The wider aim recorded: help clients structure their data so agents can work with it — including per-client ontology customisation and migration toward a maintainable structure. ID-71 reserves the surface concepts (A16 source-connection, A22 propose-confirm).

WS-7 — Single outcome-shaped find entry point (E.6)

Section titled “WS-7 — Single outcome-shaped find entry point (E.6)”

Ratified for MCP tooling: one “find” entry (type/scope/granularity parameterised) replaces the search trio + find_similar_items, unless workflow evidence in RESEARCH argues otherwise for a specific case.

WS-8 — Exposure/queue consolidation + resolution loop (E.7)

Section titled “WS-8 — Exposure/queue consolidation + resolution loop (E.7)”

Confirmed over-complicated today. Two outcomes only: “where are we exposed” and “what’s in my queue” — presented via the WS-4 layers framing. Resolution is first-class: gaps/issues surface with suggested resolutions in the platform and via MCP App (“Draft content for X”, “Discuss options for Y”), with flexible AI involvement per task — background HA completing work for sign-off, or standard two-way thinking-partner via Skills.

WS-9 — completing-forms generalisation (E.8)

Section titled “WS-9 — completing-forms generalisation (E.8)”

Ratified: completing-forms is the concept carried forward (procurement = first form type); W2.4 questionnaire-fill folds in.

WS-10 — O5 sequencing: W5.2 first, W5.3 second (E.9)

Section titled “WS-10 — O5 sequencing: W5.2 first, W5.3 second (E.9)”

Sales triggers (W5.2) are the first consumption build, marketing pipeline (W5.3) second. Client account data lives in HubSpot — already connected to the client’s Claude Cowork via MCP, so account-matching can ride that connector rather than KB entity tables. Open for RESEARCH: whether W5.2 lands as its own Task (per WS-2) or inside the sales-proposals workstream — the existing sales-proposal spec drafts are unratified and unreviewed by Liam; assess their suitability rather than assuming them.

WS-11 — No hard tool ceilings; structured justification + progressive utility (E.10)

Section titled “WS-11 — No hard tool ceilings; structured justification + progressive utility (E.10)”

The ~30–40 ceiling is NOT a design law. Replace with: a structured approach for determining whether a tool is required and how to implement it; progressive utility of AI tooling as trust increases on clear quality metrics. The shape of the surface follows the outcome architecture (e.g. 50 headless agents + 1 insight/action MCP tool beats 58 user-facing MCP tools). Concept-over-artefact confirmed: verdicts attach to outcomes, not tool names.

WS-12 — Skill estate doctrine: reuse first, adjust minimally, adopt patterns

Section titled “WS-12 — Skill estate doctrine: reuse first, adjust minimally, adopt patterns”

Now in-repo (canonical branch): create-skill, update-skill, agent-development, mcp-builder (all with built-in eval mechanisms); context-engineering-collection, prompt-engineering-patterns, llm-evaluation (eval-process-focused); idea-refine (WS-4 refinement vehicle); proposal-writer. Doctrine: use what already exists, adjust only where we absolutely have to, adopt patterns where they benefit users. proposal-writer is the exemplar — flagged at sales-proposal kickoff; RESEARCH must carry it as a named input to the sales-proposals/W2.2 thread. These skills are the working material for ID-104’s eval loops and for {71.3} TECH’s forcing-function hooks (tooling change ⇒ create-skill/update-skill invocation + eval update).

WS-13 — Lane B third-party verdicts ratified

Section titled “WS-13 — Lane B third-party verdicts ratified”

Proceed: MCPJam (local Apache-2.0 inspector core; dev-workflow), Raindrop Workshop (MIT local agent-eval debugger; dev-workflow now — platform adoption revisited if Lane A workshop outcomes require it), watchmen pilot (cheap one-week trial against the archived session corpus), Claude for Small Business plugin (pattern source: small named workflow set, owner-initiated approval gates, skills as reuse unit — map its 15 workflows against KH domains in RESEARCH). Rejections stand (nebula-graph posts, osiris, rowboat, html-anything, iii).

WS-14 — Memory: MemPalace stays for dev-workflow

Section titled “WS-14 — Memory: MemPalace stays for dev-workflow”

supermemory and memanto offer no adoption-grade benefit over MemPalace for the dev-workflow: supermemory’s MIT repo is the shell (engine closed; self-host = enterprise sales), memanto requires the proprietary Moorcheh cloud even when self-hosting the wrapper. MemPalace is local-first, already wired into session lifecycle (diary, wings, KG), and carries no data-exposure risk for dev-session content. Mine both for design patterns only — memanto’s typed memory categories + information-theoretic retrieval (arXiv:2604.22085) and supermemory’s temporal contradiction handling — as references for the post-launch platform user-memory direct-pattern build (ratified position unchanged).

B. Ledger anchors (post-rebase, 2026-06-10)

Section titled “B. Ledger anchors (post-rebase, 2026-06-10)”
  • ID-71 umbrella record + {71.1} RESEARCH (two-lane) + {71.5} done — live on id71-review (now rebased onto canonical-pipeline-setup).
  • Eval infrastructure = ID-104 (re-IDed from ID-102: canonical ID-102 “ledger id unification” was opened in parallel; theme-4 linked_tasks points at 104).
  • Pricing finding = bl-283 (re-filed from branch bl-278; canonical bl-278 differs; bl-280 fixed the key rename, VALUES remain stale).
  • {71.5} fixes live on canonical via ID-103.1 (947cc5808 + 418b659ce + b52bbebfd).
  1. /idea-refine working session with Liam on the headless-at-launch requirement (WS-4) — feeds {71.2} PRODUCT.
  2. Onboarding Task to be opened once {71.1} RESEARCH frames its scope (WS-6).
  3. Watchmen pilot + MCPJam/Workshop dev-workflow adoption — schedule after {71.1} lands (WS-13).