WHY CONTEXT DISAPPEARS
AI prototypes often preserve output but lose the reasons behind it.
The interface may look convincing while requirements, architecture choices, provider dependencies, known failures and ownership remain scattered across prompts and temporary sessions.
Continuing without reconstructing this context can multiply technical debt and make every later decision harder.
COLLECT THE SOURCES
Gather the material that can explain the current state.
Collect the product brief, screenshots, URLs, decisions, issue lists, architecture notes, provider inventory, observed behaviour and authorised repository context. Record where each item came from and whether it reflects current behaviour.
Do not expose credentials, private keys or unauthorised client data in an unapproved intake channel.
CONTEXT RECOVERY MAP
Prototype Context Recovery
- Repository contextSupplied repository context or authorised repository review
- PromptsSupplied conversational history
- DocumentsBriefs, notes and generated records
- ScreenshotsObserved interface evidence with limits
- DeploymentsSupplied URLs and observed behaviour
- DecisionsAccepted choices and unresolved conflicts
- Observed fact
- Supplied claim
- Assumption
- Conflict
- Missing information
- Classify truth
- Project Model
- Next Build Specification
FACTS, CLAIMS AND ASSUMPTIONS
Treat demonstrations and generated documentation as evidence with limits.
An observed feature, a developer statement and an AI-generated repository summary are different kinds of evidence. Record what was directly observed, what was supplied as a claim and what remains an assumption.
Conflicts should remain visible until a responsible review resolves them.
FORM THE PROJECT MODEL
Build one accepted representation of the product and its current state.
The Project Model should contain the product intent, users, scope, architecture, sources, decisions, risks, known behaviour, unresolved issues, ownership and current release state.
This becomes the basis for planning rather than the previous tool’s conversational memory.
CHOOSE THE RIGHT CONTINUATION PATH
Stabilise, repair, rebuild, clarify or continue.
The correct decision depends on product fit, evidence quality, architecture, implementation condition, operational risk and ownership. A partially working prototype may need a stabilisation phase before new features, or it may be faster and safer to rebuild a bounded part.
Record the recommendation, alternatives, confidence and evidence still required.
CREATE THE NEXT BUILD SPECIFICATION
Make the next change small enough to approve and verify.
Define the intended outcome, included and excluded work, dependencies, provider boundaries, acceptance criteria, ownership targets and evidence expected from implementation.
A versioned Build Specification gives the next agent or developer a project-aware contract instead of another open-ended prompt.
EXECUTE, VERIFY, PREVIEW AND CONTINUE
Execute, verify, preview and continue
The active Control Plane programme is establishing the Project Model, Work Items and task experience. Bounded execution, independent verification, Tested Preview and continued development follow through the approved roadmap.
These stages are not presented as available in the current product.
existing-project context, assessment, risk, recovery and handoff structure
Project Model, Source Inbox direction, Work Items and task experience
bounded execution, independent verification and Tested Preview