Data governance · Statistical production · Decision support

Turn the database you already run into governed statistics — and into answers.

SIGESTAT produces publication-ready yearbook tables from an operational relational database, keeps every figure versioned and traceable, and lets a decision-maker ask a question in plain language and get a number that cites its source. No SQL. No upfront data-modelling project.

Watch the 3-minute demo See each step

Full product demo — 3 min, English captions. Recorded end to end against a live instance.

Deployed in Cameroon Any relational database, any sector Runs on your own servers English and French

0 lines of SQL to write

2 stages removed from the chain

7 steps filmed in the product

4 export formats

The problem

How a national yearbook actually gets made

Collect, check, clean, build views over the database, then assemble the tables in Excel pivot tables — every year, largely by hand, by the one person who knows how. That last stretch has three failure modes, and they compound.

Not reproducible

The workbook is a snapshot

Next year the table is rebuilt from scratch. The reasoning that produced it — which rows counted, which were excluded — lives in somebody's head, and leaves when they do.

Not auditable

The number arrives without provenance

Nothing records how a figure was obtained. When a published number is challenged, there is nothing to re-run and no trail to follow back to the source.

Silently wrong

A duplicating join never warns you

Look up a value across a one-to-many relationship and the total inflates without a word. The error is invisible in exactly the place where being wrong costs the most.

What it does

One piece of work, three jobs

The same table serves the statistician who publishes it, the institution that has to stand behind it, and the director who needs an answer this afternoon. That is the whole idea: not three tools, one thing used three ways.

Produce the statistics

Publication-ready tables straight from the operational database — nested headers, merged cells, totals — exported to Excel and Word, and assembled into a complete yearbook document.

Govern the data

Every table versioned, every publication recorded, changes in the source database detected, and the institution's own rules written down instead of living in one person's head.

Answer the question

A decision-maker asks in plain language — no analyst to go through, no yearbook to page through — and gets a figure that cites the table it came from and the date it was computed, or an honest "no table covers this yet".

How it works

From the source database to the printed page

Four stages. Nothing in this chain asks the user to write code, and nothing in it requires a preparatory project first.

1

Connect the operational database

The structure of the database — its tables and how they relate to one another — is read from the source. Nothing has to be described by hand.

2

Design the table and its meaning

The published layout is what you build: nested headers, merged cells and totals, plus what each cell counts and what it leaves out.

3

Check, then build

Dozens of checks run before anything reaches the database — including the one that catches figures about to be counted twice.

4

Publish and keep it

Excel, Word, JSON and Stata, with several tables assembled into a single yearbook document. Versioned, so next year is a re-run.

Time to publication

Build the yearbook while the data is still being collected

A yearbook is normally produced strictly in order. Collect the data. Run the entry checks. Clean it. Then build database views on top of it, and only then start assembling the tables — in practice, in Excel pivot tables. Each stage waits for the one before, and the two design stages sit at the very end of the chain.

SIGESTAT breaks that dependency. A table is built against the structure of the database, not against the rows in it. The checking and cleaning still have to happen — that is about data quality, and nothing removes it. But the design work no longer waits behind it: the whole yearbook can be built and reviewed while collection is still running, and when the data is ready a single refresh fills every table at once.

The usual sequence

Six stages, end to end

Each stage waits for the one before. Designing the tables — the part that takes judgement — happens when there is least time left.

1Collect 2Entry checks 3Clean the data 4Build database views 5Excel pivot tables 6Publish

SIGESTAT would already be finished here

With SIGESTAT

Two stages removed, one run in parallel

The data-quality work is unchanged — that is about the data itself, and nothing removes it. The design work moves off the critical path and runs beside it, with no views and no pivot tables left to build.

1Collect 2Entry checks 3Clean the data Time recovered ADesign and review the tables, in parallel 4Refresh & publish

Data quality — unchanged Design work Publication

The structure is known long before the rows

Reference tables — regions, levels, school types — exist from the first day of a campaign. Everything that defines a yearbook table can be settled against them while the facts accumulate.

Two stages disappear

No database views to prepare, and no pivot tables to assemble. SIGESTAT reads the operational database directly and produces the published table itself, so the two design stages at the end of the usual chain are simply not there.

One refresh, the whole project

When the data is in, a single refresh repopulates every table in the project. Getting the yearbook out becomes something measured in a run, not in a season.

See it work

Seven steps, filmed in the product

Each clip is a real screen recording against a live instance and a synthetic education dataset. No slides, no mock-ups.

Step 160 s

Connect a database

Point it at the database you already run. It reads the structure straight from the source — no preparation, no reorganisation, nothing to build first.

Step 270 s

Design the table

Nested headers, merged cells, totals. What you draw is the published table — and every field you place in it is checked against the real database.

Step 365 s

Match the labels

The database stores codes; the yearbook has to print words. You draw the link between them, and say explicitly which column is a total.

Step 465 s

Set the scope

Which cases each figure counts is built up from blocks, cell by cell — no query language, and no ambiguity about what a number includes.

Step 575 s

Ask the assistant

Describe the table in plain language. What comes back is a proposal you can inspect — and a change to an existing table waits for your decision.

Step 660 s

Trustworthy numbers

Combine two things carelessly and every pupil gets counted once per teacher. SIGESTAT catches it before the figure reaches a published page.

Step 760 s

Ask a question

A director asks in plain language, without going through an analyst or opening the yearbook. The answer names the table it was read from and the date that table was computed.

Decision support

Ask in plain language. Get a number that cites its source.

A director who needs a figure has two options today. Ask someone to look it up, and wait. Or open the yearbook and find the right table among hundreds — which assumes they already know which table holds the answer.

SIGESTAT adds a third: ask. No analyst in the loop, no document to navigate. And what comes back is not a plausible-sounding figure — it is a figure they can quote in a meeting and defend afterwards.

The assistant does not query the database when it answers. It reads the published tables of the project, at the values they were last computed with — the same values the yearbook was printed from — and every figure it returns carries a citation and a date.

Every figure is traceable

Each number in an answer records where it came from: which table, which row and column, and when that table was last computed. A figure with nothing behind it cannot be returned at all.

Stale data says so

If the table behind an answer was last computed more than thirty days ago, the answer says so. The decision-maker sees the age of the number at the same moment they see the number.

"I don't know" is a valid answer

Every answer is labelled grounded, not found or needs clarification, with a confidence level. When no published table covers the question, the assistant says what is missing and offers to build the table — rather than inventing a figure that looks right.

The document stays the record, not the interface

A yearbook is meant to be an official reference, not something anyone should have to page through to settle a question. It stays exactly what it was — while the answers become reachable without opening it.

Nobody in the middle

No request to a statistician, no place in a queue, no waiting for someone to come back from leave. The question goes straight to the tables the institution has already published and validated.

The question can become a table

If the answer needs a table nobody has built, the assistant can build it — checked exactly as a hand-built one would be, marked as assistant-created, and clearable in one go.

Supervised AI, not a black box

The model never writes SQL

Elsewhere, an AI assistant on a database writes the query itself. If it gets a relationship wrong, the result looks perfectly normal and nobody finds out.

Here the model describes what the table should contain — and the software checks that description and writes the query. A mistake is caught by a check, or shown on screen before anyone approves it. It cannot slip through as a plausible number.

You hold the controls

The assistant is a co-author with a human veto. Every lever below is in the interface, on every turn.

Accept or refuse No change to an existing table is applied without an explicit decision — the proposal is shown first, with its join paths and grain checks.
Bounded autonomy To answer a question no table covers, the assistant may build a new one on its own. Those are tagged as assistant-created, capped by quota, and purgeable in bulk — and they go through the same validation as everything else.
Choose the model Trade cost against quality per turn, not per deployment.
Choose the reasoning effort The same trade-off, at a finer grain.
Interrupt a run Take back control mid-generation, without losing the thread.
Retrace every step Everything the assistant did is kept and can be reopened later: what it was asked, what it looked at, what it proposed and what someone decided.
Change what it produced It builds the same object a person builds, so anything it made can be opened and edited by hand — mid-conversation or a year later. You are never left with something only the machine can touch.

For the people who build the tables

The same assistant, doing a very different job

A director asks it for a figure. A statistician asks it to build the table that figure comes from — and, just as often, to go and find out why a number looks wrong. That second job saves the most time, because it is the one nobody can do quickly by hand. It looks, and brings back concrete cases: rows, counts, actual offenders. What they mean stays the expert's call.

Build a table from a description

Describe the table you want and get a working one back — structure, labels and scope — then take it into the builder and adjust. Faster than starting from a blank grid, and the result is an ordinary table with nothing special about it.

Find what is counted twice

The classic cause of an inflated figure is a record that appears more than once where it should appear once. The assistant can go and look, and it comes back with the actual offending records — "this establishment has two statuses in the same year" — not a suspicion.

Check a column before trusting it

How full is it, how many nulls, how many zeros, how many distinct values, and is it collected everywhere or only in some regions? Enough to catch the two silent failures: a column that is empty, and one that only exists for part of the country.

Catch labels that have drifted

A category renamed in the source, a code retired, a new value nobody declared — and a published table quietly stops counting part of its population. The assistant can compare what a table expects against what the database actually contains.

Audit the institution's own tables

It can scan the project's saved configurations for damage — empty templates, broken references. That kind of corruption is quiet: the table keeps refreshing from what was stored, so nothing complains until someone looks.

Data governance

The figure is an asset. Treat it like one.

A published statistic outlives the person who produced it and the month it was produced in. Everything below exists so that, two years later, someone can establish where a number came from, reproduce it, and know what has changed underneath it since.

Institutional memory

The rules that used to live in one analyst's head — which cases count, which are excluded, what a column really means — are written down against the data source, with a record of who vouched for each one.

Every table keeps its history

Any earlier version can be looked at and restored, and a version holds the complete recipe rather than a fragment of it.

Changes in the database are noticed

The structure of the source is recorded each time it is read. When the operational database changes underneath a table, that table is held back rather than quietly producing different numbers.

Every build recorded

Generations keep the parameters they ran with and the documents they produced. A published yearbook can be traced back to the exact run that made it.

Every AI action is retraceable — and editable

Nothing the assistant does is a closed box. Each step is kept and can be reopened, and whatever it produced can be changed by hand afterwards, because it built the same object a person builds.

Accounts, roles and recovery

User accounts with role-based access control who can author, who can publish and who can only read. Deleted projects go to a recoverable trash rather than disappearing, and the database is backed up daily on a rolling retention.

And when a figure is challenged

There is somewhere to go. The assistant can be sent back into the source database to look for what usually causes it, and it returns concrete cases rather than an opinion — see what it can look for.

Working together

A yearbook is not written by one person

It is written by a team, over months, alongside an assistant, and usually under deadline. Most of what goes wrong in that setting is not a bad figure — it is two people, or a person and a machine, quietly undoing each other's work.

Nobody overwrites anybody

Each table carries a marker of when it was last changed. If it moved while you were working on it, the save is refused and you are told to look at what changed first. The system will not resolve that conflict by picking a winner behind your back.

The assistant is held to the same rule

If a colleague edits a table while the assistant is preparing a change to it, the proposal is rejected as out of date and has to be rebuilt on top of their work. An AI collaborator gets no privilege a human colleague would not have.

Pick up where anyone left off

Conversations, proposals and decisions are kept with the project, not with a session. A colleague can open the thread, read what was asked and what was decided, and carry on — or take the table into the builder and finish it by hand.

Long jobs are shared, not private

A project-wide refresh can take a while. Several people can follow the same run at once and see the same progress, instead of each launching their own and wondering which one counts.

Shared knowledge, not private notebooks

The rules about what a column really means are attached to the data source, where the next person will find them — rather than in a document on somebody's laptop.

Hand over a whole project

A project exports as a single bundle — its data sources, its tables and their history — and imports into another instance. Useful between a test and a production server, and between one institution and the next.

Built to be used by several people at once

The heavy operations — building a query, exporting a document, running an assistant turn — are kept off the path that serves everyone else's clicks. One colleague exporting a large yearbook does not freeze the interface for the rest of the office.

Alternatives

Why not just use…

Each of these does part of the job well, and part of it not at all.

Instead of	Where it stands
Excel or Google Sheets	Unbeatable for a last-minute adjustment, and the tool SIGESTAT actually replaces. What it cannot give you is a result you can reproduce next year, a trail back to the source, or a warning when a figure quietly doubles.
The established statistical platforms	Reliable, because the data has been reorganised in advance to make it so. That reorganisation is a project in itself — months of work before the first table exists. SIGESTAT works with the database as it already is.
Power BI or Tableau	Complements rather than competes. They are built for exploring data and building dashboards; a yearbook is a different craft — three-level headers, merged cells and footnotes, in Word.

Honest limits

What SIGESTAT does not do

Three limits worth knowing before a procurement conversation rather than after one.

No visual exploration

The template encodes the final structure, so you have to know what you want. To go looking through a dataset, use a BI tool — the two are complementary, not substitutes.

It checks the method, not the judgement

Every check can pass and the figure still be wrong, because the population chosen was not the right one. No software knows that a particular group should have been left out.

A brand-new kind of table takes work

Nothing has to be prepared in advance, but each genuinely new table shape takes a round of effort. Repeating a table across years or regions is already handled.

Scope

No domain is built in

Education is where SIGESTAT is deployed, not what it is made of. Nothing about schools, pupils or school years is written into the software: the structure comes from whichever database you connect, and the vocabulary comes with it. Health facilities, civil registration, agriculture, taxation — the tool does not know the difference, and does not need to.

Any relational database

PostgreSQL, SQL Server, MySQL, MariaDB, Oracle, SQLite and Microsoft Access, connected as they are. Relational sources are what SIGESTAT reads today; other kinds of source are on the roadmap.

The statistician stays autonomous

Nobody technical is needed between the question and the table. The person responsible for the indicator is the person who builds it — by hand, with the assistant, or both.

Sovereign deployment

It runs inside your own infrastructure. The data never leaves the institution, and nothing depends on a foreign cloud service.

Bilingual by design

The interface runs in English and French, and error messages are localised too — which matters where the working language of the report is not the working language of the database.

In the field

Already deployed, on real national data

SIGESTAT is not a prototype looking for its first user. It has been deployed and tested in Cameroon, within the country's education management information system (SIGE), under the PAREC programme with the support of the World Bank.

It runs against the databases of STATEDUC, the UNESCO school data management application — an operational system already in place across the administration, exactly as it stands. That is the whole premise of the product, tested where it counts: nothing was rebuilt beforehand, and nothing was rewritten to accommodate the tool.

SIGESTAT in use during a working session in Cameroon — SIGESTAT in use — a working session during data collection

The application running against STATEDUC data — The application running against real STATEDUC data

A yearbook table produced with SIGESTAT — The output — a yearbook page produced with SIGESTAT

Country — Cameroon Programme — PAREC, with World Bank support Source system — STATEDUC (UNESCO)

Who built it

SIGESTAT

SIGESTAT builds software that turns raw statistical data into publication-ready yearbooks and tables — for statistical offices and organisations that publish numbers.

Built from inside the problem

SIGESTAT grew out of years of producing statistical yearbooks by hand: collecting data from dozens of sources, formatting tables, checking figures, and redoing it all the next year. The tools that finally took that work off the table became this product.

Yours to keep

The system is designed to be handed over. A whole project moves between servers as a single bundle, and the institution that owns the data owns the tables built from it. Nothing here depends on us to keep running.