Platform Direction

Last verified: 05/08/2026 (DR-130 retrieval-axes bullet added — subject taxonomy is display-level metadata, driving axes are scope/semantics/concepts; prior: 28/07/2026 S504 R6 rescope — dispatch-brief claim dropped as unwired, entity glossary split to reference/entity-glossary.md; prior: 27/07/2026 post-ID-145 W1 cutover fold from docs PR #11 — procurement workspace stratum dropped, form_templates→form_instances / form_template_requirements→form_requirement_templates / form_template_fields→form_instance_fields renames, form_questions re-keyed to form_instance_id, q_a_pairs.source_workspace_id dropped; canonical PR #119. Prior: 22/07/2026 S491 — tier-1 refresh: docs-site paths corrected (docs/themes/… → initiatives/core-product/canonical-pipeline/…, docs/specs/ → specs/), Intent-adoption DR-089 plan-surface note added; prior: S462 DR-038 glossary revision — workspace tier removed from the containment chain, form = the procurement item/activity, ID-145 rework opened; S441 DR-025 evidence-binding, S391 canonical entity glossary)

Purpose: Strategy summary of the platform direction — mission, principles, v1 shape, and active workstreams. An agent reading this doc plus its spec dir understands the platform’s strategic direction. Canonical detail lives in initiatives/core-product/canonical-pipeline/intended-architecture/01-vision.md (docs-site); the canonical entity definitions live in reference/entity-glossary.md (split out S504, R6).

Mission

Canonical helps UK SMBs organise their data so AI agents — Claude in particular — can do meaningful work on their behalf: the blocker to SMB AI adoption is not the AI; it is the data. The knowledge base is the product; applications (procurement first, then sector intelligence, sales proposals, and more) consume the same canonical corpus through different application and workflow surfaces.

The inversion

Canonical is infrastructure, not a destination. Content flows to wherever Claude is operating (Word / Excel / PowerPoint, Claude Desktop, claude.ai, Cowork, Claude Code, headless agents); the Canonical web UI exists to govern, curate, and visualise the corpus.

Five guiding principles

One record, many views — every fact has one canonical home, presented at multiple depths through multiple surfaces; never a duplicate to keep in sync (the Wikipedia Principle).
Helping users organise, not extracting their value — per-tenant corpus, recorded provenance, no cross-tenant aggregation or model training.
Observe and intervene, not prevent and approve — free edits, versioned changes, post-hoc review; no write gatekeeper.
Programmatic where it can be, AI where it must be — deterministic code for deterministic work; AI reserved for classification, summarisation, extraction, drafting.
The library and the applications feed each other — application artefacts (won bids, vetted summaries) are curated back into the corpus; bid #20’s corpus beats bid #1’s.

v1 shape

Evidence bindings; canonical = client DB + OKF bundle (DR-025). Client sources are evidence streams with per-binding retention classes (keep-and-watch / ingest-once / live-connected / external-referenced); authority is earned at the knowledge-admission gate (record promotion + ontology linter), never inherited from a folder — promoted records change only via proposals (DR-026). v1’s primary binding is a controlled local file server (Canonical defines the organisation structure, content added ETL-style, changes picked up automatically); SharePoint / Notion-style connectors come later, gated on pipeline confidence earned with the first client as testbed (ID-71 WS-1, WS-6).
Applications as activities (DR-038). Six baseline application types (procurement, intelligence, sales_proposal, product_guide, competitor_research, training_onboarding), each realised as ACTIVITIES carrying their own ids (a form, a proposal, a guide, …) bound to an application_types row — one architectural pattern, not bespoke verticals. The earlier “each a workspace + satellite table” framing is retired (DR-038, S452): no new *_workspaces tables ever; structured data scopes to the activity.
AI-consumer-first surfaces. The primary user is Claude with Canonical connected: a remote MCP server (the single reusable core), plugins (Cowork + Claude Code), and per-domain skill files. Headless includes managed agents, not only MCP-completable tooling — MCP + Skills from Claude Desktop / claude.ai / Cowork is itself a headless-agent form (MCP = connector, Skill = expertise); connectivity, incoming and outgoing, is a first-class headless requirement (ID-71 WS-4).
Retrieval axes: scope, semantics, concept membership (DR-130). “Aboutness” is display-level derived metadata; nothing is driven by a platform-global subject vocabulary. Filtering is scope (scope_tag, DR-125); subject relevance is semantic ranking (embeddings + keywords + entity extraction — never an exclusion predicate); browsing and curation are concept membership (bundle topics, guides as curated clusters, DR-126). The per-document subject-classification stage and the platform-global domain/subtopic vocabulary are retired; a client-facing subject vocabulary, if ever needed, returns as an R6 client-overlay CV in the client bundle (display-only).

Core entity hierarchy

The canonical, schema-verified entity definitions (application_type, workspace [legacy], form, q_a_pair) and the containment chain live in reference/entity-glossary.md — reuse those definitions verbatim; do not restate them here.

AI-tooling direction (ID-71)

Outcome-first. Design the surface by working backwards from the most valuable client workflows; verdicts attach to outcomes, not tool names (concept-over-artefact).
Eval-everything. Every AI touchpoint is born-evaluable; ongoing feedback loops are the mechanism by which tooling earns expanded autonomy.
Progressive trust graduation. Agents propose, humans gate publication/outcome writes at launch; auto-apply is earned per-workflow on clear quality metrics, with an audit trail.

Active workstreams

Workstream	One-liner
Canonical pipeline implementation	The v1 spine; live ordering board is `initiatives/core-product/canonical-pipeline/reference/v1-closeout.md`.
ID-71 — AI-tooling surface umbrella	Defines approach, standards, and target shape for the whole AI-consumption layer (tools, resources, prompts, plugins, skills, apps, inline AI).
ID-104 — Eval infrastructure	The eval-everything substrate; graduation mechanism for trust/auto-apply.
ID-145 — Procurement form-first re-architecture	Retire the workspace umbrella from procurement UX per DR-038; first-domain production-readiness. W1 schema cutover shipped (S474 / canonical PR #119 — procurement workspace stratum dropped, `form_templates`→`form_instances` rename + `form_questions` re-key to `form_instance_id`). RESEARCH: `specs/id-145-procurement-form-first/RESEARCH.md`.

Specific use-case builds (e.g. renewal packs, sales triggers) graduate to their own Tasks with their own spec chains, scheduled by priority in logical groupings — ID-71 is the structuring task, not the delivery vehicle for every workflow it inventories (ID-71 WS-2).

How to use this doc (agents)

Read this alongside your initiative/project’s spec dir (specs/id-N-<slug>/, docs-site). This doc gives shared direction; the spec dir wins on any detail conflict. Treat WS-numbered decisions in specs/id-71-ai-tooling/lane-a-workshop-outcomes.md as settled input, not open questions.

Pointers

All paths are docs-site (src/content/docs/):

initiatives/core-product/canonical-pipeline/intended-architecture/01-vision.md — full vision, user model, application framing (canonical).
specs/id-71-ai-tooling/ — ID-71 spec dir (SYNTHESIS, lane-a workshop outcomes/feedback, research inputs).
initiatives/core-product/canonical-pipeline/reference/v1-closeout.md — V1 closeout / live forward map.
initiatives/core-product/canonical-pipeline/reference/v1-completion-sequence.md — Original V1 sequencing doc - historic context only / intent/decisions may have since changed; superseeded by v1-closeout.md
reference/entity-glossary.md — the canonical entity definitions (split from this doc, S504 R6).