State Model Round 1 - AFPS Tracker
Stage-zero interrogation for the flow-anchored logical model that will sit between the approved AFPS Tracker user-flow map and UX variation work.
Table Of Contents
Context Snapshot
Primary flow nodes in play: `uf-orient-portfolio`, `uf-verify-selected-path`, `uf-inspect-source-provenance`, `uf-recover-diagnostics`, `uf-handoff-resume`, and `uf-explain-boundaries`.
Assumptions Manifest
| Assumption | Source | Your decision | Correction or flag notes |
|---|---|---|---|
| AFPS Tracker models product-path workflow state, not generic project-management tasks. | [from positioning] | ||
| The canonical source of product-path truth remains AFPS files such as `research/.progress.yaml`, scoped research docs, alignment pages, and archives. | [from user-flow] | ||
| The core stateful subjects are product paths, source artifacts, evidence links, provenance records, diagnostics, and handoff summaries. | [inferred from flow] | ||
| Path states must include active, archived, deferred, revisit-candidate, promoted, out-of-scope, unresolved, warning, blocked, and partial interpretations. | [from flow-tree and user-flow] | ||
| Diagnostics should degrade trust at source, claim, path, and handoff levels rather than hiding partial source-backed value. | [from user-flow] | ||
| Write-back, storage choices, endpoint shapes, auth, migrations, indexes, and deployment decisions must be deferred to later specification work. | [from state-model constraints] | ||
| Promoted development/execution work remains outside AFPS Tracker and should hand off toward the separate `exec-loop-tracker` concept when source state supports it. | [from journey and user-flow] |
Detected Framework Direction
The first-pass detection points to a chunked multi-framework model because the approved flow is stateful, provenance-heavy, diagnostic, and contract-rich.
| Framework | Default stance | Why |
|---|---|---|
| event-modeling | Lead | Best fit for ordered scan, resolve, inspect, validate, and handoff events across the flow. |
| domain-model | Always include | Needed to define product paths, evidence refs, diagnostics, provenance records, and handoff summaries as stable logical objects. |
| state-machine | Early | Path, source, diagnostic, provenance, and handoff lifecycles carry trust-critical status transitions. |
| data-model | After conceptual passes | Needed for the logical ERD and relationship/cardinality clarity, without choosing physical storage. |
| contract-map | Last | Needed to stabilize command/query request, response, and error shapes after entities and states settle. |
| event-storming | Optional | Useful only if AFPS vocabulary remains unsettled after this round; current research vocabulary is fairly mature. |
Open Questions
Framework Set And Run Order
Should the default framework order stand, or should any framework be added, removed, or reordered?
Recommended: use `event-modeling`, `domain-model`, `state-machine`, `data-model`, and `contract-map` in that order; skip `event-storming` unless you want a vocabulary reset.
Use event-modeling, domain-model, state-machine, data-model, and contract-map in that order. Do not run event-storming unless later answers reveal unsettled vocabulary. Agent confidence: mediumDomain Vocabulary
Which terms should the model preserve exactly, and which terms feel wrong or ambiguous?
Recommended: preserve `product path`, `active path`, `evidence ref`, `alignment provenance`, `diagnostic`, `handoff summary`, `promoted boundary`, and `source-backed claim`; scrutinize `parser confidence` versus `source confidence`.
Preserve product path, active path, evidence ref, alignment provenance, diagnostic, handoff summary, promoted boundary, and source-backed claim. Clarify whether parser confidence and source confidence are separate terms. Agent confidence: mediumStateful Subjects And Lifecycles
Are there stateful subjects or lifecycle states missing from the default model scope?
Recommended: model lifecycles for product path, source artifact, evidence link, provenance record, diagnostic issue, and handoff summary. Treat repository scan as an event/read-model process, not the central aggregate.
Model lifecycles for product path, source artifact, evidence link, provenance record, diagnostic issue, and handoff summary. Treat repository scan as an event/read-model process rather than the central aggregate. Agent confidence: mediumCommand And Query Boundary
Which user/system actions must become logical command/query contracts for UX variations to rely on?
Recommended: include scan portfolio, select product path, inspect evidence, inspect provenance, evaluate diagnostics, generate handoff, copy handoff, and explain boundary as logical contracts.
Include scan portfolio, select product path, inspect evidence, inspect provenance, evaluate diagnostics, generate handoff, copy handoff, and explain boundary as logical command/query contracts. Agent confidence: mediumPhysical Concerns To Defer
What implementation concerns are tempting but should be explicitly deferred out of this logical model?
Recommended: defer database/storage choices, file watcher mechanics, endpoint URLs, auth/permissions, migrations, indexing/search implementation, sandbox details, and deployment.
Defer database/storage choices, file watcher mechanics, endpoint URLs, auth/permissions, migrations, indexing/search implementation, sandbox details, and deployment to later specification work. Agent confidence: highRiskiest Modeling Assumption
What model assumption would most damage UX variation work if it is wrong?
Recommended: the riskiest assumption is that product path is the main aggregate root; if diagnostics or source artifacts are actually primary, the model and UX branches may organize around the wrong object.
The riskiest assumption is that product path is the main aggregate root; if diagnostics or source artifacts are actually primary, the model and UX variations may organize around the wrong object. Agent confidence: lowCompile Responses
Answer what you want to change, then compile and paste the YAML into a fresh or current agent session.