ONE MEMORY · MULTIPLE RESPONSIBILITIES
Built before go-live.
Useful long after it.
The target workflow begins while the FDE can still verify the system. Go-live would change who owns the responsibility—not which memory the participants rely on.
Target lifecycle. The Local Workbench and most solution experiences are planned; System Blueprint is prototype-only.
Product lifecycle
- 01
During delivery
Build the memory while the evidence is close
The intended workflow turns repository evidence, decisions, safe probes, and declared limits into an inspectable record before context disappears.
blueprint · decisions · bindings · baseline - 02
Go-live
Cross the line with a dated snapshot
In the target workflow, go-live is a handoff boundary: the delivery-time memory and its unknowns would already be visible.
coverage · limitations · verification state - 03
Ownership transfer
Package evidence and responsibility
Handover material, open gaps, and owners would be assembled from the same source instead of copied into a disconnected deck.
handover pack · owner record - 04
After go-live
Operate answers and freshness
Planned operated services use that memory to answer known questions, route unknowns, and prepare knowledge updates for review.
answer record · freshness review - 05
Across the practice
Govern responsibility, not production health
A planned fleet view surfaces stale knowledge, unanswered questions, and missing owners across delivered systems.
portfolio governance summary
THE CONTINUITY MECHANISM
The artifact does not change identity when the engagement ends.
In the intended workflow, the same prototype blueprint referenced in handover could ground a later answer. A planned binding could connect a runbook to a prompt and identify what a change affects. The declared limitation would remain visible after go-live.
That continuity is the product: not twelve disconnected tools, but one inspectable record used by different responsibilities over time.