Seven companies. Seven ledgers. One brain.

At a glance

Client	An industrial minerals trading and production group (name withheld)
Footprint	7 legal entities · Southeast Asia, Oceania, EU
Scale	Eight-digit group revenue (USD) · lean teams across every jurisdiction
Challenge	Group-level questions, entity-level systems
Engagement	3 phases · 6 months · fixed fee
Outcome	groupOS — one operating layer across all seven entities

The build, by the numbers:

• 69 interconnected tables — the group’s operating model in one schema
• 7 interface workspaces · 45 pages · role-based access
• 195 orchestration scenarios across 18 functional folders
• 24 native automations running inside the data layer
• 7 accounting ledgers synchronised in real time
• 78 currency pairs, updated daily — unbroken since day one
• 264,000 indexed document chunks powering the knowledge agent
• Group operating history migrated in full and verified against the team’s own benchmark

The situation

This client doesn’t fit the usual transformation story. It was never a company drowning in chaos — it was a fast-growing group that had already done the smart things. Modern productivity suite deployed. An AI assistant live over its documents and genuinely useful. Clean books in every jurisdiction. A team that knew its numbers cold.

And the owner kept hitting the same wall.

Every question worth asking was a group question. Every system that could answer it was an entity system.

What that felt like day to day:

• Consolidated sales? A day of manual spreadsheet work — stale the moment it was finished.
• Group receivables? Seven ledgers, seven exports, one hand-built merge.
• Margin by product? Reconstructed on request. Never available on demand.
• A payment batch approved? Assembled by hand, chased through email, confirmed in chat.
• Where’s that shipment document? Someone’s inbox. Probably.
• Intercompany elimination? In theory — in practice, in someone’s head.

The AI assistant answered questions about documents. Nothing answered questions about the business. The group had AI on top and nothing underneath.

The brief was blunt and broad: consolidate seven entities onto a single source of truth, automate execution across logistics, finance, accounting, receivables and payables, build real sales analytics with cost and margin per product, and make operational decisions fast enough to matter.

The method: one operating layer

Afanasyevs builds one thing, adapted to each client: the operating layer — the level between the systems a company runs on and the decisions it has to make. It has two halves.

Layer 1 — The data layer

One database where the information flows operations depend on — internal and external — are accumulated, structured, visualised and made retrievable.

Not a warehouse for analysts. An operational field where data is:

• Concentrated — no longer dispersed across mailboxes, chats, spreadsheets and disconnected tools
• Addressable — indexed for retrieval by humans through interfaces and by agents through APIs
• Append-only — history accumulates instead of overwriting, so every number traces to its origin
• Owned — governed by the client’s own team, never held hostage by its consultant

What this kills: the shadow circuit — the company knowledge that lives in people’s heads and walks out the door with them.

Layer 2 — The execution layer

On top of that data, deterministic scenarios and agents run the company’s standard operating processes.

• Everything deterministic runs deterministically — no AI where a rule will do
• AI is deployed where it earns its place — classification, extraction, language, judgement-adjacent work
• What can’t be resolved automatically becomes an Exception Case — escalated to a named human with a deadline
• Every exception decision is recorded — what was decided, by whom, why, with what consequence
• Recurring patterns are engineered back into the automation — the system learns in cycles

The compounding benefits

Risk removed	How
Tunnel vision	Decisions made against the full group picture, not one entity’s slice
Key-person risk	Process knowledge and decision history live in the system, not the employee
IP leakage	Intellectual property concentrates into a governed layer the company owns
Shadow operations	Every run logged, every failure surfaced to a queue someone owns
Attention drain	Routine executes itself; people work exceptions and events that actually matter

Phase 1 — Understand

Detailed interviews across every function, then a design nobody could argue with.

• 21 to-be process maps — extracted from staff interviews and shadowing, not assumed from a template
• A full entity-relationship diagram of the future data layer
• Automation specifications — what runs natively, what runs through orchestration, what stays human

Nothing was built until this was workshopped and approved. That discipline is why the build ran without a structural rewrite: the disagreements were absorbed by the design, not the code.

And it surfaced the decision that reshaped the engagement. The contract named a single entity. The proposal sized the build at eight scenarios and six tables. The diagnostic showed that every question the owner was actually asking was a group question — no single-entity build could answer them.

So the build became a group build. All seven entities, consolidated and intercompany, delivered inside the same engagement.

Phase 2 — groupOS goes live

The five decisions that made it work

1. The accounting system never moved. The books were accurate in all seven jurisdictions; the failure was above them. The rule was fixed on day one: accounting is transactional truth; groupOS is the operational and control layer. Every automation touching financial state writes to the ledger first, mirrors to groupOS second — never the reverse. → Eliminated the entire “which system is right?” category of dispute before it could exist.

2. The stack was chosen for handover, not for demo day. A no-code platform combining database, automation and interface in one governable environment. A dedicated orchestration layer for agent control and integration. A rendering service for branded documents. Frontier language models engaged surgically. → An operating layer only its consultant can maintain is a dependency, not an asset. This one changes hands.

3. Business logic lives in data, not in code. Aging buckets, payroll rates, margin guidelines, logistics stage definitions — all in reference tables the team edits itself. → Changing a business rule is a table edit, not a developer ticket.

4. Every human gate is doubled. Any automation requiring a decision creates both an assigned task with a deadline and a branded notification email. → A gate you can miss is not a gate.

5. Synchronisation runs belt-and-braces. Per entity: a real-time webhook capturing every accounting event, plus a nightly sweep re-reading five trailing days of changes. → No accounting event has gone uncaptured since go-live — including entries made directly in the ledger, including backdated ones.

What the group got

Management

• Sales dashboards — consolidated and per entity, with intercompany elimination
• Invoice status, cumulative totals, breakdowns by product and product type
• Margin overview tied to live cost-of-goods inputs
• Sales by customer · receivables by counterparty
• Inventory overview integrated with the group’s stock system

Commerce

• Full sales analysis by product and counterparty, cross-referenced
• Complete product matrix · freight and freight costs · margin and markup guidelines
• Extended CRM block on the customer module
• Branded PDF quotations generated straight from the dashboard — versioned, line-managed, one click
• Dynamic currency block: 78 pairs, daily, uninterrupted

Accounting & Finance

• Receivables: trend analysis and per-customer cards showing open / due / overdue
• One-click branded collection notices — gentle reminder or firm demand, both on brand
• Payables aging in buckets to 90+ days, with trend and oldest-bill surfacing
• Batch approval, end to end: accounting assembles the payment batch in the interface, submits in one click, and the director approves or rejects directly from the email
• Working-capital view projecting cash 90 days forward from live AR/AP

HR

• Employee registers · recruitment intake
• Onboarding and offboarding with automatic task-plan deployment
• Leave approvals · payroll draft pipeline · payslip generation and distribution
• Legal-document expiry alerts before they become a problem

Logistics

• Freight, transporter and warehouse registers
• Inbound and outbound agents — stage definitions, triage, document handling

Project Database

• Projects · tenders · leads · technical documentation · consumption factors
• Market research and competitor analysis
• The commercial memory of the group, in one place

System Control

• Every automation run logged · every failure surfaced to the Exception Queue
• Synchronisation tracked around the clock
• An improvement-suggestion form — the team feeds its own backlog

The learning loop, running live

The Exception Queue isn’t an error log. It’s the mechanism that makes the system improve:

• Automated case → runs on its own, logged
• Non-automatable case → Exception Queue → named human decides → decision, decider, reasoning and outcome recorded
• Recurring pattern → engineered back into automation → the exception stops being an exception

The company keeps the memory of why — permanently, and independently of who was in the room.

The migration

The group’s entire operating history — customers, vendors, items, invoices, bills, purchase orders, across every entity — was migrated into groupOS. Automated backfill pipelines handled the volume; a substantial share was manual migration and cleansing — the slow part of making historical data usable rather than merely present.

Then it was tested against the toughest benchmark available: the commercial director’s own hand-built sales workbook — the number the team trusted most.

Exact match at group level. And groupOS surfaced transactions the benchmark itself had missed.

That comparison did more to convert the team than any demonstration.

Built to absorb reality

Mid-build, the group adopted a dedicated inventory platform as its stock system — the right business call, and one that superseded a just-completed thirty-scenario logistics integration built against the previous data flow. Schemas and triage logic carried straight over; the integration layer is being rebuilt against the new source of stock truth under the extension.

Real companies make real decisions mid-project. An operating layer has to absorb them without collapsing — and this one did.

Phase 3 — The brain answers questions

Stage 1 — Prove it. A retrieval-augmented agent over the company’s document corpus: 264,000 indexed chunks, multilingual embeddings, vector search, LLM-generated answers, delivered through chat to a three-person trial group. It worked in daily use.

And it surfaced the finding that mattered more than the working demo: a company-wide rollout needs multi-level access control and governed handling of sensitive documents. A flat document store provides neither.

Stage 2 — Build it properly.

• Document estate migrated to a multi-tier enterprise document platform, with differentiated access for user groups across all seven entities
• Executed by the client’s own IT specialist — precisely the ownership model the methodology exists to produce
• Unified retrieval agent rebuilt on top, running inside the client’s own security perimeter
• Live in production

Answer quality is now governed by corpus hygiene — which the client’s team owns. The layer was handed its own maintenance.

The result

What the group has now:

• One place where the data of seven companies meets
• One mechanism executing its standard processes
• One queue where its people decide the exceptions — and the reasons are kept
• Group sales analysis that matches the trusted benchmark, then finds what the benchmark missed
• Payment batches approved from an email; collection notices sent in one click
• An AI assistant answering questions over the company’s own documents, inside its own access perimeter
• A system its own team owns, edits and extends

Is this your shape?

• 2 to 10 legal entities across multiple jurisdictions
• 20 to 300 people — too complex for spreadsheets, too small for a Big Four ERP programme
• Group-level questions answered by entity-level systems
• Books that are fine — and a management picture assembled by hand
• Process knowledge concentrated in a handful of irreplaceable people
• AI tools deployed on top of an operating layer that doesn’t exist yet

Afanasyevs builds operating layers for multi-entity groups: one governed, retrievable place where a company’s operating knowledge is concentrated, and an execution system above it that runs the standard processes, escalates what it cannot close, records how those exceptions were decided, and turns the recurring ones back into automation.