docs: add v0.5 release notes
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
# v0.5 Release Notes
|
||||
|
||||
## Purpose of v0.5
|
||||
|
||||
v0.5 stabilises the graph-backed one-turn update flow so the engine can resolve an answered unknown, surface consequential new unknowns, prioritise the next unknown deterministically, and formulate a deterministic follow-up question without changing the UI or adding more model turns.
|
||||
|
||||
## Capabilities proven
|
||||
|
||||
v0.5 includes:
|
||||
|
||||
- resolving an existing unknown
|
||||
- surfacing consequential new unknowns
|
||||
- limiting emergent unknowns
|
||||
- deterministic information-value prioritisation
|
||||
- deterministic question formulation
|
||||
- generalisation across five decision types
|
||||
- graph-backed one-turn UI update
|
||||
|
||||
## Five-case generalisation result
|
||||
|
||||
All five deterministic fixture scenarios passed:
|
||||
|
||||
1. Should we hire another engineer?
|
||||
2. Should we replace the delivery vans?
|
||||
3. Should we launch in another country?
|
||||
4. Should we continue a project that is over budget?
|
||||
5. Should we introduce a paid support tier?
|
||||
|
||||
The selector chose a foundational unknown first in each case, avoided the downstream leaf first, required no model call, and preserved graph immutability during question formulation.
|
||||
|
||||
## Key deterministic safeguards
|
||||
|
||||
- proposal application re-selects the active unknown deterministically after validation
|
||||
- information-value scoring penalises downstream or prerequisite-blocked unknowns
|
||||
- emergent unknown validation limits additions and requires explicit answer-derived linkage
|
||||
- final question wording is reformulated from graph context without an extra model turn
|
||||
- question validation rejects compound, awkward, or pricing-led fallback phrasing
|
||||
|
||||
## Known limitation
|
||||
|
||||
A correctly selected threshold node can still be phrased using an actor/customer strategy when surrounding graph context strongly references customers or value recipients.
|
||||
|
||||
This limitation is recorded for the next experiment and is not being fixed in the v0.5 release-prep task.
|
||||
|
||||
## Deliberately excluded work
|
||||
|
||||
- no reasoning-logic expansion beyond the small deterministic formulation fixes already landed on the branch
|
||||
- no new features
|
||||
- no UI changes
|
||||
- no persistence
|
||||
- no additional model turn
|
||||
- no Ollama calls for validation
|
||||
- no evaluator-suite runs
|
||||
- no Playwright runs
|
||||
|
||||
## Next experimental question
|
||||
|
||||
Can the question formulation strategy remain aligned with the selected node's role when surrounding graph context contains competing signals?
|
||||
Reference in New Issue
Block a user