ID-71 Lane A — Workshop outcomes (ratification record, 2026-06-10)
ID-71 Lane A — Workshop outcomes
Section titled “ID-71 Lane A — Workshop outcomes”Status: RATIFIED decision record. Distils
lane-a-workshop-feedback.md(Liam, 2026-06-10) againstresearch-inputs/lane-a-workflow-inventory-strawman.mdplus 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.
A. Decisions (WS-1 … WS-14)
Section titled “A. Decisions (WS-1 … WS-14)”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-refineworking 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 onid71-review(now rebased ontocanonical-pipeline-setup). - Eval infrastructure = ID-104 (re-IDed from ID-102: canonical ID-102 “ledger id
unification” was opened in parallel; theme-4
linked_taskspoints 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).
C. Queued follow-ups
Section titled “C. Queued follow-ups”/idea-refineworking session with Liam on the headless-at-launch requirement (WS-4) — feeds{71.2}PRODUCT.- Onboarding Task to be opened once
{71.1}RESEARCH frames its scope (WS-6). - Watchmen pilot + MCPJam/Workshop dev-workflow adoption — schedule after
{71.1}lands (WS-13).