This is the version I want to preserve privately because it keeps more of the product reasoning intact than a public-facing post should.
The core judgment is simple:
- Prism can still be a long-term search and adjudication layer
- Prism should begin as the spec layer for AI coding agents
Those two statements are not in conflict. One is the north star; the other is the wedge.
Why this reduction feels correct
The main reason is frequency. Branching, comparison, and rubric-driven choice matter, but they are not present in every task. By contrast, task shape, constraint retention, and explicit completion criteria matter in almost every meaningful coding run.
In practice, the user pain is rarely phrased as:
"I need a better multi-path decision workspace."
It is much more often phrased as:
- the agent went off track
- it forgot a key constraint
- I cannot tell whether the result answers the task
- the task state is muddy after twenty minutes of execution
- completion is being judged by vibe rather than criteria
That makes the wedge more obvious. The immediate missing primitive is not adjudication. It is task discipline.
The strongest line so far
The line that still feels most right is:
Prism does not start from chat history. It starts from a task contract.
The reason this works is that it names the actual break from the current tool landscape. Most AI coding tools still use the chat thread as the main container for meaning. The agent runs "within" the thread, but the task itself never becomes a stable object with its own structure and state.
If Prism can make the task first-class, it already becomes different in a way that users will feel.
Why "Spec Card" is not enough
"Spec Card" is a helpful starting label, but it is slightly too static.
What matters is not just a spec-shaped object. What matters is a live contract that spans the whole workflow:
- intake
- planning
- execution
- verification
- completion
- reopen and rework
The language I want to keep using internally is therefore Live Task Contract.
That contract should minimally include:
- Task
- Goal
- Constraints
- Non-goals
- Acceptance criteria
- Risks
- Execution state
- Open questions
- Verification checklist
- Outcome note
Among those, the fields that do the most practical work are probably:
- Constraints
- Acceptance criteria
- Execution state
Goal matters, but those three fields do more to keep the system from drifting.
The post-reduction risk
The main new risk after this reduction is not heaviness. It is superficiality.
If Prism becomes "a place where you structure your prompt into fields and then launch an agent," it will slide into being a prettier PRD form for AI.
That is not enough.
For the task contract to actually matter, it needs four properties:
1. Auto-generated first
The user should not have to start from a blank structured form. Prism should derive the first version from natural language, repo state, issue text, logs, and surrounding context. The human's job is to correct and approve, not to author from scratch every time.
2. Live, not static
The contract should update when new information appears. Unknown constraints, new risks, blocked states, and verification findings should be able to amend the contract. Those edits need provenance and reason, not silent mutation.
3. Execution-bound
The agent's plan, progress, status, and changes must stay explicitly mapped back to the contract. The spec cannot just sit on the side while execution happens elsewhere.
4. Verification-bound
Completion should be judged against explicit acceptance criteria and a concrete verification checklist. Otherwise the system drifts back to "seems done."
Without these four properties, Prism may look more disciplined than chat while still behaving like chat under the hood.
Layering still makes sense
The current layered framing still feels right with only slight wording changes.
Core layer
- Task object
- Live task contract
- Execution state
- Verification checklist
This is the layer that should define V1.
Advanced layer
- Branching
- Strategy divergence
- Evidence view
- Rubric / decision mode
This is where Prism can grow back into its original ambition, but now on top of something more stable than a conversation log.
Learning layer
- Outcome notes
- Reopen / rework tracking
- Which specs, agents, and strategies succeed most often
This is the layer that turns isolated runs into accumulated product knowledge.
The most important reframing is that branching is not being removed. It is being moved to a healthier position in the stack.
What V1 should actually include
If I were forced to choose the smallest serious V1, it would be:
- natural language task intake
- automatic first-pass contract generation
- quick human edit and approval
- execution bound to the contract
- progress and changes mapped back to the contract
- completion through a contract-derived verification checklist
That is a narrow product, but it is not a trivial one. If done well, it solves a real coordination problem between people and agents.
The deepest product claim
The sharpest phrasing I have right now is this:
Prism should not initially sell itself as a system for comparing multiple AI answers. It should first become the system that gives AI coding tasks a real task contract.
That is a more grounded claim and a better entry point.
It also leaves room for the original north star. Once task contracts exist, branching, evidence, and adjudication become easier to justify and easier to use. Without task contracts, those higher-order capabilities risk floating above a messy substrate.
So the conclusion I want to keep is not "Prism is smaller now."
It is:
Prism is becoming more first-order.