THE PORTAL · TARGET-STATE ARCHITECTURE

A system built to be governed – not just to run.

This is a Finance-specific architecture, not a generic AI platform. Its entire design exists to make the operating model enforceable – so that preparation, calculation, approval, and execution never collapse into one opaque step. Two questions it answers: is it buildable, and where does it stop?

On the next screen it sits still, so you can read the map. Then it runs – and you watch a governed decision packet build itself, one field at a time, until it reaches the one field the system cannot fill.

01 · THE MAP

The architecture, at rest.

A recognizable stack: where people work at the top, where agents orchestrate below, the certified services they draw on, the systems of record beneath – all of it governed by a security column that touches every layer.

Workbench at the top · orchestration and certified services in the middle · systems of record at the base · the governing column down the left, touching every layer.

02 · THE MAP, RUNNING

Scroll, and watch a decision packet build itself.

As you scroll, the flow moves down the architecture and each layer writes its line into the packet on the right – a real collections decision, assembling at your pace. Keep going until it reaches the field the system cannot fill.

Scroll down to assemble the packet – scroll back up to rewind.

03 · WHERE IT STOPS

The line the system will not cross on its own.

Everything up to the decision is prepared, calculated, evidenced, and logged by the system. The decision itself is not. That separation is designed in, not hoped for.

The system may

+Prepare packets, drafts, summaries, and routing recommendations

+Retrieve certified data, context, and approved policy

+Calculate through registered, versioned services – never ad hoc

+Assemble source-linked evidence and write lineage

+Monitor status, detect exceptions, and raise alerts

The system may not

×Approve accounting, tax, disclosure, or control signoff

×Own or perform governed Finance math inside agent reasoning

×Execute a material action or write back without human approval

×Approve a value claim, or allocate capital

×Cross the boundary on its own – ever

The boundary rule

Sensitive data, tool calls, write-back, evidence, and external access each require explicit controls, logging, approval, and retention – by service class, at every crossing.

04 · WHAT MAKES IT SAFE TO SCALE

The column that governs every component.

Identity, access, and control are not a feature bolted on. They run down the side of the whole architecture – every request, every tool call, every crossing passes through them.

Identity & access

Every actor has an identity

Managed agent identities, scoped permissions, segregation of duties, and DLP – humans and agents alike are known and bounded.

Evidence & lineage

Every hop is logged

Prompt, retrieval, tool call, output, and approval – each written with source links and retained, so the trail is audit-supporting by construction.

Monitoring & kill switch

Any workflow can be stopped

Continuous monitoring of quality, overrides, and incidents – with authority to suspend any agent, tool, or workflow that breaches a threshold.

This is why autonomy can grow without control chaos: the column sees, logs, and can stop everything the engine does.

05 · THE DISCIPLINE

Buildable, and bounded by design.

The architecture makes the operating model enforceable rather than aspirational. It is a design for validation – a target state that deepens as each gate is proven, not a deployed system.

The architectural commitment

The system prepares everything and decides nothing. Preparation, calculation, approval, and execution stay separate – enforced by the architecture, not by good intentions.