Skip to content
RigoMind

AI, data and software,
built around the problem.

Most organisations do not need a model. They need a system that works inside their existing operations, and reliable data underneath it.

Three layers.

The model interprets requests. The core computes anything that can be computed, such as prices, stock and balances, and the model never writes to it directly. Where a value can only be estimated, a named person signs off below a stated confidence.

System architecture
Model layer
Reads what was asked and writes the reply. May be wrong on any given turn.

May propose. Never commits.

a proposal crosses down
fixed values return up
Application layer
Turns a proposal into a request with a defined shape, and asks a person where the cost of being wrong is high.

Admits, rejects, or holds for review.

asks · is answered
Deterministic core
Prices, balances, stock and records. The same inputs always give the same answer.

The only authority over a value that can be computed.

The same three layers sit underneath every engagement, whatever it is for.
For your technical team — the architecture
The review floor
01the model's confidence in its own readingREVIEW FLOORa named person decidesaccounts, or the duty manager, by rolethe system proceedsand the record shows that it did
Below the floor a named person decides; above it the system proceeds, and the record shows that it did. Where the floor sits is set for each deployment.
The proposal object
crosses down
{
"intent": "enquiry.availability",
"proposed_by": "model",
"fields": {
"room": "Deluxe",
"window": "12–14 Oct",
"guests": 2
},
"may_commit": false
}
returns up
{
"rate": { "value": 4200, "source": "rate_table",
"row": "Deluxe · 12–14 Oct" },
"total": { "value": 8400,
"computed": "2 × 4200" },
"hold": { "written": false }
}
// fixed. the model may phrase these; it may not change them
Every field the model produced is marked as a proposal, and the object it hands over cannot commit anything. The reply it is allowed to send is built from the values that come back.
One request, in sequence
  1. 01ChannelModel

    message, in the guest's words

  2. 02ModelApplication

    proposal: intent and fields

  3. 03Application

    validate, check permissions

  4. 04ApplicationCore

    compute the rate, lock the room

  5. 05CoreApplication

    fixed values, with their source

  6. 06ApplicationModel

    values the model may phrase

  7. 07ModelChannel

    reply, phrased

The model never speaks to the core. It hands a proposal to the application layer, which decides what to ask for, and it phrases the values that come back.

Operational Systems

We build the systems an organisation runs on: where bookings, stock, records and money are held, and where being wrong has a cost. AI is added where it earns its place.

Every record passes through the states raised, validated, held, reviewed, posted, audited.

Payments
Order raised
before checkout, never after
checkout abandoned
Stays open
The order stays open. There is no phantom payment to unwind.
Captured
provider reference, read back
confirmation never arrives
Checked by absence
Detected by absence on a schedule, then checked with the provider.
Settled
matched to our own ledger
settlement does not match
Escalated to a person
Escalates to a person. Nothing is assumed to have cleared.
Refunded
against the original capture
refund exceeds the capture
Refused
Refused by the system before it reaches the provider.
The happy path is the easy half. A payment integration is judged on what it does when the confirmation never arrives, and each dashed edge names where that case goes.
What this involves — Operational Systems
  • Existing system of record
    Work inside an existing system of record, reading from and writing to the ERP, PMS, ledger or database the organisation already runs, without becoming a second source of truth.
  • Your own infrastructure
    Deployment on the organisation's own infrastructure where that is required, with single sign-on, role-based access, audit trails and stated data residency.
  • Websites and portals
    Websites, portals and content platforms with an editorial workflow, so the people who own the content publish and revise it without a developer in the loop.
  • Administrative systems
    Administrative systems for membership, scheduling, attendance and approvals, with the periodic returns generated from the record rather than re-keyed, so the return and the system agree.
  • Allocation and scheduling
    Allocation and scheduling computed against stated constraints: assignment, routing and sequencing where the system proposes and a person disposes, and the constraints are written down.
  • Production and provenance
    Production and provenance systems where lot identity survives splits and merges, captured append-only and attributed at the moment of work.
  • Booking and availability
    Booking, inventory and availability systems where a hold is real and a price comes from a table.
  • Payments and reconciliation
    Payments, settlement and reconciliation designed around the failure column, where an unmatched settlement escalates to a person.
  • Asset and member registries
    Registries of assets, entities and members, with role-based access, audit trails and exports.
  • Multi-party platforms
    Multi-party platforms where listings, approvals and payouts each have a state machine rather than a status field.
  • Offline-first capture
    Offline-first capture for field conditions, so a record made without a network is not a record lost.
  • Bilingual, protected by design
    Bilingual interfaces, and data-protection obligations designed in from the start.
  • Consoles that give reasons
    Administrative consoles where every row carries the reason it is in the state it is in.
  • 3D, AR and VR experiences
    3D digitisation of objects and spaces, virtual tours, and AR and VR experiences for museums, campuses and destinations, delivered in the browser and on phones, with headset versions where a site has the hardware.
  • Handover and ownership
    Handover documentation and code ownership, so the client's own team can maintain what we build.
Lot ledger
LOT-4417
opening quantity 120
out 50 · in 48
LOT-4417-A
Operator 1 · Unit A
variance 2, recorded at return
out 40 · in 39
LOT-4417-B
Operator 2 · Unit A
variance 1, recorded at return
appended, never edited
correction · appended
first booked 38, then +1 → 39
out 30 · in 29
LOT-4417-C
Operator 3 · Unit B
variance 1, recorded at return
parent closes
116 returned + 4 variance = 120
against an opening quantity of 120
Every stage is recorded by the person who did it, at the time they did it. A wrong number is put right by a new line, and the parent closes only because the quantities reconcile.

Data and Machine Learning

We build the data a system depends on, and the models that learn from it: unified records, labelled datasets and evaluation sets, then forecasting, classification and detection on top. Language is the hardest case and the one we work in most. Where a model can only estimate, we state its confidence and name the person who decides below it.

  • Unified records
    Records held in different places and formats unified into one queryable record, including deciding when two entries are the same entity, with the ambiguous cases routed to a person.
  • Corpora and evaluation sets
    Corpora and held-out evaluation sets built for the specific problem, especially for languages with little digital material, so capability is a measurement.
  • Forecasting
    Forecasts of demand, occupancy and cash flow, reported with their uncertainty.
  • Detection and classification
    Anomalies and duplicates found, and documents and images classified, with a confidence floor below which a person is asked.
  • Speech for low-resource languages
    Speech recognition and synthesis for languages with little digital material.
From collection to a decision
01
Collection
Text and speech gathered under an explicit protocol, with script and transliteration decisions recorded, and speaker consent held.
02
Annotation
Guidelines written before annotation begins, so two annotators reading the same passage make the same call.
03
Evaluation set
A held-out set built for this language specifically, so performance can be measured rather than inferred from a neighbouring language.
04
Model selection
Recognition and synthesis models chosen and adapted against that set, not against a benchmark built for another language.
model
Estimate, with its confidence
A forecast, a classification or a reading, never a bare answer.
system
Above the floor
Used automatically, and logged.
person
Below the floor
A named person decides, and the decision is recorded.
The evaluation set exists before a model is described as working, so its performance is a measurement. What the model produces is an estimate: above the stated confidence floor it is used automatically, below it a named person decides.
What this involves — Data and Machine Learning
  • Collection under protocol
    Collection under an explicit protocol, with capture conditions recorded and consent held, for text, speech, images or sensor readings.
  • Annotation guidelines
    Annotation guidelines written before annotation begins, so two annotators looking at the same item make the same call.
  • Models chosen against the evaluation set
    Models chosen and adapted against that set, not against a benchmark built for an adjacent domain.
  • Catalogue and record schemas
    Catalogue and record schemas: what a field means, what is required, what is independently verifiable.
  • Unattended monitoring
    Systems that run unattended, where nothing arrives and the job is to notice: a stream watched continuously, raising a case for a person.
Coverage and evaluation
CapabilityStatusNote
Text generationevaluatedBase models compared on a held-out set. The result holds only for the tested register.
Speech recognitionevaluatedMultilingual models assessed on speech from a language absent from their training data.
Speech synthesisno evaluation setUntil one exists, no accuracy claim is made.
TransliterationblockedWaiting on the orthography decision, which is upstream of everything else.
A capability without an evaluation set is one we do not describe as working. Two of the four rows are therefore unclaimed rather than unbuilt.

Generative and Agentic AI

We build AI that drafts, answers and acts inside an organisation's own systems: agents that handle multi-step tasks such as enquiries, quotations and approvals; assistants that answer from the organisation's documents with sources shown; and extraction from documents, images and speech. The model proposes. Your systems and your people decide.

  • Agents with approval gates
    Agents that carry out multi-step work, such as enquiries, quotations and approvals, using the organisation's own systems, with a person approving wherever a wrong action is costly.
  • Assistants grounded in your documents
    Answers drawn from the organisation's own documents and registries, with sources shown, and defined behaviour when the answer is not there.
  • Conversational and voice agents
    On WhatsApp, web chat, email and voice, including mixed-language input and languages with little digital material.
  • Extraction from documents, images and speech
    Fields read from documents, photographs and recordings, with arithmetic and tax checks computed by application logic, not by the model.
  • Evaluation and guardrails
    Test suites built before launch, and guardrails against prompt injection and unsafe actions.
One agent task, as a loop
THE AGENT'S LOOPpassespassesapprovedcommitfigures wrong: redraftcheck fails: re-planunsure: ask the managerunresolved: escalateMODELRead the emailPlana school's requestgoal → stepsSYSTEMCheck the price listActprices and stocktool call, read-onlyMODELDraft the quoteDraftitems, totals, termspropose the outputSYSTEMCheck the figuresChecktotals and taxcomputed validationPERSONManager approvesApproval gatethe only way outhuman in the loopSYSTEMSend and logCommitsent once, loggedwrite once, log
Illustrative. The agent goes round the loop until its draft passes the computed checks; anything it cannot resolve goes to a person. Nothing is sent until the manager approves, and every step is logged.
See this running in RigoInvoiceInformed by our research on causal and agentic AI
What this involves — Generative and Agentic AI
  • Multi-agent orchestration
    We build systems in which specialised agents share one task, with defined hand-offs between them and a single point where the outcome is decided.
  • Typed tools and MCP
    We connect agents to ERPs, ledgers, calendars and messaging through typed tools and MCP servers, each limited to what that agent may do.
  • Model adaptation and private deployment
    We adapt open models to an organisation's own material, and deploy them on its own infrastructure where data cannot leave.
  • Drafting with review
    Reports, replies, summaries and translations drafted from the organisation's own records, with sources shown and a person approving what goes out.

How we engage

Every engagement starts by deciding whether it should happen, and ends with the client's own team owning what was built.

  1. Phase 1, One to two weeks

    Discovery

    What should be built, what it will require, and whether it should be built at all. If simpler means would do, this is where we say so.

  2. Phase 2, Fixed scope

    Build

    Delivered in stages against a written scope, inside the systems the organisation already runs.

  3. Phase 3, Live, supervised

    Pilot

    In daily use with real transactions, under our supervision, with the review points set against what actually arrives.

  4. Phase 4, At the end

    Handover

    Documentation and code ownership, so the client's own team can maintain what we built.

What holds in every engagement

  1. 01Financial values, inventory and records are computed by application logic rather than by a language model.
  2. 02We do not describe a system as supporting a given language until it has been evaluated in that language.
  3. 03We build systems the client's own team can maintain, and we document them accordingly.
  4. 04Where a problem is better addressed by simpler means than AI, we say so during the diagnostic phase.

Ways of working together

DiagnosticOne to two weeks
Determines what should be built, what it will require, and whether it should be built at all.
BuildFixed-scope
A fixed-scope project delivered in stages.
Pilot partnershipActive deployment
Reduced fees in exchange for a reference deployment and a published account of the work.
Research collaborationInstitutional
Grant-funded or institutional engagements.

Discuss what you are trying to build

We will tell you what we would build, what it would take, and whether AI is the right approach.

Start a project