Skip to content

ID-71 Lane A — Workflow inventory strawman (workshop draft, 2026-06-09)

ID-71 Lane A — Workflow inventory strawman

Section titled “ID-71 Lane A — Workflow inventory strawman”

Status: WORKSHOP STRAWMAN — this document proposes; it does not decide. Every verdict cell is deliberately empty; every assumption needing Liam’s validation is marked [VALIDATE]. Purpose: give Liam something concrete to react to in the Lane A workshop rather than blank paper.

Spine: SYNTHESIS.md §1.2 (ranked outcomes), §1.7 (onboarding thread), §2 (audit method). Extends: the s314 U1–U17 × A1–A15 use-case/affordance matrix (knowledge-hub-archive/research/s314-id75-usecase-affordances.md) and the four client personas (kh-client-content-archive/docs/reference/client-personas.md). Maps onto: Liam’s current tooling grouping (current-ai-tooling-grouping.md).

Unit of analysis: the concept/outcome, not the tool name — per the ratified method, “verdicts attach to outcomes, not to tool names” (SYNTHESIS §1.1).

Notation. Outcomes O1–O9 (= SYNTHESIS §1.2 ranks 1–8 + §1.7 onboarding as O9). Workflows W<outcome>.<n>. Personas: existing Sarah/James/Rachel/Tom + proposed Maya/David/Priya/Emma (§A). Use-cases U* and affordances A* follow s314 numbering; new ones continue the sequences (§C).


Same format as the existing four (job, goals, pains, behaviours, success metric), plus an explicit AI/MCP readiness line (the existing matrix’s “MCP/Claude” row).

SMB reality check [VALIDATE]: at Phew’s size (~9–11 people) these are likely hats, not heads — e.g. Sarah-the-founder may wear the Finance hat, James may wear the Sales hat. The workshop should decide whether these are four people, four hats, or some collapse (e.g. Sales + Customer Success as one “revenue owner”). The workflows in §B survive either answer; the surface grouping (§D) may not.

Persona 5: The Marketing Generalist — “Maya”

Section titled “Persona 5: The Marketing Generalist — “Maya””
  • Role: Marketing Manager / Communications Lead (often part-time or shared hat in an SMB) [VALIDATE: does this role exist as a distinct person at Phew?]
  • Job: turn what the company knows and what’s happening in the sector into credible, timely external content — blogs, social, email campaigns, webinar topics, case-study collateral.
  • Evidence base: U13 (Sector-Intelligence Brief §5.1 — filtered news as source material for blogs/social/campaigns/thought leadership; webinars reacting “to what’s happening in real time”); SYNTHESIS §1.8 (“no marketing… personas — despite those functions being the primary intelligence beneficiaries”); backlog #49 (marketing personas/prompts) absorbed into ID-71 per D5.
  • Goals: publish content that reacts to sector events within days, not weeks; reuse case studies and capability claims without re-verifying them each time; keep a pipeline of topics fed by the intelligence layer.
  • Pain points: sector signal lives in someone else’s feed-triage; case studies go stale silently; no way to know which claims are still safe to publish [VALIDATE: assumed pains — no direct client interview evidence].
  • Behaviours: weekly planning cadence + event-driven bursts; consumes summaries and topic tags, not raw articles; drafts in external tools, wants source material handed over cited.
  • AI/MCP readiness: high-willing, low-ceremony — natural fit for prompt-driven workflows (“draft me a post about X, cited”) in Claude; unlikely to learn tool names. Plausible early consumer of headless digest→draft automation [VALIDATE].
  • Success metric (strawman): “When something happens in our sector, I can ship a credible, source-linked piece about it within 48 hours, without chasing anyone for the facts.” [VALIDATE]

Persona 6: The Seller / Account Manager — “David”

Section titled “Persona 6: The Seller / Account Manager — “David””
  • Role: Sales Lead / Account Manager (in many SMBs: the founder or a senior consultant wearing the hat) [VALIDATE]
  • Job: spot and act on buying triggers, research prospects/accounts, get proposals out fast, defend pricing.
  • Evidence base: U8 (Brief §5.2 — MAT mergers/appointments/audits, legislation triggers, “with the new KCSIE requirements coming in September”, retention sharing); U9 (AccountSnapshot / Account Brief MCP App — sales-proposals plan arm-a Phase 6); U10 (competitive-positioning sections, comparison matrix justifying per-line price differentials); SYNTHESIS §1.2 outcome 5 (“the consumption half is underserved; no marketing/sales tooling or personas exist”).
  • Goals: open conversations with timely, specific hooks; walk into any account conversation with a one-page brief; turn a qualified opportunity into a sent proposal in days.
  • Pain points: triggers arrive as noise or not at all; account research is manual re-googling; proposal assembly means scavenging old documents; competitor claims go unanswered [VALIDATE: assumed pains].
  • Behaviours: opportunistic, interrupt-driven; lives in email/CRM, not in knowledge tools; will use whatever produces the document fastest.
  • AI/MCP readiness: outcome-hungry, process-averse — the strongest candidate for the “just ask” posture and for headless agents that watch signal and push (trigger alerts, draft briefs) rather than waiting to be asked [VALIDATE].
  • Success metric (strawman): “I hear about a trigger event in my accounts before my competitors do, and I can send a relevant, accurate proposal or note the same week.” [VALIDATE]

Persona 7: The Finance / Commercial Controller — “Priya”

Section titled “Persona 7: The Finance / Commercial Controller — “Priya””
  • Role: Finance Manager / Commercial Lead (SMB: often the founder or an operations person with the commercial hat) [VALIDATE: weakest-evidenced persona — confirm a real counterpart exists before investing]
  • Job: make sure the numbers in client-facing documents are right and defensible — pricing tiers, ROI claims, day rates — and that commercial commitments (T&Cs, certifications backing framework eligibility) are current.
  • Evidence base: SYNTHESIS §1.8 names finance as a missing persona; the sales-proposals plan gives the function a concrete surface (pricing configurator, ROI calculator, QA gate numerics tolerance ±0.5% — arm-a T14/T23/Q9); U14 (Brief §5.3 — legislation + audit requirements inform pricing/roadmap); expiring certifications (gap-analysis trio; get_certification_status).
  • Goals: one source of truth for rates/tiers/ROI assumptions; no proposal leaves with numbers she hasn’t blessed; early warning on anything expiring that revenue depends on.
  • Pain points: pricing lives in spreadsheets-of-spreadsheets; ROI claims in old proposals are uncheckable; finds out about expired certs from a failed bid [VALIDATE].
  • Behaviours: periodic + gate-keeping; reviews rather than authors; wants audit trails and version lineage, not chat.
  • AI/MCP readiness: cautious-systematic (Rachel-like) — will trust AI that shows its checks (QA gate runs, fact-trace) and distrust AI that drafts numbers. Likely a verifier of agent output, not an agent driver [VALIDATE].
  • Success metric (strawman): “No client-facing document goes out with a number, rate, or compliance claim I can’t trace to a current, approved source.” [VALIDATE]

Persona 8: The Customer-Success / Renewals Owner — “Emma”

Section titled “Persona 8: The Customer-Success / Renewals Owner — “Emma””
  • Role: Account/Delivery Lead who owns retention and renewals (SMB: usually the delivery consultant closest to the client) [VALIDATE]
  • Job: keep existing clients, renew them, and grow them — which means assembling the evidence of value delivered (renewal packs) and spotting risk/opportunity signals in their sector.
  • Evidence base: SYNTHESIS §1.2 outcome 2 (“proposals now, renewal packs later” — Matthew’s “output engine, not reference library”); §1.8 (“Renewal packs imply an unpersonified customer-success user”); U8 retention sharing (“share relevant sector intelligence with existing clients”); case-study push as a client-promised capability (§1.4 unbuilt surface).
  • Goals: never start a renewal from a blank page; show clients sector-aware value (“here’s what’s changing for you and what we did about it”); convert completed work into case studies while it’s fresh.
  • Pain points: value evidence is scattered across delivery artefacts; renewal packs are rebuilt by hand each time; case studies never get written [VALIDATE].
  • Behaviours: cyclical (renewal calendar) + relationship-driven; consumes briefings about her clients’ world, not the company’s.
  • AI/MCP readiness: moderate — would adopt an assembled-for-me pack and a per-account briefing; natural beneficiary of scheduled headless runs keyed to the renewal calendar [VALIDATE].
  • Success metric (strawman): “Sixty days before any renewal, I have a client-specific pack of evidence, outcomes, and sector context that’s accurate without me assembling it.” [VALIDATE]

Extended persona matrix (strawman row additions)

Section titled “Extended persona matrix (strawman row additions)”
DimensionMaya (Marketing)David (Sales/AM)Priya (Finance)Emma (CS/Renewals)
FrequencyWeekly + event burstsInterrupt-drivenPeriodic / gatingRenewal-calendar cyclical
Primary actionSource, draft, repurposeSpot trigger, brief, proposeVerify, approve numbersAssemble, evidence, renew
KB roleViewer/EditorViewer (+ proposal author)Viewer/ReviewerViewer/Editor
AI/MCPHigh-willing, low-ceremonyOutcome-hungry; push > pullCautious; verifierModerate; scheduled packs
Key metricTime-to-credible-contentTrigger-to-touch speedTraceability of numbersPack readiness
Risk if unsatisfiedSignal wastedRevenue left on tableWrong numbers shipSilent churn

All cells [VALIDATE] — especially KB role mappings, which interact with RLS roles.


For each ranked outcome: concrete workflows with actor, trigger, outcome-level steps, data objects, and the two required variants. HvC = human-via-Claude (Claude Desktop/Claude.ai, may use skills/prompts/apps). HA = headless agent (MCP-only — no skill layer, no UI; SYNTHESIS §1.3 “headless agents are surface #4”).

Standing strawman rule for all HA variants [VALIDATE]: headless agents may read anything their RLS role allows and may propose writes (draft, queue, flag), but publication-status changes and outcome-affecting writes stay human-gated — mirroring the onboarding doctrine “proactive but never automatic.” Workshop Q5 challenges this rule directly.

O1 — Answer this question well, with citations I trust, fast

Section titled “O1 — Answer this question well, with citations I trust, fast”

(James’s <30s metric; universal A4 provenance; confidence postures.)

  • W1.1 Cited knowledge answer. Actor: any (James daily; Tom cold-start). Trigger: a question mid-task. Steps: ask → two-step retrieval (metadata preview → verbatim fetch on accept) → answer with citations + confidence posture. Data: content_items, chunks/embeddings, citations, q_a_pairs. HvC: conversational; Search Strategy / Knowledge Synthesis skill behaviour folds into how Claude searches. HA: an agent mid-pipeline (e.g. proposal assembly) issues the same retrieval calls; citations must survive into its structured output without a skill telling it to.
  • W1.2 Prior-answer match for a new question. Actor: James. Trigger: new bid/form question. Steps: question in → question_matches ranked candidates → preview → verbatim fetch → cite with version-on-cite. Data: q_a_pairs (corpus-level, scope_tag), question_matches, citations. HvC: inside composer or Claude (“have we answered this before?”). HA: batch agent pre-matches every question in a newly ingested form and stages candidates for human review.
  • W1.3 Entity/ontology-grounded answer. Actor: any; David for accounts. Trigger: “who/what do we know about X?” Steps: resolve entity → traverse relationships → compose grounded, cited answer. Data: entities/entity_mentions, ontology CVs, content_items. HvC: conversational with follow-ups. HA: account-research agent builds an AccountSnapshot from the same calls (U9). Note: ontology grounding is a Liam note (notes §“Ontology”) with Lane B mechanics — this workflow is the Lane A placeholder for it.

(Output engine, not reference library. Proposals now, renewal packs later.)

  • W2.1 Draft bid response, question by question. Actor: James. Trigger: live procurement workspace in in_progress/in_review (10-state workflow, procurement PRODUCT B-5). Steps: open question → matches → select/adapt → draft with posture → cite → mark question status. Data: procurement workspace + satellite, bid_questions/form_responses, q_a_pairs, citations. HvC: the composer conversation; /kb:draft-response-shaped entry. HA: agent drafts all low-risk/high-confidence questions overnight, leaves “Needs SME” postures for humans; never ships.
  • W2.2 Assemble a sales proposal end-to-end. Actor: David (+ Priya gate). Trigger: qualified opportunity. Steps: intake/account research → template → select case studies + quotes → configure pricing → compute ROI → assemble draft → QA gate → export DOCX. Data: proposal tables (7, per arm-a), content_items (case_study), pricing tiers, QA-gate runs. HvC: proposal_shortcut prompt + conversational assembly. HA: proposal.* tool chain is explicitly designed MCP-first (arm-a T3/T9/T14/T18/T24/T25) — agent assembles to draft + QA report; export/send human-gated. Status: unratified twin-arm draft — direction, not commitment.
  • W2.3 Assemble a renewal pack. Actor: Emma. Trigger: renewal date −60 days [VALIDATE: cadence]. Steps: gather delivery evidence + case studies + sector context for that client → assemble pack → review → send. Data: content_items, intelligence archive (client-sector scoped), proposal/pricing history. HvC: “build me the renewal pack for ”. HA: calendar-triggered agent pre-assembles; flags evidence gaps to Emma. Entirely unspecced — strongest candidate for a new workflow family inside O2 [VALIDATE: is this v1-adjacent or later?]
  • W2.4 Auto-fill a standard questionnaire/template. Actor: James. Trigger: recurring framework/security questionnaire. Steps: template coverage check → gaps list → fill from corpus → human completes residue. Data: templates, template coverage/gaps, q_a_pairs. HvC: conversational fill. HA: agent fills and stages; the “completing-forms generalisation” question (Liam’s note on the Bid Writing skill) lives here.

O3 — Keep knowledge trustworthy with minimal effort

Section titled “O3 — Keep knowledge trustworthy with minimal effort”

(Fact-check-everywhere, feature-ingest with supersession, case-study push, document control — all client-promised, all unbuilt.)

  • W3.1 Fact-check a claim/item on demand. Actor: Rachel; Maya pre-publish; Priya for numbers. Trigger: about-to-use or scheduled sweep. Steps: extract claims → trace each to current sources → verdict per claim → flag/fix. Data: content_items, source_documents, citations, version lineage. HvC: “fact-check this before I send it.” HA: nightly sweep over high-traffic items; files flags, never edits. Unbuilt promise; spec-pending as MCP prompt.
  • W3.2 Feature-ingest with supersession. Actor: Rachel/editor. Trigger: new product/feature doc arrives. Steps: ingest → detect superseded items → propose supersession set → human confirms → supersede_content_item. Data: content_items, supersession links, review queue. HvC: guided supersession conversation. HA: pipeline-triggered agent proposes the supersession set as a review batch. Unbuilt promise.
  • W3.3 Case-study push. Actor: Emma/delivery → Rachel review. Trigger: project completion. Steps: harvest delivery artefacts → draft case study → review → publish → available to Maya/David/W2.x selectors. Data: content_items (case_study), provenance. HvC: prompted drafting. HA: completion-triggered agent drafts and queues. Unbuilt promise.
  • W3.4 Document control loop. Actor: Rachel. Trigger: scheduled review / governance queue. Steps: review queue → diff versions → approve/flag → assign owners → governance status. Data: review queue, source_documents versions/diffs, governance queue, ownership. HvC: conversational triage (“what needs review this week?”). HA: agent pre-sorts the queue, attaches diffs + change summaries; decisions stay human.
  • W3.5 The bid-feedback flywheel (UC5+UC6+UC8). Actor: James ships → Rachel curates. Trigger: bid reaches terminal state. Steps: shipped responses → promote to Q&A corpus (lost-bid default skip) → revise stale pairs → dedup/merge. Data: form_responses, q_a_pairs, dedup candidates. HvC: post-bid promotion conversation. HA: agent stages promotion candidates with dedup pre-flags; promotion confirm is human. This is the load-bearing v1 data-quality loop (procurement PRODUCT B-20).
  • W3.6 Q&A .docx import. Actor: Rachel/admin. Trigger: supplier/legacy Q&A document. Steps: presign → upload → analyse (Track Changes/draft-final/dedup pre-flight choices) → import to corpus. Data: q_a_pairs, import staging. HvC: guided import. HA: limited — file-acquisition is the constraint; becomes fully headless only once source-connection (O9) exists. [VALIDATE]
  • W4.1 Personal “what needs me” briefing. Actor: Sarah weekly; all roles. Trigger: start of day/week. Steps: assemble assignments + attention items + active work + changes since last visit → ranked brief. Data: dashboard summary, assignments, change reports, workspaces. HvC: /kb:briefing-shaped; one ask. HA: scheduled agent posts the brief to email/Slack — the purest headless-consumption workflow. [VALIDATE: delivery channel ambition]
  • W4.2 Sector briefing / digest. Actor: Sarah, David, Emma (per-client scope), Maya. Trigger: weekly or on-demand. Steps: intelligence summary → notable items with citations → so-what framing per persona. Data: intelligence archive, feed_articles (passed), summaries, topic tags. HvC: /kb:sector-briefing, Intelligence Feed app for density. HA: scheduled digest; re-syndication (U3) is its publish-side sibling.
  • W4.3 Re-orientation after absence. Actor: Tom (1–2×/month), anyone post-holiday. Trigger: returning cold. Steps: “what changed since I was last here” → personalised re-entry. Data: read-marks, change reports, reorientation payload. HvC: Reorient Me app / conversational. HA: n/a as consumption (inherently human-facing); agent variant = pre-computing the payload.

O5 — Turn sector/competitor signal into action

Section titled “O5 — Turn sector/competitor signal into action”

(The consumption half is underserved; no marketing/sales tooling or personas exist — SYNTHESIS §1.2.5. §A personas Maya/David are the owners this family was missing.)

  • W5.1 Intelligence triage + filter feedback. Actor: Rachel/coordinator. Trigger: poll cycle completes. Steps: review passed articles → flag FP/FN → refine filter prompts → metrics. Data: feed_articles (passed AND filtered), flags, prompt versions. HvC: triage conversation or Intelligence Feed app. HA: agent pre-clusters and suggests flags; filter-prompt changes human-gated.
  • W5.2 Sales trigger → outreach draft. Actor: David. Trigger: trigger-shaped intelligence item (legislation date, MAT merger, audit, key hire). Steps: detect trigger → match to accounts/prospects → draft outreach hook with citation → David sends. Data: intelligence items, entity_mentions, account/prospect records [VALIDATE: where do accounts live — CRM integration or KB entities?]. HvC: “anything in this week’s intel I should act on?” HA: standing watch-agent pushes trigger+draft pairs. No tooling serves this today.
  • W5.3 Marketing content pipeline. Actor: Maya. Trigger: weekly planning or event burst. Steps: candidate topics from passed intel → select → cited source pack → draft (blog/social/email) → human edit/publish. Data: intelligence archive, summaries, topic tags, case studies. HvC: topic-to-draft conversation. HA: agent maintains a rolling “content opportunities” queue. U13 — named, never specced; no tooling.
  • W5.4 Product/roadmap signal. Actor: Sarah. Trigger: monthly/quarterly review. Steps: aggregate legislation/audit/competitor signal → implications summary → roadmap notes. Data: intelligence archive, entity records. HvC: on-demand synthesis. HA: quarterly digest agent. U14 — unowned; lowest urgency in this family [VALIDATE].
  • W5.5 Competitor record over time. Actor: David/Maya; feeds W2.2 positioning. Trigger: continuous accretion; consulted at proposal time. Steps: competitor entities accrete mentions → structured record → comparison matrix on demand. Data: entities, entity_mentions, competitor_research workspace (reserved seat). HvC: “what’s been doing this quarter?” HA: the accretion side is already pipeline-shaped; matrix generation on demand. (U12/U17/U10.)
  • W5.6 Re-syndicate to intranet RSS. Actor: system (Rachel configures). Trigger: items pass relevance. Steps: format (title/source/date/summary/tags) → publish to feed routes. Data: feed_articles, output feeds. HvC: n/a (configuration only). HA: fully headless already — the existing proof that headless consumption works. (U3.)
  • W6.1 Coverage-gap review. Actor: Rachel; Sarah summary view. Trigger: weekly/pre-bid. Steps: coverage by domain/template → gaps ranked → creation suggestions → assign. Data: coverage matrix, gaps, taxonomy. HvC: /kb:coverage + Coverage Matrix app for density. HA: agent files gap-creation suggestions into the review queue.
  • W6.2 Freshness/expiry sweep. Actor: Rachel; Priya for certs. Trigger: scheduled. Steps: expiring content + stale items + certification status → ranked exposure list → renew/supersede/retire actions. Data: freshness report, expiring content, certification records. HvC: “what’s about to expire?” HA: scheduled sweep with escalation thresholds — natural headless candidate.
  • W6.3 Quality actions briefing. Actor: Rachel. Trigger: weekly. Steps: quality summary → prioritised actions → execute/assign. Data: quality signals/audits. HvC/HA: as W6.1. Currently three tools + audit_content — the quality cluster overlap (§D) concentrates here: is this one outcome or three?

O7 — Find and verify a specific thing in under 2 minutes, cold-start

Section titled “O7 — Find and verify a specific thing in under 2 minutes, cold-start”
  • W7.1 Tom’s cold-start lookup. Actor: Tom. Trigger: a colleague asks him to check something. Steps: natural-language search (no taxonomy knowledge assumed) → item → provenance/version check → answer with confidence. Data: content_items, source_documents, versions. HvC: plain question in Claude — the test case for “you don’t need to remember the tools — just ask”. HA: n/a as a human workflow; the same calls underpin every agent’s verification step.
  • W7.2 “What do we claim about my specialism?” Actor: Tom. Trigger: periodic pride/risk check. Steps: gather claims citing his domain → review → flag corrections (without becoming a content manager). Data: content_items by domain/entity, citations. HvC: conversational audit. HA: agent compiles the claim sheet; corrections route to W3.4.
  • W8.1 Build/refresh a guide section. Actor: Rachel/editor; Matthew-shaped product owner [VALIDATE: who owns guides at the client?]. Trigger: new guide, section misalignment, new content. Steps: section spec (27-section layout) → resolve content by subtopic_filter + expected_layer → draft/refresh → review. Data: guide_sections, content_items, taxonomy layers. HvC: Guide Builder skill behaviour, conversational. HA: agent flags sections whose resolved content changed; regeneration proposals human-gated.
  • W8.2 Research Feed currency. Actor: system → Rachel review. Trigger: research- layer content arrives in guide domain. Steps: aggregate into trailing Research Feed section (display_order 27 guarantee) → surfaces in guide. Data: research-layer content_items, guide research-feed rows. HvC: review only. HA: already the design — pipeline-fed.
  • W8.3 Guide coverage check. Actor: Rachel/Sarah. Trigger: monthly. Steps: per-guide coverage vs sections (“strong KCSIE coverage, nothing on MAT mergers”) → gap list → feeds W6.1/W5.x. Data: guide sections, coverage, intelligence topics. HvC: on-demand. HA: scheduled report.
  • W8.4 Sales-argument quality pass (“IMPACT of If Not Now”, dual-tier). Actor: editor + David as consumer. Trigger: pre-client-use. Steps: check argument sections present + sharp → propose strengthening from evidence. Data: guide sections, case studies, intelligence. HvC: guided critique. HA: lint-like agent check producing findings, not edits. [VALIDATE: is argument-quality checking wanted as tooling, or is this purely editorial craft?]

O9 — Onboarding / day-one (the §1.7 family)

Section titled “O9 — Onboarding / day-one (the §1.7 family)”

(Currently served by NOTHING in the 58-tool surface — the strongest new-capability candidate. Under-4-hours vs Loopio’s 2–4 weeks is where the “this is different” judgement forms.)

  • W9.1 Tenant bootstrap + programmatic enrichment. Actor: coordinator (Sarah-or- Rachel-shaped). Trigger: first login. Steps: Companies House auto-populate (name/registration/directors/SIC) → SIC-derived sector context primes classification. Data: company profile, taxonomy priors. HvC: confirmation conversation. HA: fully programmatic — no AI needed (historic doc’s own framing); the enrichment hook is the reusable concept.
  • W9.2 Connect sources (upload as fallback). Actor: coordinator. Trigger: hour 0–1. Steps: “tell us where your documents live” → connect SharePoint/Drive/email → or drag-and-drop → pipeline treats both identically. Data: source connections, source_documents. HvC: guided connection. HA: is the external-folder-as-canonical-store model the cocoindex pipeline now implements — the historic vision maps onto current architecture better than onto its original one (SYNTHESIS §1.7). No source-connection tooling exists on the MCP surface.
  • W9.3 Discovery → extract → interpret → propose. Actor: system. Trigger: sources connected. Steps: broad discovery (“things that look like past proposals / certs / case studies”) → programmatic extraction → agentic interpretation (Q&A structures, lifecycle types, expiry dates, duplicate flags) → proposal batch with provenance. Data: source_documents, staged proposals, dedup flags. HvC: progress narration + early-question handling. HA: the content- gathering agent in onboarding mode — the headless variant IS the primary variant.
  • W9.4 Bulk review (parse → propose → confirm). Actor: coordinator. Trigger: proposal batch ready. Steps: grouped proposals → bulk-accept high-confidence → quick-review medium → resolve duplicates → flag missed folders → re-run targeted. Data: staged proposals → content_items/q_a_pairs. HvC: the review conversation; bulk actions. HA: never — this gate is the trust moment; “proactive but never automatic.”
  • W9.5 First bid on a partial library. Actor: James/coordinator. Trigger: tender docs arrive (independent of library completeness). Steps: ingest tender → brief + familiarity signal honest to library state (“limited library content…”) → W2.1 with more No-Content/Needs-SME postures → completed answers feed back via W3.5. Data: procurement workspace, library-state signal. HvC: primary. HA: pre-processing only. The flywheel bootstraps through use.
  • W9.6 Monitoring mode (the same skill, re-pointed). Actor: system → coordinator confirms. Trigger: new/changed document in a connected source. Steps: detect → propose entry or update (e.g. renewed cert PDF → update expiry on the date-bound item) → notify → confirm. Data: source deltas, staged proposals. HvC: notification review. HA: the steady-state headless workflow; closes the loop with W6.2 and W3.2.

The s314 matrix scoped to URL/RSS-sourced data. Lane A re-scopes it to all knowledge artefacts across all six application types + cross-workspace loops (SYNTHESIS §3 Lane A). Existing U1–U17 rows and A1–A15 columns carry over unchanged; re-validate ●/○ cells against the wider scope rather than re-deriving.

New use-case rows (and owners for the orphans)

Section titled “New use-case rows (and owners for the orphans)”
#Use-caseProposed owner personaWorkflow familyNotes
U13 (existing, unowned)Marketing content creationMayaW5.3s314 T6 flagged “no affordance owner” — resolved by persona
U15 (existing, unowned)General researchTom + future research workspace; any persona as secondaryW1.xOwner is a workspace, not a person [VALIDATE]
U16 (existing, unowned)Sentiment understandingMaya/David (proposed)W5.xStill no data home (s314 T6); propose: keep on matrix, mark “no affordance until data home exists” [VALIDATE: park or pursue?]
U18Day-one corpus bootstrap (connect → discover → propose → confirm)Coordinator (Sarah/Rachel)W9.1–W9.5The §1.7 family as first-class matrix rows
U19Ongoing source monitoring / change detectionRachel (confirm), system (detect)W9.6Distinct from U18: different volume, cadence, trust posture
U20Revenue-document assembly (proposal, renewal pack, questionnaire)David, Emma, JamesW2.1–W2.4Generalises beyond URL-sourced data — the output-engine row
U21Trust maintenance (fact-check, supersession, case-study push)Rachel, PriyaW3.1–W3.3Client-promised, unbuilt — needs matrix presence so affordances get designed in
U22Briefing / reorientationSarah, allW4.1–W4.3Cross-cutting consumption
U23Sales-trigger detection → outreachDavidW5.2Split from U8 (intent) to name the detection+matching capability
#AffordanceWhy the existing 15 don’t cover itPrimary rows
A16Source connection + enumeration (connect a store, list/walk it, detect deltas)A14 dedups records; nothing models the upstream source itselfU18, U19
A17Fact-trace / claim-level verification (claim → current-source verdict)A4 cites provenance of a record; A17 verifies claims inside content against live sourcesU21, U20
A18Assembly + export (multi-item composition, templates, DOCX/PDF, QA gate)Matrix is retrieval-shaped; the output engine needs composition affordancesU20, U13
A19Confidence-posture signalling (per-answer honesty: strong/partial/no-content/needs-SME)Implicit in platform doctrine, absent from matrixU20, U22, W1.x rows
A20Supersession / version lineage (this replaces that; what changed between versions)A14 is identity-dedup, not lifecycle successionU21, U19
A21Ontology grounding (CV-validated values, entity-anchored responses)A9 extracts mentions; A21 constrains and grounds outputsAll answer/assembly rows
A22Batch propose → human confirm (staged proposals, bulk accept, audit of decisions)A11’s flag loop is per-article scoring feedback; A22 is a general write-gating patternU18, U19, U21
A23Scheduled/triggered delivery (digest schedules, watch-triggers, push channels)Matrix assumes pull; half of §B’s HA variants are pushU22, U23, U19

Strawman claim to test in workshop: A16, A18, and A22 are the three affordances whose absence explains most of §D’s outcome-level gaps. If Liam agrees, they become the spine of the “additions” wave in {71.4} PLAN.


D. First-cut surface mapping (verdicts EMPTY — workshop fills them)

Section titled “D. First-cut surface mapping (verdicts EMPTY — workshop fills them)”

Liam’s six groups (current-ai-tooling-grouping.md) mapped onto §B. Concept level — tool names appear only to locate overlaps the S309 pass flagged. Verdict column is deliberately empty: keep-concept / refine / retire / gap-fill attaches per row in the workshop.

GroupWorkflows servedOverlap concentration (S309-flagged)Adjacent outcome-level gapsVerdict
Search & discovery (5 tools, 2 skills, 1 cmd)W1.1–W1.3, W7.1–W7.2; substrate for nearly every HA variantSearch trio (search_knowledge_base / search_qa_library / search_content_chunks) + find_similar_items — four entry points for one “find me…” outcome; duplicate-detection overlaps Content mgmt’s pairOntology-grounded answering (W1.3) has no deliberate affordance; entity search is in the wrong group (see Content mgmt)
Dashboard & orientation (5 tools, 1 app, 2 cmds)W4.1–W4.3; partial W6.2Freshness/expiring pair (get_expiring_content / get_freshness_report) sits here while quality/staleness siblings sit in Content mgmt — one exposure outcome split across two groupsPush delivery (A23): every briefing is pull-only today; no scheduled/channel delivery
Procurement (8 tools, 1 app, 1 skill, 3 cmds)W2.1, W2.4, W1.2; W3.5 entryTemplate trio (list_templates / coverage / gaps) vs Coverage Matrix overlap; naming drift now fresh against renamed DB (SYNTHESIS §1.4)Forms-generalisation: “completing-forms” concept vs bid-specific skill (Liam’s own note); promotion (UC5) has no dedicated surface
Content management (29 tools, 1 app, 3 skills, 2 cmds)W3.1–W3.6 (partially), W6.1–W6.3, W8 substrateThe densest group — quality cluster (get_quality_actions / _briefing / _summary + audit_content); single-vs-batch pairs (get_content_item/get_content_items, assign_content_owner/bulk_assign_owner); dup trio (find_duplicate_candidatesfind_all_duplicates + import dedup); review vs governance queues (two queues, one “needs attention” concept?)The three client-promised trust workflows (W3.1 fact-check, W3.2 feature-ingest, W3.3 case-study push) are all UNSERVED despite this being the largest group — volume ≠ coverage
Intelligence (2 tools, 1 app)W4.2, W5.1 (thin), W5.6 (off-MCP)None — opposite problem: 2 tools against the U1–U6 demand setThe whole consumption half of O5: W5.2 sales triggers, W5.3 marketing pipeline, W5.4 roadmap signal, W5.5 competitor matrix — no tooling, no prompts, no personas (until §A)
Product guides (4 tools, 1 skill)W8.1–W8.3None flaggedW8.4 argument-quality; guide↔intelligence coverage loop (W8.3→W6.1) is manual
(No group)W9.1–W9.6 — the entire onboarding family; W2.2/W2.3 assembly+exportO9 has zero tooling (SYNTHESIS §1.7: “no onboarding/source-connection/discovery tooling at all”); O2 beyond the bid composer (proposal assembly, renewal packs, export) is design-only

Cross-group observations for the workshop (not verdicts):

  1. The 58 tools concentrate in curation (Content mgmt = half the surface); the ranked outcomes concentrate in consumption and output (O1, O2, O4, O5). The surface is inverted relative to the outcome ranking.
  2. Every S309 overlap cluster is a candidate for ONE outcome-shaped entry point with parameters (find / what-needs-attention / duplicates / get-one-or-many) — which is also the main route back under the ~30–40 ceiling without losing capability.
  3. The two biggest gaps (O9 onboarding, O5 consumption) are also the two biggest differentiation claims (under-4-hours; signal-to-action). Gap-filling here likely outranks consolidation in client-visible value — sequencing question for Liam.

E. Workshop agenda — ten questions, ordered

Section titled “E. Workshop agenda — ten questions, ordered”
  1. Outcome ranking sanity-check. Does the §1.2 ranking still hold as the design spine — specifically O2 (revenue documents) above O3 (trust maintenance)? And do renewal packs (W2.3) enter ID-71’s horizon, or stay explicitly future?
  2. Personas: people or hats? At Phew’s size, who actually is Maya/David/Priya/ Emma? Should any collapse (e.g. David+Emma as one revenue owner)? Which of the [VALIDATE] success metrics would the real counterparts recognise?
  3. The headless-complete set. Which workflows MUST be 100% MCP-completable at launch (the surface-#4 guarantee)? Strawman: all of O1/O4/O6 reads + W5.6 + W9.3; none of the publication gates.
  4. Agent write discipline. Is the standing rule in §B (agents read and propose; humans gate publication/outcome writes) the policy — or are there workflows (W6.2 expiry escalation? W9.6 cert-date updates?) where auto-apply is acceptable?
  5. Onboarding’s home (decision D4). Does O9 graduate to its own Task now, with ID-71 only reserving the surface concepts (A16 source-connection, A22 propose-confirm) — or does Lane A spec it fully? And which connector is first: SharePoint, Drive, email, or local-upload-only?
  6. One search or four? Is a single outcome-shaped “find” entry point (type/scope/ granularity as parameters) the target for the search trio + similar-items — and does any live Phew usage argue for keeping separate entries?
  7. What-needs-attention consolidation. Quality cluster + freshness pair + review queue + governance queue + coverage gaps: how many distinct outcomes does Liam see here? (Strawman: two — “where are we exposed” and “what’s in my queue”.)
  8. Forms over bids. Confirm the generalisation: completing-forms as the concept (procurement = first form type), per your own grouping note — and does W2.4 questionnaire-fill fold into it?
  9. O5 sequencing. Of the unserved consumption workflows — W5.2 sales triggers, W5.3 marketing pipeline, W5.4 roadmap signal — which one is the client-evidenced first build, and is there appetite to spec it inside ID-71 vs a new Task?
  10. Ceiling strategy. Given §D’s inversion finding: do we get under ~40 tools by consolidating curation into outcome-shaped entries on ONE server, or split servers by audience (consumption vs curation/admin) per the ratified “split rather than defer-load” constraint?

End of strawman. Nothing above is decided.