Class: ALIGNMENT — this document describes the repository. It never defines architecture.
Where it disagrees with
00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md, the
disagreement is a gap to close in code.

Part I maps the nine planes to real code. Part II is the ranked gap register.

Canon §28 sets the standard this document is held to:

Readiness must be evidence-based across at least: implemented, wired, deployed and verified
end-to-end. Presence of code or a Wrangler manifest is not proof of production readiness.

That is why several entries below downgrade a finding from "broken" to "dead" or "unwired" — and
why one stays Not verified rather than being closed on inference.

Describes commit: b60d21ec0effbf9e382c801727ce233703625ede (main)
Surveyed: 2026-09-04 · re-verification of G-17–G-22 plus a new-structure survey across
services/ (39), packages/ (56) and sql-migrations/. Code is byte-identical to the
2026-09-03 survey base (22013618); the commits in between are canonical-documentation only.
Method: every claim below was checked by reading the file it names. Claims that could not be
closed by reading code are marked Not verified rather than inferred.

---

Verdicts on the drifts named in the Founder Canon

The canon's drift list was written against the Aug 1 freeze. The tree has since moved past one of
its four items, so each was re-checked rather than carried forward.

ADK middleware is a governance bypass — confirmed, but it was orphaned

Status: RESOLVED (deleted 2026-08-31).

The canon's description was accurate: services/gateway/src/adk-middleware.ts fabricated a
Capability with requiresApproval: false hardcoded (line 108) and dispatched straight to a
runtime (lines 114–128) with no Governance call, no Hermes and no authority check in 362 lines.

But it was dead code — nothing imported it outside its own test, and it was absent from the
Gateway's index.ts and runtime-wiring.ts. It was a latent bypass waiting to be wired by
someone who assumed it worked, not an active hole.

The correct action was therefore deletion, not redesign. The file and its test were removed; no
dangling references remain.

Hermes n8n-first orchestration and spine.write — already fixed

services/hermes/src/orchestrator.ts:130–139 rejects both spine.write and http.request with
ungovernedNodeError, and states the canon's own reasoning in the comment: a Spine write from an
orchestration node bypasses Pipeline promotion; an arbitrary HTTP node bypasses capability
resolution and Governance. The n8n-first path is gone from the orchestrator.

Loose end: the string n8n still appears in services/hermes/src/types.ts and index.ts.
Probably inert handoff-adapter typing, but unread — it should be removed or explicitly scoped so
the next audit does not re-flag it.

Capability Fabric → Governance → Hermes — correctly built

Not a drift. This is the strongest part of the codebase and matches the canon's authority boundary
precisely.

• services/capability/src/index.ts:51 — "Descriptive catalogue only. Resolution, governance and
  approval happen in the Governance service."
• services/govern/src/index.ts — owns /v1/capability/prepare, /v1/approvals,
  /v1/authority/{decisions, approvals/consume, idempotency/claim, reconciliations}
• services/hermes/src/authority.ts:2 — "Hermes reads its authority from Governance, never from
  itself." Line 115 fails closed: a Governance outage is refused rather than read as
  "not replayed."
• services/gateway/src/workbench-capabilities.ts:928,462 — plans are prepared and signed before
  reaching an approval surface; status pending_approval.

Per canon §5, this separation should not be redesigned.

MCP Pool staying out of the core data path — NOT VERIFIED

The shape is right: services/mcp-pool/src/ is built as a registry and router
(registry.ts, pool.ts, invocation-router.ts, manifest-loader.ts, health-monitor.ts),
and the Workbench data plane runs through Projection and context-fetch on separate Gateway routes.
services/gateway/src/index.ts:1687 confirms /api/v1/capabilities/resolve is introspection, not
execution.

The L1 read path was not traced end to end. This is deliberately left open. The canon's own
warning was that MCP Pool had previously been accepted "without actual routing evidence," and
converting an architectural intention into an implementation claim is the exact failure mode this
document exists to prevent.

---

Nine planes → code

#	Plane	Status	Implementation
1	Identity & Authority	Question	packages/auth, packages/rbac, packages/tenancy, services/tenants, apps/one-access, apps/one-access-console, apps/auth
2	Ecosystem & Integration	Aligned	services/connector, connector-sync, mcp-connector, webhook-ingress, marketplace-installation, packages/connectors, packages/connector-contracts
3	Discovery & Activation	Gap	apps/activation (UI), gateway/platform-discovery.ts, gateway/platform-catalog.ts
4	Ingestion & Normalization	Aligned	services/gateway, loader, normalizer, pipeline, store, folder-watcher, packages/loader, packages/normalizer
5	Spine & Continuity	Gap	services/spine, knowledge, continuity, context, signals, packages/spine-schema, spine-entities, hermes-spine-memory
6	Projection & Experience	Naming	packages/projection-engine, projection-contracts, services/projection, context-fetch, packages/workbenches, apps/web, apps/workspace
7	Cognitive & Agent Runtime	Partial	services/twin-orchestrator, iw-agent-runtime, agent-registry, intelligence, packages/adk, packages/model-gateway
8	Capability & Governance	Strongest	services/capability, govern, mcp-pool, packages/lib/capability-fabric, packages/spine-network
9	Execution & Closure	Aligned	services/hermes, services/pipeline/promotion, packages/core/execution-orchestrator, services/workflow

Plane notes

1 — Identity & Authority. Well covered, with one open question: the Gateway carries both
clerk-auth.ts and descope-auth.ts. "One Auth" with two identity providers wired needs a stated
reason — mid-migration, or deliberate IdP layering — or it becomes a drift by accident. Needs a
founder or engineering answer, not a code change.

3 — Discovery & Activation. The weakest plane. Activation Bridge — the canon's runtime
configuration compiler, distinct from the human-facing Activation Manager — has zero presence by
name. Discovery Engine matches only UI components and knowledge search, not a discovery
service. packages/bootstrap has no src/. The capability may exist under other names; the
naming does not survive a canon reader's grep, which is the test that matters for a freeze.

4 — Ingestion. Gateway → Loader → Normalizer → governed writers all present. Flows A/B/C/D are
not labelled as such in code — a vocabulary gap, not a capability one.

5 — Spine & Continuity. The Business Spine is real and well built. The continuity model is
not: only two memory scopes exist where canon mandates three. See G-01, G-02.

6 — Projection. Projection Engine and Active Context Bundle both exist and are wired.
"Workbench Contract" does not exist under that name. The word Workbench is overloaded — see
G-04.

7 — Cognitive & Agent Runtime. Twin, ADK and model routing are present. Spine Agents as
canon defines them are not first-class; services/agent-registry/src is a single file. Blocked
behind the memory-scope work.

9 — Execution & Closure. Outcome → reconciliation → governed promotion → projection
invalidation is implemented end to end. services/pipeline/src/memory-promoter.ts enforces the
canon invariant directly: Twin-sourced writes can never auto-promote into organizational
memory, landing in staging pending approval. This is the invariant already working in code.

---

What is already canonical and should not be touched

Recorded explicitly, because an alignment document that only lists problems invites unnecessary
redesign:

• Capability / Governance / Hermes separation, including fail-closed behaviour on Governance
  outage.
• Hermes' refusal to perform canonical Spine writes.
• Governed memory promotion, including the rule that AI-sourced observations never auto-promote.
• Projection Engine as the sole composition layer, and the Active Context Bundle.
• Outcome → sync → verify → reconcile → projection invalidation.

---

Part II — Gap Register

⚠️ Ordering superseded — 2026-09-01

The entries below remain accurate as measurements, but their ranking is superseded by the
priority stack in
ADR-2026-09-01-02.
The next design target is the Reference Execution — Business Context to Verified Outcome, and
G-04 is explicitly deprioritized to P2.

Survey refreshed against the 6.1 suite — 2026-09-03

The suite (adopted verbatim in
ADR-2026-09-03-05):
00-SPINEWORKSPACE-INTEGRATEWISE-CANON-6.1.md,
02-BUSINESS-CONTEXT-SPINE-6.1.md,
06-CONNECTOR-SCHEMA-CAPABILITY-CONTINUITY-6.1.md.

The repository was re-surveyed at
22013618a50ea8c6b7f7d75ba980c48b11440454. The previous stale-stamp warning no longer applies.
G-17 through G-21 record the additional schema, mapping, KPI/signal, Work/continuity and
connector-lifecycle gaps found in that survey. Earlier entries remain as dated measurements.

Re-verified against the founder records — 2026-09-04

Re-surveyed at b60d21ec after the founder Architecture Flow / Final Goal / Final Architecture
records landed (ADR-2026-09-04-01/02/03). Every G-17–G-22 claim was re-verified by
reading the file it names; verdicts are recorded per gap. Three new gaps found: G-23
(memory/continuity/reconciliation planes contracted in surface bindings but never persisted),
G-24 (governance outcome vocabulary drift), G-25 (stale agent-roster references).
Positive alignment also recorded: Hermes implements the canon execution law; the surface
contract system (~30 surfaces) is a working projection-binding registry; storage planes
(Valkey, Vectorize, R2) are wired; creamy/breadth hydration phases exist in sync adapters.

Gap-closure pass — 2026-09-04 (functional verification included)

A fix pass closed G-22, G-24 and G-25, authored the G-23 persistence, and — via the
governed-chain test suite (pnpm test:governed-chain) — found and fixed a live functional
break: the projection engine's D1 entity read path returned zero entities because
mapSpineEntitiesToView was imported from types.ts (which lacks it) instead of
types/index.ts; the TypeError was swallowed and the Workbench silently composed empty
(packages/projection-engine/src/assemblers/entity-assembler.ts:2). With the import corrected,
@integratewise/projection-engine passes 54/54 and @integratewise/capability 50/50,
including new denied / bounded_delegation cases. See per-gap notes below for status.

Ranked by structural consequence, not by effort.

---

G-12 · Business context never reaches the action surface — CRITICAL · STARTED 2026-09-03

The largest gap between the product thesis and the code.

Canon §1A: "Business Context is the only thing that connects the entire workspace to every
other feature. Without business context, there is no meaning in working in SpineWorkspace."
Business context must lead every surface, every action and every ranking, and priority is
business priority — objectives, goals and KPIs decide order.

Code: the four context actions resolve against ActiveContextBundle. That contract carries
principal, projection, selection, entityContext, entity360, formation, knowledge,
memory, evidence, capabilities, policy, freshness, uncertainty, returnState — and
no objectives, goals or KPIs. Zero matches for those terms anywhere in
packages/context-contracts.

KPI measures exist, but only as entity-level fields in the Projection Engine — target_value,
current_value, health_score, probability, stage, target_date, under the comment
"Canonical KPI & Business Context dimensions (§11.1a)"
(packages/projection-engine/src/types.ts:137). They are assembled at entity level and stop there.

Consequence: an action can see what this record is, but not which goal it serves or how it
ranks. Nothing in the running system can order work by business priority, because the dimension
required to do so never reaches the surface that would use it. The Mission → Objectives → Goals →
KPIs → Work chain from canon §13 exists in doctrine and not in the contract.

Decision: ADR-2026-09-01-01

Shape of the fix: extend ActiveContextBundle with a business-context / intent section
carrying the entity's place in the objective chain and its governing KPIs, have the Projection
Engine populate it from dimensions it already assembles, and have ContextActionSlot resolve
availability and ranking from it. This touches the Projection Engine and every consumer of the
bundle — scoped, not started.

STARTED 2026-09-03 (first slice):

• ActiveContextBundle.businessContext?: BusinessContextAlignment added
  (packages/context-contracts/src/active-context.ts) — optional for backward compatibility.
• context-fetch assembler populates it from the entity's canonical KPI dimensions
  (target_value, current_value, health_score, probability via selection attributes),
  with chainComplete: false — honest partial: KPI measures surface, the objective/goal chain
  above them is still not populated anywhere in the data.
• Consumer: ContextualTwinInvocation.businessAlignment (Twin context now receives the KPIs this
  work serves) and ContextActionSlot renders the business-priority line with a visible
  (partial chain) marker when chainComplete is false.

Remaining: objective/goal chain data source (lifecycle chain from canon §13), priority
ranking of actions from business priority, projection-engine-side objective resolution.

---

G-13 · The Platform view has three homes — HIGH (new, 2026-09-01)

Canon §2A requires User, Platform, Package, Pipeline-execution and Agentic-execution views to be
distinct. The Platform view is not one surface.

Code — three candidate homes:

Location	State
apps/web/app/platform/	A platform surface inside the user-view app. Sections include integration-manager, connector-marketplace, telemetry, tool permissions, autonomous policy gates.
apps/platform/	Has app/architecture, tailadmin-architecture, api, a shell.
apps/platform-console/	Has src/app with organizations and users. The name matching canon §25 ("Platform Console") — but the thinnest of the three.

Consequence: an operator cannot be pointed at the Platform view, and a change to operator
experience has three places it might belong. It also puts operator-shaped sections inside the
application whose entire job is to hide infrastructure from the user (canon §10, Appendix C item
22).

Unverified — needs checking before it is treated as a security finding.
apps/web/app/platform/ contains no in-page authorization: no useSession, auth(),
currentUser, role or redirect. Next.js middleware does cover the path
(matcher: ["/((?!_next/static|_next/image|api/|favicon.ico).*)"]), so it is not unprotected by
default — but I did not verify whether that middleware enforces an operator role for
/platform. Confirm before concluding either way. Much of the content also reads as descriptive
rather than operational, so this may be an informational page rather than a live console.

Decision needed: which surface is the canonical Platform view, and what happens to the other
two. Canon §25's naming points at apps/platform-console, but that is the least built.

---

G-11 · A surface implements the four actions outside the governed path — CLOSED 2026-09-03

Code: apps/web/app/app/workbench/sales/page.tsx renders "Store in Spine" three times
(lines 117, 155, 194), each driven by local setShowStoreModal component state rather than
ContextActionSlot.

The placement is correct — per-card, not a toolbar, consistent with
ADR-2026-09-01-01. The path is not: no
governance decision, no evidence requirement, no proposal, no approval, no reconciliation.

Same class as G-06 — a parallel ungoverned path — though a UI one. The page has no inbound links
and appears to be an orphaned demo, which is why it is HIGH rather than CRITICAL. Confirm it is
dead, then delete it or route it through the slot.

CLOSED 2026-09-03: confirmed dead (zero inbound links; /workbench/* permanently redirects to
/work) and deleted. The four actions exist only through ContextActionSlot (governed path).

---

G-01 · Three continuity domains collapsed into two — CLOSED 2026-08-31

Was: packages/hermes-spine-memory/src/types.ts:29 defined
MemoryScope = "personal" | "org", and the namespace header described personal:user:{id} as
holding "twin chat history, personal notes" — one namespace, two participants. routeTwinMemory()
could only route Twin into personal or org; AI had no namespace of its own.

Now: three scopes — org (tenant-addressed), personal (user-addressed), ai
(agent-addressed). Twin defaults to its own ai continuity. Every scope refuses to resolve without
the subject it addresses, rather than falling back to another participant's id. 27 tests added; the
package previously had none.

Also fixed: a latent round-trip bug where dbNameFromPath(ns.path) and ns.dbName produced
two different database names for the same namespace. The path grammar is now uniformly
{scope}:{subjectType}:{subjectId}.

Decision: ADR-2026-08-31-02

Correction to the original assessment: this register previously implied live commingled data.
It does not exist. packages/hermes-spine-memory has zero consumers; services/continuity
binds D1 exclusively and no longer has a CouchDB client; apps/web/lib/core/twin-memory/store.ts
is an in-memory Map marked dev-only. No CouchDB memory databases are provisioned, and AI
continuity has no persistent home today. No migration was required — see G-10.

Note: the promotion side was already correct — memory-promoter.ts never auto-promotes
AI-sourced writes. Unchanged.

---

G-02 · Personal Contextual Spine does not exist — CRITICAL

Code: no match for the term anywhere across services, packages, apps or contracts. The
closest construct is the personal memory namespace, which is a memory store, not a contextual
spine.

Canon: a first-class personal context plane, distinct from both organizational Spine truth and
AI continuity, with its own privacy boundary and governed promotion rules.

Decision: ADR-2026-08-31-03

---

G-03 · "Twin Workbench" contradicts "AI Workbench" — CRITICAL

Two live documents, two different models — and this is the drift that caused the whole class of
problem.

Code / docs:

• apps/web/public/docs/architecture/PRODUCT_FRAMING_LOCK.md §8, §15 — defines Twin Workbench
  as "the agentic work environment used by the user's Twin." Per-user, Twin-owned. Was still
  marked CURRENT PRODUCT FRAMING.
• docs/architecture/SPINEWORKSPACE_CANONICAL_PRODUCT_MANUAL.md — headed "THE DEFINITIVE
  END-STATE MODEL… frozen source of truth." Lists Twin Workbench as architectural layer 10
  and Coworker as layer 9.

Canon: Twin is not the AI Workbench. Twin is the human-facing AI coworker operating inside
the AI Workbench, which hosts Twin and Spine Agents.

Decision: ADR-2026-08-31-01.
Both documents have been stamped superseded.

Coworker — RESOLVED against the Founder Canon. This was previously recorded as needing a
founder decision. The Founder Canon settles it: "coworker" appears only as a common noun
describing Twin — "Twin is the human-facing contextual AI coworker operating within the AI
Workbench" (§0.3 item 6, §32) — never as a distinct layer or component. Appendix C item 5 names
the human-AI interface as Twin, with no Coworker beside it.

So the Product Manual's layer-9 Coworker is retired, absorbed into Twin. Not a separate
concept, not a second orchestration authority.

Update 2026-09-04: the founder's Final Architecture record
(FOUNDER-FINAL-ARCHITECTURE-2026-09-04.md §13,
ADR-2026-09-04-03) restores Coworker
as a distinct concept — the contextual companion that helps assemble active context and
communication, still not a second orchestration authority. As the later founder decision it
supersedes this entry's resolution; the text above stands as the dated measurement of the
2026-08-31 Founder Canon era. Product/UI surfaces follow ADR-2026-09-04-03.

---

G-04 · "Workbench" means several different things — PARTLY CLOSED 2026-08-31

Correcting the original entry

This entry originally said WorkbenchType was a departmental enum competing for the word, and
prescribed "rename the departmental lens — mechanical but wide." Both halves were wrong, and
the correction matters more than the original finding.

WorkbenchType was dead. packages/types/src/projection-layers.ts had zero importers —
all 25 exports unreferenced. The apparent hits on Twin (1,179), Insight (52), Correlation
(21) and WorkbenchContext (5) were coincidental collisions with types defined independently
elsewhere; none imported from this file.

The live departmental model is somewhere else, and it is load-bearing.
packages/workbench-config and packages/workbenches carry the real departmental surface, and
they are consumed by the Gateway (projections.ts, cors.ts), the Projection Engine, and
services/projection. Critically, DomainWorkbench carries a hostname field — these map to
deployed subdomains. Renaming them is not a mechanical rename; it is a routing, CORS and
deployment change.

There are at least three senses in play, not two:

Sense	Where	Example values
Participant class (canon)	00-INTEGRATEWISE-CANON.md	Human Workbench, AI Workbench
Department / domain (live)	packages/workbench-config, packages/workbenches	cs, finance, engineering, founder
Surface / modality (live)	apps/web/components/workbenches/	email, calendar, tasks, inbox, approvals

Action taken

packages/types/src/projection-layers.ts deleted, and its barrel export removed from
@integratewise/types. Beyond squatting on WorkbenchType, it defined TwinWorkbench — the
exact term superseded by ADR-2026-08-31-01
— and being barrel-exported made it reachable by autocomplete and adoptable at any time. Same
shape as G-06: dead code encoding a superseded model.

Deleted rather than renamed, because renaming would have preserved a duplicate of a model the live
packages already implement better. Full suite before and after: identical (61 failed / 50 passed —
all pre-existing unresolved imports in an unbuilt workspace).

Deliberately not done

The live departmental surface keeps its name. Renaming it would touch ~315 files plus Gateway
CORS and hostname routing, to resolve a vocabulary concern. That is a bad trade, and the canon does
not require it — canon requires that Workbench mean participant class in canonical documents and
new work, not that every existing identifier be rewritten.

Note the live app layer already disambiguates better than the dead type did:
apps/web/lib/core/workbenches/types.ts uses DepartmentWorkbench.

Open: whether to adopt DepartmentWorkbench / domain-lens naming consistently in new code. A
naming convention question, not a refactor.

---

G-05 · Spine Agents are not first-class — HIGH

Named, not modelled.

Code: the term appears in two files. services/agent-registry/src is a single index.ts. No
agent-owned memory namespace, no per-agent authority record.

Canon: governed organizational AI actors carrying identity, authority, memory namespace and
capabilities, cooperating through shared Work and evidence state rather than agent-to-agent
re-explanation.

Depends on G-01 — agents cannot have memory namespaces until the scope model supports them.

---

G-06 · Orphaned governance-bypass middleware — RESOLVED 2026-08-31

services/gateway/src/adk-middleware.ts — 362 lines, requiresApproval: false hardcoded at line
108, direct runtime dispatch at 114–128, zero importers outside its own test. Harmless as it
stood; a live bypass the moment anyone wired it.

Action taken: file and test deleted. No dangling references remain.

---

G-07 · Activation Bridge and Discovery Engine unfindable — HIGH

Plane 3 has no named home.

Code: no match for Activation Bridge. Discovery Engine matches only UI components and
knowledge search. packages/bootstrap has no src/. What exists: apps/activation (UI),
gateway/platform-discovery.ts.

Canon: Discovery Engine discovers data, systems, models, agents and capabilities. Activation
Bridge compiles runtime configuration — distinct from the Activation Manager surface.

Action: establish the canonical name → implementation mapping, or build what is missing.
Either resolution is acceptable; leaving the plane unnameable is not.

---

G-08 · Documentation has no single canonical root — MEDIUM (partially addressed)

State at survey: 2,586 md/mdx files across three roots — docs/ (5),
apps/docs/ (1,921), apps/web/public/docs/ (661). Four documents claimed canonical
authority and disagreed with each other. ADR numbering collides: two independent sequences both
start at ADR-001 (apps/docs/internal/adr/decision-register.md 001–014, and
apps/web/public/docs/adr/ 001–007).

Addressed: docs/canonical/ now exists with the CANON / ALIGNMENT doctrine, source
precedence, and date-namespaced ADR IDs that cannot collide with either legacy sequence. The two
competing canonical documents are stamped superseded.

Remaining: merging the two legacy ADR sequences into this tree, and consolidating the three
documentation roots. Both are disruptive moves that deserve their own change.

---

G-09 · Contracts tree is one-eighth built — LOW

Contracts exist, but not where canon looks.

Code: contracts/ holds only shared-workbench/. Authority contracts live in
services/govern; projection contracts in packages/projection-contracts.

Canon: /contracts/ covering schemas, commands, events, capabilities, projections, authority
and executions.

Largely a topology gap — most contracts exist, they are simply not collected.

---

G-10 · AI Continuity is neither persisted nor grounded — HIGH (new 2026-08-31, reframed 2026-09-01)

The question was wrong

This entry originally asked: "which store backs AI Continuity Memory?" Canon §1A reframes it, and
the reframing is the more important half:

How does AI maintain independent continuity while remaining grounded in, and accountable to,
the authoritative Business Context Spine?

Accountable to, not merely grounded in — the AI's continuity must be answerable to business
context, not just correlated with it.

Storage is an implementation of grounding, not a substitute for it. Both personal and AI memory
operate on Business Context — they do not replace it. A persisted AI memory that drifts from the
Spine would satisfy the original question and still fail the product: it would be an AI with a good
memory of things the organization no longer believes.

So this gap has two halves, and only the first was previously recorded.

Half one — nothing persists it

AI continuity has no persistent home. Neither candidate substrate is live.

Code:

• packages/hermes-spine-memory — a complete CouchDB substrate (client, namespaces, continuity
  object CRUD) with zero consumers. Nothing imports it.
• services/continuity — binds env.DB (D1) exclusively. Its wrangler.toml carries the note
  "SUPABASE_ secrets removed — service uses env.DB (D1) exclusively (DECISION 22)"*, and
  src/couchdb.ts no longer exists.
• apps/web/lib/core/twin-memory/store.ts — in-memory Map implementation, headed "Production:
  Replace with Supabase or database backend."

Consequence: the three-domain model now exists correctly in types (G-01), but nothing writes
through it. Twin's working memory does not survive a process restart.

Stale documentation to correct: services/continuity/README.md still instructs
wrangler secret put COUCHDB_URL / COUCHDB_USER / COUCHDB_PASSWORD, and
apps/web/public/docs/internal/status/SERVICE_ARCHITECTURE_REPORT.md lists a src/couchdb.ts that
no longer exists. Both imply a CouchDB deployment that is not there.

Half two — nothing grounds it

Even once persisted, there is no mechanism keeping AI continuity anchored to the Spine:

• No grounding reference. ContinuityObject carries references: ObjectReference[] typed as
  entity | document | session | task | decision | signal — but nothing requires a continuity item
  to reference the business context it was formed against, and nothing invalidates it when that
  context changes.
• No staleness signal. ActiveContextBundle has freshness and uncertainty for the context
  it assembles, but AI continuity is not assembled through that path, so it inherits neither.
• No business anchor to ground to. Per G-12, objectives, goals and KPIs never reach the
  context surface — so even a grounding mechanism would have nothing to bind against beyond entity
  identity.

G-10 half two is therefore blocked on G-12. Business context has to arrive at the surface
before AI continuity can be held against it.

Decisions needed

1. Grounding contract (architecture, blocked on G-12) — what a continuity item must reference
   in business context, and what happens to it when that context moves. This is the decision that
   matters.
2. Store (implementation) — the existing CouchDB substrate, D1 alongside services/continuity,
   or something else. Answer this after (1), so the store is chosen to serve grounding rather
   than grounding retrofitted onto a store.

---

A note on "memory scope" meaning three different things

Not a gap, but a trap for the next reader. Three unrelated axes share the word scope:

Location	Axis	Values
packages/hermes-spine-memory	Ownership / continuity domain	org, personal, ai
apps/web/lib/core/twin-memory/types.ts	Durability / lifetime	SESSION, WORKING, LONG_TERM, ORGANIZATIONAL
packages/context-contracts/src/active-context.ts	Retrieval facet (Active Context Bundle)	session, user, work, entity, organization

Only the first is the canonical three-domain model. The other two are legitimate but differently
named concepts, and both use organization/ORGANIZATIONAL in a sense that overlaps but is not
identical to org. Renaming is deferred — recorded so nobody "fixes" the wrong one.

---

Open questions (not gaps)

Recorded because they need an answer from someone, not a code change from anyone.

#	Question
Q-1	The Gateway carries both clerk-auth.ts and descope-auth.ts. Is "One Auth" with two IdPs a migration in flight, deliberate layering, or accidental drift?
Q-2	Is MCP Pool in the L1 read path? Requires tracing, not opinion.

Closed: "Is Coworker an aspect of Twin, or retired?" — answered by the Founder Canon. Retired, absorbed into Twin. See G-03.

G-14 · Agent Home is not a unified runtime — HIGH (new, 2026-09-03, from Canonical Product Spec)

The spec names one governed Agent Home per workspace: shared/ (workspace context, policies,
knowledge, capabilities, model registry), twin/ (orchestration + continuity state), and runs/
(specialist agents as isolated scoped runs). Code has fragmented pieces (agent registry, Twin
runtime, twin-memory store) but no unified Agent Home runtime, and the "runs as scoped tasks, never
competing user-facing identities" model is unbuilt. Twin intervention levels 0–5 (Observe → Inform
→ Explain → Propose → Prepare → Execute) are likewise not modeled explicitly. Users must see
outcomes, evidence, decisions, and approvals — never an "Agents" menu.

---

G-15 · Fortress audit plane does not exist as a named plane — HIGH (new, 2026-09-03, from Canonical Product Spec)

The spec defines Fortress: an append-oriented, tamper-evident, retention-governed audit plane
(decisions, approvals, policy checks, actions, outcomes, verification) with a defined decision-trace
shape: context snapshot refs, evidence refs, rationale summaries, model/version, proposal/approval,
tool calls, results, verification state. Raw chain-of-thought must NOT be retained as an enterprise
persistence contract. Audit logs exist (canon §17) but no unified Fortress plane or decision-trace
shape.

---

G-16 · Role grammar (16 sections) and role-specific entity models — MEDIUM (new, 2026-09-03, from Canonical Product Spec)

The spec freezes a 16-section workbench grammar (Home/Role Brief, My Work, Primary Portfolio,
Entity 360, Pipeline/Queue, Timeline, Calendar, Communications, Documents & Knowledge, Signals &
Risks, Approvals, Planning Canvas, Reports & Metrics, Automation & Playbooks, Recent Work, Twin
Detail — Twin Detail is click-triggered, never a permanent sidebar) and 12 canonical roles with
distinct entity models (Founder→Strategic Objective, Sales→Opportunity, Legal→Contract/matters/
clauses, Technology→Service/repos/PRs, Support→Ticket/SLAs/escalations, …). Current code has 10
department configs; the grammar and role-specific entity models are not yet projection contracts.

---

G-10 (updated) · AI Continuity — L1–L8 promotion stages not modeled — (reframed 2026-09-03)

The spec fixes the memory lifecycle as an eight-stage pipeline: L1 Twin insight → L2 Intake → L3
Triage → L4 Evolution → L5 Promotion candidate → L6 Approval → L7 Organizational continuity → L8
Verified knowledge. Dynamic records must retain tenant/entity linkage, confidence, generating actor,
and OODA episode association; canonical promotion requires governed review; memory supports
provenance, correction, supersession, expiration, retention, and conflict resolution. The existing
promotion law satisfies the boundary; the explicit stage model does not exist yet.

---

G-17 · Entity ontology and universal envelope do not match 6.1 — HIGH (new, 2026-09-03)

Canon: §3 and §4 define a 26-field universal Spine record envelope and 20 primary business
entities. The Business Context Spine extends that inventory with 20 additional canonical objects.
Required envelope concerns include workspace identity, primary source, record state, confidence,
freshness and visibility — not only an ID, tenant and JSON payload.

Code: the active vocabulary is both narrower than 6.1 and internally inconsistent:

• packages/spine-schema/src/entities.ts:11-21 exports ten RootConcept values.
• services/spine/src/canonical-store.ts:17-42 labels its model "16 Root Concepts" plus seven
  operational primitives and stores all of them through one generic entity contract.
• sql-migrations/081_neon_workbench_spine_v1.sql:147-165 constrains spine.entities to those 16
  entity types and places most record-specific state in data, metadata and provenance JSON.
• Richer definitions such as Account and Contact exist in
  packages/spine-entities/src/account.ts and contact.ts, but the package barrel exports neither
  (packages/spine-entities/src/index.ts:9-41). They are not the active canonical store contract.

Consequence: canon entities such as Contract, Subscription, Invoice, Ticket, Meeting, Employee,
Feature, EngineeringIssue, Release and Deployment have no consistently exported, persisted 6.1
identity. Envelope fields cannot be validated uniformly, and connector mappings can collapse
business meaning into a generic type or JSON payload.

Required fix: adopt one versioned 6.1 entity registry; implement the universal envelope as a
shared persisted contract; export the canonical object schemas; migrate the D1/Neon constraints and
read/write paths; and provide compatibility mappings for existing 16-type records. This is a schema
migration, not a terminology-only rename.

Re-verified 2026-09-04 (b60d21ec) — HOLDS. All four claims re-read and confirmed. Refinements:
spine-schema RootConcept is the ten values Organization, Workspace, Person, Team, Process, Project, Objective, Outcome, Asset, Opportunity; the barrel now additionally exports operational
types (Connection, Connector, SyncJob, Webhook, Schema, Capability, TimelineEvent,
PlatformEvent with ReconciliationStatus/ProjectionFreshness) — account.ts/contact.ts
remain unexported. The universal envelope concerns (workspace_id, external_ids,
source_systems, source_primary, record_state, confidence, freshness_at,
visibility_scope, classification) appear nowhere on spine.entities; external_ids JSONB
exists only in domain depth tables (sql-migrations/048_spine_universal_depth.sql:62,227,260).
082_spine_tenant_user_lifecycle.sql adds a real lifecycle/RBAC plane (business domains, app
categories, domain_entity_types, lifecycle stages, domain_workbench_bindings, five projection
views) but does not adopt the 6.1 entity set or envelope.

---

G-18 · Versioned field-mapping plane and conflict resolution are absent — CRITICAL (new, 2026-09-03)

Canon: §11.1 and Connector Specification §5 require a durable, versioned, per-tenant mapping
record: provider object class, canonical object and field, transformation, identity and relationship
rules, source precedence, conflict policy, write mode, sync direction and provenance. Canonical field
state must represent source_conflict, stale, unverified, missing, invalid and
pending_promotion rather than silently selecting a value.

Code: mapping is implemented as disconnected local helpers:

• services/pipeline/src/canonical/entity-type-map.ts:82-92,385-395 is a process-wide static object
  map and defaults unknown provider types to Asset.
• services/integration-management-mcp/src/schema-manager.ts:11-53 keeps tenant-tagged schemas in an
  in-memory Map; its versioned result is not a durable activated tenant policy.
  normalizeSchema/computeFieldMapping (:201-240) perform vocabulary substitution only.
• packages/connectors/src/sync-adapters.ts:35-84 hardcodes provider-specific field transforms in
  connector functions.

There is no single persisted mapping activation record, provider-object classification registry,
sample-test gate, tenant source-precedence engine or canonical field-conflict state machine.

Consequence: the same provider field can acquire different business meaning depending on which
path ingests it. Mapping changes are not auditable or safely reversible, tenant precedence cannot be
enforced, and contested values can be promoted without an explicit resolution state.

Required fix: build the semantic mapping plane as a durable tenant-scoped service/schema;
version object and field mappings immutably; activate versions only after sample-record tests; add
transformation, identity, relationship, write and conflict policies; persist field-resolution state
and provenance; and route every connector/normalizer through the activated mapping version.

Re-verified 2026-09-04 (b60d21ec) — HOLDS. All three claims re-read and confirmed. Note:
packages/spine-entities/src/schema.ts defines a Schema shape with canonicalMappings,
version and hash, but it is a type definition, not a durable activated tenant mapping policy.
Positive: packages/connectors/src/sync-adapters.ts implements the founder record's hydration
phases (opts.phase === "creamy" ? 10 : …) — creamy/breadth hydration exists at the sync layer
even though the mapping plane above it is still absent.

---

G-19 · KPI and Signal are not first-class business objects — HIGH (new, 2026-09-03)

Canon: §6 defines KPI as a governed object with metric identity, target, actual, thresholds,
ownership, period, trend and alert policy. §9 defines Signal with source, severity, baseline, delta,
impact, evidence and recommended Work. Together they form the traceable KPI → Signal → Work chain.

Code: services/signals is an event bus. Its SignalMessage
(services/signals/src/index.ts:24-36) carries routing/event data, while SignalStore persists bus
processing state (services/signals/src/store.ts:1-13,32-42). It is not the canonical 24-field
business Signal contract. KPI appears only as projection alignment dimensions in
BusinessKpiAlignment (packages/context-contracts/src/active-context.ts:177-198); there is no
first-class KPI record with thresholds, ownership and alert policy.

Consequence: targets and thresholds cannot be governed and queried independently of a
projection, and a detected event cannot retain a canonical baseline, delta, impact and recommended
Work. The system cannot evidence which KPI produced a Signal or which Work resolved it.

Required fix: add versioned KPI and Signal schemas and persistence; connect KPIs to entities,
goals and evidence; implement threshold/trend evaluation that creates canonical Signals; link each
Signal to recommended or created Work; and project those records through the existing context and
signal-delivery paths. The event bus should transport Signal changes, not substitute for the Signal
business object.

Re-verified 2026-09-04 (b60d21ec) — HOLDS. SignalMessage remains an event-bus envelope
(signal_type, source_service, event_name, correlation_id — no baseline/delta/impact/
recommended_work); SignalStore remains bus state (pending/processed/failed/replayed);
BusinessKpiAlignment remains projection dimensions. One richer element than previously recorded:
BusinessContextAlignment already models the Mission → Objectives → Goals → KPIs chain with an
explicit chainComplete: false honesty flag — the chain skeleton exists, the governed KPI/Signal
records do not.

---

G-20 · Formal Work identity and ContinuityRun execution chain are missing — HIGH (new, 2026-09-03)

Canon: §8 makes Work the durable human-AI coordination object, including context contract,
current holder, handoff state, authority, evidence and outcome. §19 requires ContinuityRun to keep
one trace from intent and context through capability selection, governance, execution, verification,
reconciliation and canonical-state refresh.

Code: services/continuity models conversational SessionContainer, SessionEvent and
checkpoints (services/continuity/src/types.ts:31-88). Operational tasks live in
spine.activities; the schema explicitly says Activity is a primitive rather than a canonical root
and provides task/message/meeting/approval rows (sql-migrations/081_neon_workbench_spine_v1.sql:261-286).
Neither contract carries the canonical Work identity, context_contract, current_holder or
handoff_state, and no ContinuityRun joins the execution-and-closure stages.

Consequence: a task, conversation, approval, capability execution and verified outcome cannot
reliably share one stable business-work identity. Handoffs require reconstruction, and end-to-end
continuity is lost when the model, participant, provider or execution route changes.

Required fix: implement Work and ContinuityRun as first-class canonical records; preserve
Work ID across projections and provider routes; bind Work to goals/KPIs, Signals, context snapshots,
evidence, decisions and commitments; and append each governance, Hermes, outcome, verification and
reconciliation transition to the same ContinuityRun. Existing activities and sessions should link
to Work rather than be relabelled as Work.

Re-verified 2026-09-04 (b60d21ec) — HOLDS, with one new partial to credit.
services/intelligence/src/handoff/ implements a real handoff state machine
(state-machine.ts — ALLOWED_TRANSITIONS, persisted handoff_packages/handoff_state_log
with actor + reason, 409 on invalid transitions), and
packages/contracts/src/surfaces/platform.ts:415 names a spine_continuity_runs supporting
table. This is handoff/continuity infrastructure, not the canonical Work object: no record
anywhere carries context_contract, current_holder, handoff_state or Work identity, and no
ContinuityRun joins governance → execution → verification → reconciliation stages.

---

G-21 · Connector revocation does not complete the degradation lifecycle — MEDIUM (new, 2026-09-03)

Canon: Connector Specification §10 requires revocation to stop sync, invalidate credentials and
route-dependent capabilities, retain historical canonical state, visibly degrade freshness, expose
stale projections and retain the audit trail.

Code: the connector route marks tenant_connections.status = 'revoked'
(services/connector/src/routes/capability.ts:242-249). Projection governance can block a capability
already marked degraded or unavailable
(packages/projection-engine/src/evaluators/governance-evaluator.ts:71-79), and the context contract
can describe generic stale sources (packages/context-contracts/src/active-context.ts:126-141). The
survey found no end-to-end path that converts the revoked connection into both route-capability
status and source-specific freshness degradation in projections. The freshness source contract also
has no connection/revocation reference.

Consequence: historical values sourced only from a revoked provider can remain visually
indistinguishable from live data, while capability availability and data freshness may disagree.
Users and AI can therefore reason from stale context without seeing why it degraded.

Required fix: emit and audit a revocation lifecycle event; stop scheduled and queued sync;
invalidate credentials; recompute route-dependent capability availability; mark records and
projection sources from that connection stale with last-successful-sync and revocation reason; and
verify re-install, retention and reconciliation behavior end to end.

Re-verified 2026-09-04 (b60d21ec) — HOLDS. The revocation handler remains a single
UPDATE tenant_connections SET status = 'revoked' returning {revoked: true} — no event, no
credential invalidation, no sync stop. The governance evaluator's healthy-path comment ("A
capability whose connection is not healthy cannot resolve, so the Workbench shows it as blocked")
and FreshnessSource {sourceRef, observedAt, status} confirm both halves exist with no link
between them.

---

G-22 · Superseded v11.0-era doctrine is still live in active instructions and contracts — HIGH (new, 2026-09-04)

Canon: the Founder Canon (2026-08-31) and the founder Architecture Flow record
(FOUNDER-ARCHITECTURE-FLOW-2026-09-04.md, see ADR-2026-09-04-01) fix the AI work model as
Twin + governed Spine Agents coordinating through Work, evidence and handoff, with knowledge
promoted through the governed Spine path. The January 2026 "v11.0 Master Lock" marketing pack and
its vocabulary are superseded (ADR-2026-09-04-01 §F-3).

Code: superseded doctrine and vocabulary remain in active, non-archive surfaces:

• .github/agent.md:169-171 instructs agents: "Only One Cognitive Twin … a single Cognitive
  Twin per tenant/workspace, not multiple specialized agents." This directly contradicts the
  Twin + Spine Agents model and would steer new implementation away from governed specialist
  agents.
• contracts/shared-workbench/CHANGELOG.md:20,36 still maps the knowledge projection input to
  "IQ Hub context" and states "knowledge comes from IQ Hub, never from Spine directly";
  packages/projection-engine/ARCHITECTURE.md:21,83 repeats the "IQ Hub" enrichment language.
  The retired name aside, an absolute "never from Spine" rule conflicts with the canonical
  knowledge/evidence promotion path (KnowledgeRecord/EvidenceRecord in the 6.1 canonical
  inventory) and needs re-scoping to personal knowledge surfaces versus promoted organizational
  knowledge.

Consequence: agents reading .github/agent.md will implement against retired doctrine;
contract language pins the projection layer to a retired product concept, so future work either
propagates stale vocabulary or diverges from the written contract.

Required fix: rewrite the agent-doctrine section to the Twin + Spine Agents model with the
current vocabulary; re-scope the knowledge projection contract to explicit personal-knowledge
versus Spine-promoted knowledge inputs and update the projection-engine architecture references;
keep archived v11.0 documents as lineage only.

Re-verified 2026-09-04 (b60d21ec) — HOLDS, expanded. All three original claims re-read and
confirmed. Two refinements: (1) the same "Only One Cognitive Twin" doctrine is duplicated at
apps/web/public/docs/team/AGENTS_SUPPLEMENT.md:159-161; the codebase it describes already has
specialist agents (services/iw-agent-runtime/src/agents/ — triage, schema, discovery,
autotuner, collaboration-log) and a services/twin-orchestrator, so the doctrine contradicts
reality, not just canon. (2) The "knowledge from IQ Hub, never from Spine" line echoes a
deliberate boundary documented in apps/web/public/docs/adr/005-iq-hub-derived-intelligence-only.md
(derived intelligence never stores canonical state; Spine reads entities) — the boundary is
ADR-backed, the name is retired; the fix is re-scoping and renaming, not reversing the
fact/inference separation.

Fix 2026-09-04 — CLOSED. Doctrine rewritten in .github/agent.md §8 and
apps/web/public/docs/team/AGENTS_SUPPLEMENT.md §8 ("One Twin, governed Spine Agents" with the
four governance outcomes and explicit-delegation rule); the knowledge contract line in
contracts/shared-workbench/CHANGELOG.md now scopes the derived-intelligence plane against the
Spine promotion path; packages/projection-engine/ARCHITECTURE.md references the derived
knowledge plane instead of IQ Hub.

---

G-23 · Memory, continuity and reconciliation planes are contracted but never persisted — HIGH (new, 2026-09-04)

Canon: the founder records and Canon 6.1 make Organizational Memory, Personal Contextual
Memory and AI Continuity Memory three governed planes, with promotion, continuity runs and
reconciliation records as durable state (6.1 §19 ContinuityRun; final-architecture record §8).

Code: the surface contracts already bind the Workbench to these planes —
packages/contracts/src/surfaces/platform.ts:405-421 (memoryContinuitySurface) declares
primaryTable: spine_memory_items and supportingTables: spine_memory_candidates, spine_memory_promotions, spine_continuity_runs, spine_continuity_checkpoints, spine_continuity_episodes, spine_reconciliation_records, with governed commands
(memory.promote, authority human_approval); admin.ts references the same table family.
No migration creates any of them: a sweep of sql-migrations/ (including d1/) and
services/*/migrations finds no CREATE TABLE for this family. The continuity service types map
to a memory.* schema (memory.session_containers, memory.session_events,
memory.continuity_checkpoints) whose creation is likewise not in the migration tree.

Consequence: the Memory & Continuity surface is wired to tables that do not exist, so the
platform's memory/continuity/reconciliation story is presented in contracts while having no
durable state; promotion and reconciliation cannot be audited because their records cannot be
stored.

Required fix: add the migration set for the memory/continuity/reconciliation table family
(or reconcile the contract table names to wherever this state actually lives); wire
services/continuity and services/pipeline/src/memory-promoter.ts to the persisted tables; and
make spine_continuity_runs/spine_reconciliation_records the join points required by G-20.

Fix 2026-09-04 — PARTIAL. sql-migrations/084_spine_memory_continuity_reconciliation.sql
creates the full seven-table family in the 081 Neon style (spine.memory_items,
memory_candidates, memory_promotions, continuity_runs, continuity_checkpoints,
continuity_episodes, reconciliation_records), including the promotion-queue fields from the
final-goal record and the ContinuityRun join refs. Still open: runtime wiring of
services/continuity and the memory promoter onto these tables (they currently write
org_memory/memory_promotion_audit on the D1 edge), and Neon migration application.

---

G-24 · Governance outcome vocabulary and delegation outcome drift from canon — MEDIUM (new, 2026-09-04)

Canon: Governance has four outcomes — ALLOW, DENY, REQUIRE_APPROVAL, BOUNDED_DELEGATION
(Founder Canon §19; ADR-2026-09-04-01 flag set).

Code: packages/projection-engine/src/evaluators/governance-evaluator.ts:65,76,90,99 emits
decision: "blocked" | "approval_required" | "allowed"; services/govern/src/index.ts operates
on the same vocabulary. There is no denied outcome distinct from blocked and no
bounded-delegation outcome anywhere (BOUNDED_DELEGATION / bounded delegation: no matches in
services/govern, packages/projection-engine).

Consequence: governance decisions cannot express delegation-with-bounds, and the mismatch
between canon outcome names and code decision values makes policy review and audit mapping lossy.

Required fix: align the decision vocabulary to the four canon outcomes (or version the
mapping explicitly in a contract), and implement BOUNDED_DELEGATION for capability invocation
under delegated authority.

Fix 2026-09-04 — CLOSED. packages/capability/src/governance.ts now resolves to
allowed | denied | approval_required | bounded_delegation | blocked (canon four plus blocked
reserved for integrity/availability non-resolution, documented at the type). Explicit policy
refusals (blockedCapabilityIds, blockedRiskThreshold) emit denied;
PolicySnapshot.delegatedCapabilityIds implements BOUNDED_DELEGATION — a non-human actor with an
explicit capability-scoped delegation executes without an approval token, while explicit refusal
still wins over delegation. authorization.ts refuses denied (decision_denied) and the
projection-engine evaluator projects policy-denied capabilities as denied. Tests updated and
extended (denied, bounded delegation, denial-beats-delegation); capability 50/50,
projection-engine 54/54.

---

G-25 · Agent-roster documentation references a Coworker implementation that no longer exists — MEDIUM (new, 2026-09-04)

Canon: ADR-2026-09-04-03 restores Coworker as a distinct concept — the contextual
companion that helps assemble active context and communication, not a second orchestration
authority (superseding the G-03 retirement annotation).

Code: packages/skills/src/agent-roles/SKILL.md:5,24,235,457 documents a "Coworker Agent"
and points to services/iw-agent-runtime/src/agents/coworker-agent.ts; that file does not exist —
the agent directory holds adaptive-autotuner-agent.ts, collaboration-log-agent.ts,
discovery-agent.ts, schema-agent.ts, triage-agent.ts, and
services/pipeline/src/memory-promoter.ts:96 records the rename ("coworker" legacy marker —
class renamed to CollaborationLogAgent).

Consequence: with Coworker restored at the founder level, the runtime has no Coworker actor
under that name, and the skills documentation routes contributors (and agents) to a path that
404s. Context-assembly companion behavior is either scattered or mislabeled.

Required fix: reconcile the agent roster with the restored canon concept — either restore a
Coworker agent (context-assembly companion role) in iw-agent-runtime or rename the
CollaborationLogAgent role explicitly; update packages/skills paths and the type union to match
reality.

Fix 2026-09-04 — PARTIAL. packages/skills/src/agent-roles/SKILL.md now points at
collaboration-log-agent.ts, documents the rename and the ADR-2026-09-04-03 restoration. Still
open: a dedicated Coworker actor (context-assembly companion) in iw-agent-runtime — the
Collaboration Log Agent currently carries the behavior under the old name.

---

Verified alignment strengths (2026-09-04)

Recorded so gaps are read in context:

• Hermes implements the execution law — services/hermes/src/index.ts: executes only
  already-authorized AuthorizedExecutionCommands, verifies tenant/workspace/actor match, plan
  immutability, governance decision validity/expiry, capability/tool-capability/connection match,
  approval token, replay/idempotency; never writes canonical truth (outcomes promote through the
  Pipeline); exposes projectionInvalidationKeys and isPresentableAsComplete.
• Projection-binding registry exists in practice — ~30 SurfaceBackendContracts across
  packages/contracts/src/surfaces/ bind route → projectionId → primaryTable →
  supportingTables → governed commands (capability, authority, governanceRequired);
  services/projection/src/manifest-loader.ts loads projection manifests;
  packages/projection-engine/src/ has assemblers/enrichers/evaluators/resolvers;
  sql-migrations/082 adds product.domain_workbench_bindings and RBAC projection views.
• Storage planes are wired — Valkey (services/context-fetch, services/knowledge,
  services/intelligence), Vectorize (services/connector, services/loader,
  services/intelligence), R2 (services/admin, services/connector-sync, services/hermes,
  services/context-fetch, services/folder-watcher, services/intelligence).
• Creamy/breadth hydration exists in packages/connectors/src/sync-adapters.ts, matching the
  founder Architecture Flow record's onboarding doctrine.

---

G-29 · An orphaned surface still exposes four literal context-action buttons outside the governed path — HIGH · FIXED 2026-09-04 (new, 2026-09-04)

Canon: §3A — the four context actions are ambient affordances bound to a specific owner, never
a persistent toolbar: "the interface never exposes four literal global controls"
(ADR-2026-09-01-01).

Code:

• apps/web/components/workbench/department-workbench.tsx:237-266 renders a sticky footer grid of
  four literal Observe / Orient / Decide / Act buttons — exactly the anti-pattern.
• apps/web/components/workbench/workbench-router.tsx:183-186 wires onOODAAction to a bare
  console.log — no ContextActionSlot, no governance decision, no proposal, no approval, no
  reconciliation. Same class as the closed G-11.
• The router itself is orphaned: zero usages of WorkbenchRouter outside its own file (verified
  2026-09-04 at the UI-alignment pass).

Consequence: a copy-paste-ready ungoverned four-button pattern sits in the component tree; the
next surface builder can inherit it as if it were an approved pattern.

Required fix: delete the orphaned workbench-router + department-workbench pair, or rebuild
it against ContextActionSlot with the actions surfaced per-owner. Do not ship the literal
toolbar anywhere.

Fixed (2026-09-04, later the same day): deletion chosen, following the G-11 precedent. Deleted
in one commit:

• The G-29 pair plus seven more orphaned files in apps/web/components/workbench/
  (five-zone-shell, ooda-buttons, entity-detail, entity-grid, lifecycle-view,
  store-spine-modal, twin-signal-feed) — all with zero importers (verified 2026-09-04).
  action-ledger, dashboards, role-based-workbench, workbench-shell remain: they are the
  only files still imported (solely by components/_deprecated/**).
• A live sibling of the same class, found during deletion prep:
  apps/web/app/workspace/sales/page.tsx rendered the four literal action buttons
  (Store in Spine / Ask your Twin / Assign Your Twin / Approve Twin's Action) via
  components/workspace/ooda-buttons.tsx, plus an ungoverned four-button row inside
  sales-workbench.tsx — with fake-governance modals (hardcoded demo data, no ContextActionSlot,
  no receipts). The route had zero inbound links (not in nav or landing surfaces), so it was
  unreachable; the page and its three components were deleted.

Addendum (2026-09-04, all-apps re-sweep): one more live sibling, in the platform app —
apps/platform/components/home/command-rail.tsx rendered the same four literal OODA buttons
(OODA control grammar) on the platform shell home. Deleted, with its import/usage removed from
app/(shell)/page.tsx, a dead fourButtons import removed from app/(shell)/agents/page.tsx,
and the OodaAction/fourButtons/oodaPhase data model removed from apps/platform/lib/data.ts.
Zero OODA references remain in apps/platform (verified 2026-09-04).

---

G-30 · UI surfaces spoke the pre-canon vocabulary — MEDIUM · PARTIALLY FIXED 2026-09-04 (new, 2026-09-04)

Canon: §1 (SpineWorkspace is the product; IntegrateWise is the company/infrastructure), §3
canonical vocabulary and drift watch, ADR-2026-08-31-01.

Fixed in the 2026-09-04 UI-alignment pass:

• apps/workspace/src/app/page.tsx:137 — "customer-facing IntegrateWise product" → "customer-facing
  SpineWorkspace product".
• apps/web/app/login/page.tsx:83 and apps/one-access/src/app/page.tsx:15 — sign-in h1 presented
  the product as "IntegrateWise" → now "SpineWorkspace" (company marks such as the iW logo and
  one-access sign-in/sign-up logos retained as company attribution).
• apps/web/components/views/settings-view.tsx:695,700 — "Clear Twin Memory" → "Clear AI Continuity
  Memory" (canon §3 drift watch).
• apps/web/lib/twin-handoff.ts / apps/web/components/l1/personal/hub-home-view.tsx:21,152 —
  openTwinWorkbench() renamed openAIWorkbench(); the integratewise:twin-context event string
  was intentionally left stable (no in-repo listeners found; avoid breaking unknown consumers).

Still open:

• "AI Workbench" appears zero times in any UI. The canonical second Workbench is unnamed on
  screen while Twin-labelled code carries its role. Whichever surface becomes the AI Workbench
  entry point needs its canonical name.
• WIG anti-pattern inventory — cleared 2026-09-04 (all-apps design-system sweep): all 251
  transition-all uses converted to transition (bounded property lists) across apps/*; 78
  focus-visible outline repairs applied to interactive fields (web, platform, platform-console —
  the latter using its --iw-ring convention); 8 transition: all CSS rules expanded to explicit
  property lists (spine-theme.css in marketing and web, landing-page styles.css). Two upstream
  shadcn sites (components/ui/tabs.tsx, components/ui/input-otp.tsx) and two marketplace fields
  with existing focus:border-primary indication intentionally left as-is. Typechecks pass
  (web, platform, platform-console, workspace).

Required fix: name the AI Workbench surface when it is built/promoted; keep new UI copy inside
the §3 vocabulary.

---

G-31 · Alignment spec and root agent instructions point at retired documents and a nonexistent app — MEDIUM · FIXED 2026-09-04 (new, 2026-09-04)

Code:

• apps/web/public/docs/architecture/CODEBASE_ALIGNMENT_SPEC.md:77,128 — names apps/live as the
  primary frontend ("User Workbench (primary)") and lists it under Frontend Apps; no apps/live
  exists in the repository (verified 2026-09-04).
• Root AGENTS.md — header still says "Current framing: 2026-08-25" and orders agents to read
  PRODUCT_FRAMING_LOCK.md first, which is stamped SUPERSEDED 2026-08-31 by
  docs/canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md.

Consequence: agents and contributors are routed to a superseded framing (Twin Workbench,
two-scope memory) as their first read, and the service-alignment plan references an app that does
not exist.

Required fix: update AGENTS.md to read order from the current canon (00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md, then the 6.1 suite) and correct the alignment spec's frontend table to the actual app set — or stamp the spec superseded if the live gap register has replaced it.

Fixed (2026-09-04):

• Root AGENTS.md — header now points at the Founder Canon as current authority; "Current
  framing" corrected to 2026-08-31; §2 read order is now Canon → gap register → ROADMAP →
  ARCHITECTURE_LOCK.md, with PRODUCT_FRAMING_LOCK.md and the other legacy architecture docs
  demoted to a lineage-only item ("treat any conflict with the Founder Canon as superseded").
• CODEBASE_ALIGNMENT_SPEC.md — stamped SUPERSEDED (2026-08-31) in the same day's docs pass,
  satisfying the spec half via the stamp option (the live gap register has replaced it).

---

G-26 · Pre-canon doctrine live in the public docs bundle and remaining product copy — HIGH (new, 2026-09-04, PARTIALLY FIXED)

Same class as G-22, in a scope G-22 did not cover. An apps/*-wide alignment sweep (2026-09-04)
found 70 documents under apps/web/public/docs/** and apps/docs/architecture/** still
teaching pre-canon doctrine — Twin Workbench, Twin Memory as a substrate, retired
positioning — with no supersession marker, served publicly by the web app. This is the surface
that presents the platform's own architecture story.

Code (fixed this pass):

• UI copy — four remaining "IntegrateWise"-as-product instances: apps/web/components/core/auth/login-page.tsx:99 (→ "Sign in to SpineWorkspace."), apps/one-access/src/app/layout.tsx:5-6 (title/description → SpineWorkspace), apps/web/components/core/site/landing-page.tsx:196 (hero alt text), apps/web/components/iw/config/platform-inventory.ts:149 (→ "SpineWorkspace shell").
• 70 pre-canon docs bulk-stamped with a uniform SUPERSEDED (2026-08-31) — lineage only banner linking to the Founder Canon and naming the known drift (ADR-2026-08-31-01/02). Excluded from stamping: */_archive/** and apps/web/public/docs/archive/** (lineage folders), already-stamped docs, and the two canon-aligned frozen docs architecture/FULL_END_TO_END_ARCHITECTURE_v1.md and architecture/ARCHITECTURE_LOCK_v2.md.

Still open:

• Banner contents are only stamped; the 70 documents' bodies still teach the retired model.
  Rewriting them into the canon model (or deleting them from the public bundle) is a dedicated
  documentation pass and must not happen silently.
• apps/mobile, apps/desktop, apps/connector, apps/auth, apps/activation were swept this
  pass and are clean — only legitimate company usage (publisher names, IntegrateWiseMobileClient
  class names) remains there.
• Metadata titles in the live /workspace surfaces ("Founder Dashboard", "Template Library")
  presented the product as "IntegrateWise"; fixed 2026-09-04 in the G-29 deletion pass →
  "SpineWorkspace".

Addendum (2026-09-04, all-apps re-sweep): three further pre-canon docs missed by the bulk
stamp are now stamped — apps/docs/architecture/GLOSSARY.mdx (with a drift note that the OODA
"control grammar" framing is retired — context actions are ambient per the canon),
apps/docs/architecture/TWIN_WORKBENCH.mdx, and apps/docs/architecture/TWIN.mdx (no H1; banner
inserted after frontmatter). One remaining product-name drift fixed: apps/workspace/src/app/layout.tsx
page title "IntegrateWise Workspace" → "SpineWorkspace"; and apps/web/app/capabilities/page.tsx
OODA prose reworded ("observe, orient, decide, act" → "from signal to governed action").

Required fix: a documentation pass that rewrites or prunes the 70 stamped lineage docs; until
then the banners prevent readers from treating pre-canon doctrine as authority.

G-27 · App UI tokens drifted off the Salesforce-blue design-language foundation — MEDIUM · PARTIALLY FIXED 2026-09-04 (new, 2026-09-04)

SPINE_DESIGN_LANGUAGE_V1.md §3.1 declares the base identity: Salesforce blue on white
(light #0176d3, dark #00a1e0), implemented canonically in
packages/design-system/src/foundation/tokens.css (--iw-primary and friends). The all-apps
token sweep (2026-09-04) found three apps hard-coding their own brand hue instead of consuming
the foundation:

• apps/web/app/globals.css — "Webflow-inspired cooler theme" with indigo
  oklch(0.55 0.18 265) primary/accent/ring/charts/sidebar tokens overriding the foundation
  it already imports.
• apps/platform/app/globals.css — same indigo palette, no design-system dependency at all.
• apps/docs/app/globals.css — literal copy of web's indigo theme ("mirrors apps/web"),
  no design-system dependency.
• apps/portfolio/app/globals.css — v2-style HSL vars with an indigo-leaning
  --primary: 223 67% 54%.

Fixed 2026-09-04: web light + dark blocks re-pointed (--primary, --primary-foreground,
--accent, --accent-foreground, --ring, --chart-1/2, --sidebar-* family) to
var(--iw-*) foundation refs, keeping local neutral surfaces; platform and docs gained the
@integratewise/design-system workspace dependency plus first-line
@import "@integratewise/design-system/styles.css"; and the same re-pointing
(--success oklch token left as-is); portfolio primary/ring re-hued to 207 99% 42%
(light) / 197 100% 44% (dark) and the accent family re-hued to match
(210 99% 26% foreground light, 197 90% 85% dark). Neutral surfaces (hue 250 oklch,
hue 211 HSL) intentionally retained per app.

Still open (deliberate sub-brand/legacy flags):

• packages/one-access-ui ships a distinct green sub-brand (--oa-primary: #1f6f43)
  consumed by apps/one-access-console and apps/auth. Not a drift — a bounded sub-brand —
  but it should be ratified in the design language doc before it spreads.
• apps/marketing landing page and apps/web spine-theme use warm-dark sand/gold surfaces
  that sit outside the Salesforce-blue identity; reconcile in a dedicated pass.
• apps/docs landing-page palette (forest-green/paper) likewise predates the design language.
• apps/web/styles/globals.css is an unused legacy neutral shadcn file unreferenced by code;
  delete in a cleanup pass.

Required fix: extend SPINE_DESIGN_LANGUAGE_V1.md to ratify (or retire) the green
one-access sub-brand and the warm-dark/forest-green marketing surfaces, then converge those
tokens; until then the four fixed apps now resolve brand color from the single foundation
source.

G-28 · apps/mcp-servers is an unwired skeleton that cannot build — HIGH · OPEN (new, 2026-09-04)

All-15-apps wiring-readiness verification (2026-09-04): 10 apps typecheck green, 13 apps
build green (12 Next builds + desktop electron-vite build). Two apps had no verification
harness; mobile was fixed, mcp-servers was not fixable in place:

• apps/mcp-servers has no package.json, so pnpm excludes it from the workspace and it
  has no install, typecheck, or build path. Its wrangler.toml points at src/index.ts
  (Cloudflare Worker, itty-router), and src/middleware/* is complete — but
  src/index.ts imports nine ./handlers/* modules (claude, openai, github, slack,
  postgres, brave-search, playwright, sentry, grafana) that do not exist: src/handlers/
  is absent entirely. The source cannot compile even with a manifest.

Fix required before MCP route wiring: decide whether mcp-servers is a deliverable. If
yes: restore/implement the handlers, add a package.json (wrangler + itty-router +
@cloudflare/workers-types, typecheck + deploy scripts) so it joins the workspace
build; if no: move it out of apps/* into an archive dir so the app count and readiness
matrix stay truthful.

Resolved in the same pass — mobile harness gap: apps/mobile (Expo 52) had no
tsconfig.json and no typecheck script, and shipped lib/supabase-provider.tsx, which
imported @integratewise/supabase/native — a package that exists nowhere in the monorepo —
and had zero importers. Deleted the orphaned provider (G-11/G-23 precedent), removed the
also-unused @supabase/supabase-js dependency, added tsconfig.json (expo/tsconfig.base,
strict) and a typecheck script. pnpm --filter @integratewise/mobile typecheck is now
green. Mobile still has no local build (EAS device builds are external by design);
desktop likewise verifies via electron-vite build only.

---

Gap register vs the Canonical Operating Model — 2026-09-04

Survey base: facd8b03 (main) — the commit that landed
01-SPINEWORKSPACE-OPERATING-MODEL.md,
18-CANONICAL-GLOSSARY.md and ADR-2026-09-04-04…13.
Method: Repository Archaeology Protocol
— every claim closed by reading the file it names; strict status labels; evidence-only, no
solutions. Entries use GAP- IDs (not G-) because the G-sequence is concurrently maintained by
other writers. Existing G- entries that already measure a requirement are cross-referenced
rather than duplicated.

ID	Canonical requirement	Current evidence	Status	Confidence	Risk	Dependency	Recommended next action
GAP-001	OneAuth is the single entry resolving identity, org, workspace, host identity, host connections, connector projections, plugins, MCP capabilities, activation policy	Auth exists (services/gateway/src/auth.ts, clerk-auth.ts, descope-auth.ts, oauth.test.ts); per-installation identity/workspace/consent in services/marketplace-installation/src/index.ts (state machine); versioned platform read contract with OneAuth law reference at services/gateway/src/platform-discovery.ts:225 — but no single resolution surface that also returns host connections, projection grants and activation policy	Partial	High	High	Identity boundary (G-01/Q-1)	Trace the gateway auth composition; design the OneAuth resolution response as one contract before host-entry work
GAP-002	Host-first capability routing: request classification, HostCapability (confirmed/declared/unknown), SpineCapability, route resolver with read/write precedence, ConnectionBinding	No matches for HostCapability, ExecutionRoute, RequestClassification, or a host-vs-spine precedence resolver anywhere in services/ or packages/; cascade discovery exists (packages/host-platform-connector/src/services/cascade-discovery.ts) and the capability package resolves provider routes, but neither implements host-first precedence or confirmed/declared availability	Absent	High	High	GAP-003, capability fabric	Design the route resolver against the existing @integratewise/capability resolution pipeline; do not bolt a second resolver beside it
GAP-003	Connector projections: per-workload projections (read/sync/search/event/approved-write) of host-owned connections carrying scopes, approval requirements, retention, classification, rate limits, revocation state; connection-reuse-first	platform.connector_connections (sql-migrations/081:56-77) carries provider, connection_ref, status, scopes, supported_capabilities, health — a connection record, not per-workload projection records; no retention/classification/per-projection revocation columns; no reuse-first activation flow evidenced	Partial	High	High	GAP-002, G-18, G-21	Extend the connection model with projection records and route the marketplace-installation binding stage through them
GAP-004	Activation Hub stages 3–4: connection activation creates projections; Activation Bridge compiles config + identity + connections + policy into an active workspace	An ActivationManagerClient exists and is invoked by cascade discovery (cascade-discovery.ts:27-37,144) and an ActivationManagerView ships in packages/platform-mfe/src/index.ts:47; no Activation Bridge (runtime compiler) evidence; services/schema-ai/src/index.ts offers /schema/adapt, /schema/generate, /schema/:tenant/lifecycle (compiler-adjacent)	Partial	Medium	High	GAP-001, GAP-003	Trace what ActivationManagerClient.startActivation actually calls before designing the bridge
GAP-005	Discovery Engine emits one workspace bootstrap contract (identity, workspace, connections, projections, plugins, MCP servers, tools, models, knowledge, memory scopes, role views, policies)	Discovery exists in pieces: services/schema-ai (infer/register/drift/adapt/generate/discover/lifecycle), discovery agent (services/iw-agent-runtime/src/agents/discovery-agent.ts with DiscoveredCapability kinds), MCP Pool GET /capabilities, cascade discovery — but no unified bootstrap-contract output consumed by onboarding	Partial	High	Medium	GAP-001	Compose the bootstrap contract from the existing discovery surfaces before inventing new ones
GAP-006	Spine Cache: policy-filtered, rebuildable, default agent read surface; Active Context Bundle with completeness level	services/pipeline/migrations/0007 creates operational_entity_cache, operational_projection_cache, operational_promotion_staging, operational_sync_receipts, operational_flow_log; services/context-fetch is the Gateway-only bounded Active Context Worker with ContextScope, EffectiveCapability, EvidenceBoundOutput, FreshnessSource	Implemented (read path)	High	Medium	G-21 freshness	Verify rebuildability and policy filtering end-to-end; wire freshness degradation into cache invalidation
GAP-007	ACP: agent ↔ agent / Twin ↔ agent governed handoff transport carrying Work ID, authority scope, correlation/causation	No matches for ACP or an agent-communication protocol in services/ or packages/; handoff machinery exists (services/intelligence/src/handoff/state-machine.ts, handoff_packages) but as DB state, not a transport with the canon envelope	Absent	High	Medium	G-20 (Work identity)	Defer transport design until Work identity exists — ACP carries Work IDs it does not create
GAP-008	Bridge message envelope: communication attached to Work with tenant, principal, Work ID, authority context, correlation/causation, provenance, sensitivity	No communication_type / Work-bound communication envelope in packages/context-contracts/src or services/context/src; communication content is ingested as Flow B context, not carried as governed Bridge messages	Absent	High	Medium	G-20, GAP-007	Model the envelope in packages/context-contracts alongside the Active Context types
GAP-009	Model profile resolver: stable profiles (fast, reasoning, code, specialized); no model version in the durable contract	packages/model-gateway/src/types.ts carries provider usage plumbing (reasoning_tokens details at :151); no profile abstraction in model-gateway or omni-router	Absent	Medium	Medium	—	Add the profile layer in the model gateway; keep vendor models behind it
GAP-010	UI auto-tuner proposes versioned projection patches; never rewrites components	Adaptive autotuner exists (services/iw-agent-runtime/src/agents/adaptive-autotuner-agent.ts — TuningRun targeting profile | prompt | model with outcome feedback); no projection-patch proposal path evidenced	Partial	Medium	Medium	ADR-2026-09-04-12	Route tuner proposals through the projection manifest versioning, not component edits
GAP-011	Standard tenant-table envelope: workspace_id, version, created_by, trace_id, correlation_id on tenant-owned tables	081 tables carry tenant_id/status/created_at/updated_at; spine.entities lacks workspace_id, created_by, trace_id, correlation_id; envelope concerns measured under G-17	Partial	High	High	G-17	Fold into the G-17 envelope migration rather than a separate pass
GAP-012	Spine Access Plane (scoped/redacted continuity for external hosts; Cache + Mirror internals) has persisted state	Surface contract binds primaryTable: spine_access_projections (packages/contracts/src/surfaces/spine-access-plane.ts); no migration creates spine_access_projections or spine-mirror tables — same contracted-but-unpersisted class as G-23	Absent	High	High	GAP-001, G-23	Author the access-plane migration alongside the G-23 wiring pass

Survey-positive findings: the versioned platform read contract (services/gateway/src/platform-discovery.ts:1-16 — PlatformResponse with contractVersion/traceId/freshness/state/provenance) and the Gateway-only Active Context Worker (services/context-fetch) implement the "frontend never touches a store" law; the operational cache family (pipeline 0007) gives GAP-006 its substrate; cascade discovery already invokes an Activation Manager (GAP-004 partial credit).

Deliberately not re-measured here: G-17–G-25 (earlier 2026-09-04 re-verification) and G-26–G-28 (concurrent writers) stand as dated measurements at their own stamps.