The forks, handled as records rather than conversations.

Which stack, which service boundary, which cutover pattern. The platform presents two to four real options, recommends one with reasoning, and then makes the choice bind everything downstream.

Authority
The user decides. The platform recommends, explains and blocks
Grounding
Effort and risk estimated from your model, not from industry averages
Reversal
Allowed. Derived artifacts are flagged stale, never silently rewritten

Seven things every option has to state.

A comparison that omits any of these is a preference dressed as an analysis.

01What it is, in one sentenceReadable by someone who will not implement it
02Effort, grounded in the modelSymbol counts, dependency depth, rule count
03Rules at riskHow many extracted business rules need a hand rewrite
04Resulting technical debtWhat this choice leaves behind for the next team
05Operational cost implicationWhat it costs to run, not just to build
06Team capability fitIncluding the hiring pool reality, stated plainly
07ReversibilityHow expensive it is to be wrong about this
A recommendation, with its reasoning attached

Tied to your evidence, not to a vendor's preference.

The platform names its choice and shows the counts it rests on. Rules at risk is usually the number that decides these arguments, and it is usually the number nobody has.

Every recommendation also states what it costs you. A recommendation with no downside listed is marketing.

Persistence strategy for the rating engine

412 business rules extracted, 187 of them inside stored procedures ยท Tier 1 analyzer coverage

Your rules live in SQL. We extracted 412 business rules, and 187 sit inside stored procedures. An object relational mapper forces a hand rewrite of each one, which is exactly where migrations lose meaning.

This option keeps SQL as the source of truth while making schema drift a compile error. The cost is a smaller hiring pool and a commercial licence for the Oracle dialect.

Selecting an option writes an architecture decision record and rewrites every affected envelope.

Propagation is what separates a decision from a chat message.

Selecting an option is not the end of a discussion. It is a write to Core that changes work already sitting on the board.

Recorded

An architecture decision record is written to Core with an owner and a date attached to it.

Rewritten

Every affected task envelope is regenerated carrying the new constraint.

Unblocked

Tasks waiting on the decision release. Tasks incompatible with it are flagged for regeneration.

Inherited

Agents dispatched afterwards carry the constraint and cannot silently violate it.

And you are shown exactly what moved: ADR-03 recorded. 23 envelopes updated, 4 tasks unblocked, 1 task regenerated.

Railway junction with converging switched tracks

Which forks are treated this way.

Anything that will constrain work for the rest of the programme. If a choice would change what a task envelope says, it belongs here rather than in a meeting.

Target language and runtime Persistence strategy Framework selection Service boundaries Messaging patterns Deployment target Managed service adoption Cutover strategy Data migration approach

Decisions may be revisited. Revisiting flags every artifact derived from the old choice as stale rather than quietly rewriting history to match the new one.

Record a decision and watch the envelopes rewrite.

The prototype reports exactly what moved: envelopes updated, tasks unblocked, tasks flagged for regeneration.