Architecture overview

This article describes Yig at the level a security reviewer or compliance officer needs to see — what the system is, where data lives, what crosses each boundary, and what the operator controls. It deliberately omits implementation specifics.

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 your team already uses. Each surface 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 manager in Slack get the same agent and the same audit semantics with different ergonomics.

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, what was reviewed, and what was changed.

L4 — Data path

The most important property of the architecture is what is not on it. Yig does not maintain a vendor-side data lake. Customer data is read from the customer’s own systems and written back to the customer’s own systems. There is no intermediate Yig database holding business data.

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, by design.