How Stream Central shows up here. Architecture principles stay attached to the components and change kinds they govern — so a capability gap named in a review is still there when someone designs a settlement-adjacent endpoint six months later, with the rationale intact.

Story so far: DretzaPay’s board approved a scored bet — win on settlement speed, sub-30-second FedNow, for cash-flow-sensitive mid-market merchants. Read post 1 → · Series overview →

Build architectural runway before commitment

Mature organizations treat architecture as runway: name the capabilities that must exist, the debt that blocks them, and the principles that govern how change is allowed — before dates harden. The failure mode is the hallway brief: “We’re doing real-time settlement now. When can engineering start?” Gaps discovered mid-sprint become excuses nobody believes; gaps named before commitment become plan inputs leadership can own.

Michael Osei, DretzaPay’s Enterprise Solution Architect, wasn’t in the boardroom when the bet got approved. He needed a way to say “not yet” without standing in front of the train — so he ran the capability and technology-debt review in front of the same people who’d made the bet, where gaps aren’t opinions: they’re named, owned, and attachable to principles.

How Stream Central attaches gaps to governed work

Stream Central models capabilities and technology debt against the components that will carry the work, records standing architecture principles with scope and rationale (mandatory or recommended for affected layers and change kinds), and carries those principles so later design reviews and handoffs can resolve them against linked work — without reconstructing why from memory.

Walk the flagship storyboard →

What to notice in this screen: a standing principle titled for ledger ownership — Mandatory and Active — with Applies When, Do Instead, Rationale (including the $40K drift incident), and the layers and change kinds it governs. That is durable governance, not a one-time debt slide.

The capability and technology-debt review that preceded this principle named the same gaps against the components that will carry settlement — inventory leadership can treat as plan input.

Three findings from that review carried the most weight:

• The ledger is the single source of truth for money movement, or it isn’t yet. DretzaPay’s existing settlement path had a reconciliation service computing its own shadow balance instead of writing through the ledger synchronously — the pattern behind a prior $40K weekend drift. Real-time settlement makes that gap load-bearing.
• Settlement writes have to be idempotent and safely retryable. Sub-30-second settlement means clients retry far more aggressively than T+1 batch ever saw. Without an idempotency key on every settlement write, a retried FedNow call double-settles a merchant.
• Cardholder data can’t leave the vault boundary unencrypted. PCI-DSS Level 1 scope is calculated by everywhere a raw PAN can flow — and that scope stands between DretzaPay and the enterprise deals the Meridian comparison from post 1 depends on.

Principle governance, not a one-time deck. You name the capability or debt item once, attach a standing principle to the affected layers and change kinds, and the next design review checks against that principle. Principles govern architecture scope and can be resolved for linked work and handoff; they do not auto-apply every rule to every epic. Input is the gap; connection is the principle on the component and work; result is a plan input leadership can see.

When someone proposes a settlement-adjacent endpoint six months later, the ledger and idempotency principles are still there — rationale attached — so nobody has to re-litigate why.

What the architect does differently

Michael didn’t kill the bet. He turned “we think we can build this” into a named list of what has to be true first, each item owned, each item visible to the same leadership that approved the roadmap. Leadership still chooses sequencing and dates; Stream Central surfaces the constraints.

Because Stream Central models capability and debt against the components that carry settlement and records standing principles with scope and rationale, Michael could present ledger integrity, idempotency, and PCI scope as owned plan inputs before dates hardened, producing a bet the board could still hold — with eyes open about runway. This matters because an approved strategy without architectural constraints is a delivery date waiting to fail in public.

Without the scored bet from post 1 framing this review, capability and debt mapping is just an inventory — technically accurate, and nobody prioritizes it. The bet turns “here’s our tech debt” into “here’s what blocks the thing the board just approved.”

Apply it in your organization

1. For your largest active bet, can you name the three stack constraints that must be true before delivery dates are credible — and who owns each?
2. When a designer proposes a change adjacent to that bet six months from now, do they find a standing principle with rationale, or a deck from last year’s offsite?
3. Are capability gaps visible to the people who approved the roadmap, or only to engineering?

The open question

Michael’s review named the gaps and assigned owners. What it didn’t do is say when. Ledger dual-write, idempotency, PCI scope: three named workstreams, no shared understanding yet of how they compete for the same engineering time. The gaps are named, but leadership still can’t say when. The roadmap is a wish until someone knows where delivery time actually goes.med, but leadership still can’t say when. The roadmap is a wish until someone knows where delivery time actually goes.

→ Next: Where the work actually goes

---

Stream Central is not another issue tracker, and it’s not a heavyweight portfolio rollout — connectors aren’t the pitch. It’s where architecture principles stay attached to the components and work items they govern, instead of living in a wiki nobody opens during planning.

See how Stream Central connects architecture to delivery → · Read about backlog readiness → · Series overview →