Architecture overview

The architecture refuses two things by construction: a vendor-side data plane, and a dashboard. Everything below follows. This is for the security reviewer, internal audit lead, and IT admin — at the level a reviewer can defend, not at the level of implementation.

The four layers

┌─────────────────────────────────────────────────────────────┐
│  L1 · Surfaces — where work runs                            │
│  CLI · Slack · Teams · Feishu · Excel / Word add-ins · API  │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  L2 · Reasoning core — the agent                            │
│  Tool layer · Planner · Reviewer gate · BYOK model contract │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  L3 · Audit & trust                                         │
│  Append-only audit log · per-step diffs · reviewer record   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  L4 · Data path — your stack                                │
│  Your warehouse · your spreadsheets · your document store   │
└─────────────────────────────────────────────────────────────┘

L1 — Surfaces

Yig does not operate a dashboard. The surfaces are the tools the team already uses. Each exposes the same primitives — invoke a workflow, view a draft, review, accept, reject — wrapped in the chrome of that surface. A controller in Excel and an FP&A lead in Slack get the same agent with different ergonomics. Each surface is held to the surface contract: a contract, not an integration.

L2 — Reasoning core

The reasoning core has three parts:

• Tool layer. A library of finance- and data-shaped tools (read connectors, structured extractors, schedule builders, recon engines, narrative drafters). Each tool has a typed contract and is independently auditable.
• Planner. Given an instruction and a workflow template, the planner sequences tool calls, gathers intermediate state, and decides when to halt for review.
• Reviewer gate. A first-class component, not an afterthought. The gate is what enforces that no output crosses to L4 without a human approval recorded in L3.

The model that powers the planner is bring-your-own-key (BYOK). The customer owns the inference contract. Switching from Claude to a self-hosted model does not require workflow changes.

L3 — Audit & trust

Every step in a Yig run produces an audit record:

• The instruction received.
• The tool called and the input shape.
• The output shape (not the proprietary tool internals).
• The reviewer who approved or rejected, with timestamp and comment.
• The diff between the draft and the shipped artefact.

The audit log is append-only and reproducible. A future audit can replay the trail and see exactly what was drafted, reviewed, and changed. What else this architecture persists — and what it throws away — is a trust decision, set out in what we don’t cache and why.

L4 — Data path

A vendor data lake holds a copy of the customer’s books and asks them to trust the copy. A read-from-source architecture leaves the books in the customer’s stack and reads them per run.

Yig is the second. Customer data is read from the customer’s own systems and written back to them. There is no intermediate Yig database. This is not a feature toggle; it is structural. The product cannot run a workflow without the customer’s stack being the data of record.

Trust boundaries

There are exactly two boundaries the architecture cares about:

Boundary	What crosses	What does not
Customer data ↔ Reasoning core	A scoped, read-only slice of the data the workflow needs	The full warehouse; data unrelated to the workflow
Reasoning core ↔ Inference	The minimum prompt envelope plus the scoped data slice	Any data not in scope of the current workflow

Both boundaries are inspectable per-run via the audit log.

What this architecture excludes by design

• A vendor SaaS data plane. Yig does not host customer financial data.
• A dashboard product. The reasoning core is not exposed as a UI of its own.
• Background automation. Workflows do not execute without an explicit instruction tied to a specific reviewer.
• Multi-tenant model state. Each deployment is single-operator (or single-team). Cross-tenant features will be considered as a separate architecture, not an extension of this one.

What the operator controls

• Which surfaces are enabled.
• Which workflows are installed.
• Which model provider is contracted (BYOK).
• Where the audit log is written.
• Which reviewers are authorised for which workflows.
• The deployment topology — local, customer cloud, or single-tenant managed.

If a workflow is not installed, Yig cannot run it. If a reviewer is not authorised, Yig cannot ship the output. The operator is the upper bound on what the agent can do.

The easy versions of this product are ruled out on purpose: no vendor data plane “monitoring for trends,” no dashboard the controller has to visit, no background automation acting without a named reviewer, no multi-tenant model state crossing the customer’s boundary. The bet is that an audit response three years from now survives a stranger reading it. If the four layers cannot hold under that reading, the architecture chose wrong, and the choice will surface in audit — not in a sales demo.