Skip to main content

Knowledge Layer — Work Record

Intent​

A vendor-neutral knowledge/memory layer inside the agent orchestration platform, so Justin's data stays his across harnesses — Muse, ChatGPT, Gemini, Claude, and Hermes — instead of being re-moved and re-explained at every vendor switch. The layer is the platform's memory: one store, governed by fleet primitives, served to machine-grounded agent clients only.

  • Opened: 2026-10-09, at Justin's direction.
  • Tracked goal: knowledge-layer-for-the-agent-orchestration-platform.

The model (Justin's design, 2026-10-09)​

  • North–South axis — lifecycle tiers. Working → short-term → long-term → archive. Items are curated southward by the sweeper as they age and cool.
  • East–West axis — governance ↔ surface. West: the governing primitives and rules. East: an AI-friendly store/retrieve surface the harnesses consume.
  • Z axis — compartments. Access boundaries that cut through every tier (precedent: the divorce material's firewall). A compartment is a boundary, not a tier.

Rulings of record (Justin, 2026-10-09)​

  • Clients are machine-grounded agents only — Muse, ChatGPT, Gemini, Claude, Hermes. No web surfaces.
  • One adaptable item model with types — a single item shape carries every kind of knowledge; the type field, not separate stores, distinguishes them.
  • Tier ladder — driven by ontology links to active projects plus last access: demote at 14 days unaccessed → short-term, 28 days → long-term, 60+ days → archive; a 7-day freshness ring inside working; a touch resurrects an item northward.
  • Admission to long-term is gated by the chief of staff, who escalates to Justin when a call is undecidable.
  • Hard deletion is a primitive only Justin authorizes — the archive tier is the floor for everyone else.
  • Retrieval is search and questions, plus a working-set brief.
  • Build for the current estate, expandable later.

Recommendation on record (chief of staff)​

One self-hosted Postgres (+ pgvector, full-text, JSONB) as the system of record; the east surface is an MCP server. Neo4j is deferred behind a named trigger. Supabase Cloud is rejected under the no-third-party rule (no fleet data to third-party services).

Status​

Specification APPROVED and published (2026-10-10). The finalized spec stands at docs/03-projects/knowledge-layer/ spec.md in this docsite (approved by Justin 2026-10-10; all four open decisions approved as recommended — see the log). Phase 1 (KL-01..KL-08, 52 points) is groomed and being filed onto the agent-orchestration board under the initiative's own work lane, drawing on the four-worker bench in parallel with the AF program. This record is the initiative's living record and is kept current by the sweeper as work lands.

The work lane (owner direction, 2026-10-10)​

"Now that we have more workers, I'd like to have a work lane for the knowledge layer too." The Knowledge Layer runs as its own lane in the fleet pipeline: the planner grooms, the chief approves, the scrum master files and dispatches, the worker bench builds, §3 review gates as usual. Phase 1's dependency spine: KL-01 (item model + Postgres store) → KL-02 (search/ ask) → KL-03 (MCP surface) → KL-04 (brief composition); KL-05 (tier ladder + sweeper pass) on KL-01; KL-06 (the long-term gate) on KL-05; KL-07 (compartments + firewall) on KL-01 + KL-03; KL-08 (seeding) on KL-01 + KL-06.

Decisions (owner, 2026-10-10 — all four approved as recommended)​

  • Host = the owner's Azure host, created by fleet-built automation — history, all 2026-10-10: jkdev001 was approved, then amended by the owner ("I'm going to add another host in azure for this") to an owner-provisioned Azure host, then amended again ("Add the azure automation for creating the host to the build process") — the host is created by fleet-built provisioning automation as part of the build (lane story KL-01a). The host of record is the automation-built Azure host. (This gated KL-01's build start; KL-01's build is ungated, its on-host verification follows KL-01a.)
  • Hermes write access = read-only start — brief, search, get, promote; store/link enabled per harness once earned (scoped KL-03's Hermes criteria).
  • Deletion tombstones = kept — content-free (item id, type, deletion date), so the provenance audit trail stays unbroken (touches KL-09, Phase 2; carried on the epic).
  • Conflict rule = the spec's §4 rule — contradictions stand linked in the hot tiers, surface in retrieval, and resolve at the chief's long-term gate (gated KL-06's mechanics).

Log​

  • 2026-10-09 — Initiative recorded (owner rule: the project record is the first step). Justin directed the initiative and gave the model and the rulings of record above; the chief of staff's storage/surface recommendation is recorded with them. Record opened by maverick-muse-sweeper-001 on the chief of staff's dispatch. Product specification drafting dispatched to the planner in parallel.

  • 2026-10-10 — Spec approved and published; lane opened. Justin directed a dedicated work lane for the initiative (2026-10-10). Phase 1 was groomed by the planner from the spec of record (KL-01..KL-08, sizes as spec'd; the spec's §13 total corrected to 52 at finalization), the groomed set's four grooming questions were resolved by the chief from standing decisions (Gemini's target is the Gemini CLI; document bodies are reference-only where a canonical home exists; the embedding model is the builder's choice within the spec's constraints; ChatGPT verification binds against the Codex harness, with no web fallback), and the set was handed to the scrum master for filing under the KL lane. Justin then approved the spec and all four of the chief's recommendations ("Approve all four recommendations", 2026-10-10): host jkdev001; Hermes read-only start; tombstones kept (content-free); the §4 conflict rule adopted. The planner finalized the spec the same day (status APPROVED, decisions recorded in its §12, the four rulings' consequences flowed into §§4, 7, 8) and published it beside this record at docs/03-projects/knowledge-layer/ spec.md (docsite commit 2b68de39fb85; prepublish validation 0 errors). Publication closes the spec phase; build starts under the lane on the scrum master's dispatch. under the lane on the scrum master's dispatch.

  • 2026-10-10 — Host amendment (owner), same day. Minutes after the four approvals, Justin amended the host decision: the layer's host of record is a new Azure host he is provisioning for it, superseding jkdev001 (approved earlier the same day). The sequence of record is approved-jkdev001 → amended-to-Azure, both dated 2026-10-10. The planner's correction pass carried the amendment into the published spec (§§8, 12 — docsite commit 3536383867e0), this record, and the groomed set's KL-01 annotation. Everything else in the finalization stands (Hermes read-only start, tombstones kept, the §4 conflict rule, the 52-point total). kept, the §4 conflict rule, the 52-point total).

  • 2026-10-10 — Second host amendment (owner): the host's creation joins the build. Justin directed that the Azure automation for creating the host be added to the build process — the host is not hand-provisioned. The planner groomed it as lane story KL-01a (Azure host provisioning automation, 5 points, ahead of KL-01's on-host work) into the groomed set; a security consult on the provisioning design was dispatched in parallel, and KL-01a's security passages fold in its posture before the set is called ready. The published spec's host passages were updated the same day (the jkdev001 approval and the hand-provisioning amendment both superseded in sequence, dated).

Host re-evaluation opened (2026-10-10, owner direction). The owner asked whether Azure container services could host the KL instead of the Azure VM, and then reopened the hosted-Supabase option the earlier recommendation had set aside: he is not opposed to Supabase ("it's secure and a lot of people use it") and named its free tier as a possible start. A costed Azure-vs-Supabase comparison (including the Container Apps + Flexible Server variant of the Azure side, and the fact that Supabase replaces only the database leg — the MCP server still needs a small host in both worlds) was delivered to the owner in the Sweeper desk on 2026-10-10. The host decision is OPEN again pending the owner's pick; the VM-shaped security postures are held, not extended, until it lands.

Host decision — HYBRID (2026-10-10, owner, final). The owner picked the hybrid shape the same day. Supabase hosts the database ONLY (Postgres + pgvector + JSONB), starting on the free tier (500 MB; the inactivity pause is mitigated by the fleet's daily touch cadence) and moving to Pro ($25/mo: 8 GB, no pause, daily backups) when warranted. Azure hosts everything that runs: the MCP server on Azure Container Apps with a Tailscale sidecar, so agent access stays tailnet-only, and the tiering/promotion jobs as scheduled Container Apps Jobs (~$0–10/mo at this scale). The Supabase credentials are held only by the Azure-side workloads, in Azure-side secret storage — never issued to agent callers; per-caller MCP tokens and the divorce-compartment gate at the MCP layer are unchanged. The MCP-to-database leg crosses the public internet over TLS via the Supabase pooler — the one deliberate exception to the tailnet-only posture, accepted by the owner knowingly. Exit path preserved: the database is plain Postgres, so repointing the Azure side at an Azure Flexible Server moves the data home without touching the agent-facing layer. The Azure VM host decision (B4ms plan) and its automation lane story are SUPERSEDED — the lane re-cuts to Container Apps + Supabase provisioning, and the security consult re-runs on the hybrid shape (the VM-shaped postures do not transfer verbatim).

Record opened by maverick-muse-sweeper-001 · 2026-10-09; updated by maverick-muse-planner-001 · 2026-10-10; host re-evaluation noted by maverick-muse-sweeper-001 · 2026-10-10.