Solutions · platform capability

The reporting layer your core system never had.

Describe the report. An agent finds the data, does the calculation, and saves it as a recipe anyone can run again. Over data from our modules, or over data from the systems you already run.

Let's meet

The problem

Sound familiar?

There is a report designer nobody remembers how to use, a dashboard product priced per viewer, and a spreadsheet at the end of every quarter that one person assembles by hand. The numbers in the three of them do not always agree.

And the report the board actually reads is the one built by the analyst who left in March.

How a report gets made

AI is used once, to build the template. After that the report is ordinary software.

01
You describe it

In plain language: what it should show, how it should be grouped, what the totals are. No designer to learn.
02
An agent finds the data

It looks through the data sources available to you, picks the ones that answer the question, and writes the calculation.
03
You review it once

You check the numbers and the layout against what you expected. When you accept it, it stops being a request and becomes a recipe.
04
Then AI steps out

Every run after that is plain code. No model is called, so two runs of the same report cannot drift apart. On demand, or as a step inside a workflow.

The part clients ask about first

It works over the data you already have.

You do not have to move your core system to get reporting out of it. Two ways in, and they can be mixed inside one report.

Data from Omnicorn modules

Every Omnicorn module registers the data it holds, with the fields, filters and grouping it supports. A report asks for it by name, and the request carries the permissions of the person running it.

Data from the systems you already run

Your ERP, your core system, your data warehouse. We connect to it over whatever it speaks: REST or SOAP interfaces, a database connection, files over SFTP, or a message queue. Your own system can also simply send the data along with the request and get the finished document back. Nothing has to be migrated to be reported on.

This is why some clients start here. They keep the system that runs their business and use ours for the reporting it was never built to do.

Shared work, separate data

One template, and everyone sees their own numbers.

A report somebody builds can be shared with the rest of the organization. What travels is the recipe, not the data.

Documents and dashboards, from the same recipe

Documents to send and sign

PDF for the record, Excel for the people who will pull it apart, Word for the ones who will keep editing. Charts and tables are rendered on the server, so a document looks the same wherever it is opened. More output formats are on the way.

Dashboards on screen

The same recipe renders as a dashboard inside the system, with the same numbers and the same access rules. No second product, no per-viewer licence to count.

Reports as a workflow step

A report can be produced by a process rather than by a person: at the close of a period, on an approval, or when a threshold is crossed. The document lands where the process says it should.

The calculation layer

Real reports need real arithmetic.

Placeholders in a template cannot do a weighted average across three years, or a simulation, or a reconciliation. So the calculation runs as actual code, in a box built to hold it.

A fresh, isolated process per run Nothing carries over between runs. Memory and time limits are set by configuration, not by whoever wrote the report.

No network The code cannot reach the internet or pick a system to call. Its only way to data is a proxied request that carries the permissions of the person running the report.

Known libraries only A reviewed set for data work. Nothing is installed at run time.

Recorded by fingerprint Each run is recorded by a hash of the code that ran, so a change is visible without the calculation itself being exposed.

What you stop licensing

Report designers

A separate tool, with its own licence and its own specialist, to lay out documents your data already contains. Here the layout is part of the recipe.

Dashboards priced per viewer

The cost of letting one more person look at a number should not be a line item. Dashboards render inside the system, under the access rules that are already there.

The quarter-end spreadsheet

Not a product, but the most expensive one on the list: several senior people, several days, and a number nobody can trace back to its source.

Questions we hear

Do we have to move our data?

No. Your system can send the data with the request and get the document back. Reporting does not require a migration.

Can two people share a report but see different rows?

Yes, and that is the normal case. The template is shared; the data each person sees is decided by their own rights at the moment they run it.

Is the output stable?

Rendering is deterministic. The same inputs produce the same document, which is what makes a generated report usable as a record.

Who can see a generated file?

Access applies to the report, to the data behind it and to the file itself. Every generation is recorded with who asked for it and what it read.

Can our own developers call it?

Yes. Generation is an API call, and it is already used that way by workflows inside the system.

It is part of the core. Access rules, the audit trail and storage are not built into the report engine. They belong to the system underneath, which is why a generated document is governed the same way as everything else.

Inside Omnicorn

Bring the report your team assembles by hand.

The quarterly one, with the tabs and the manual checks. We will show you the generated version on your own data structure, and what it takes to get there.