Interoperability
Beside your systems, or the record itself.
Two modes, and an operation can use both. Which one applies depends on whether anything in your estate already holds the thing you are asking about.
Mode one
Beside
Selira keeps every source’s version side by side, with its origin and when it was known. Today records arrive through an API and import jobs; live connectors to ERP, maintenance and operations systems are the direction. Your systems of record stay the systems of record. No cutover, nothing overwritten: this is the de-risked way in, and where we start.
Mode two
Native
Selira holds the record directly for what your systems keep only one version of, or forget: competing claims about the same thing, who made each and on what authority, when you knew it, and which records across systems are the same thing. These rarely have a home in the estate — which is why they live in spreadsheets and in people’s heads.
A layer that only reads adds one more system. One that can also hold the record can retire the sheets that exist only to hold it.
Beside and native are one model: what arrives from your systems and what Selira holds itself sit together, each with its source, so one question can cross both.
We lead with beside because nobody should bet an operation on a new platform before seeing it answer something. But the ambition is not to be another thing you integrate.
What that means concretely
Your systems stay the systems of record
Where one exists, transactions keep happening where they happen today. Selira does not take custody of what already has a custodian.
No cutover
Your systems stay in charge throughout. For a first question we import an extract of exactly what it needs, and nothing else moves.
Each source keeps its own version
We do not overwrite one system’s answer with another’s, so adopting Selira never costs you information you had before.
Writing back will be deliberate and narrow
Where it is going: a source system’s own transactions, posted through its own interface, each path declared, under the authority allowed to make them.
Mappings are declared, and yours
A vendor’s field becomes a modelled property through a declared mapping — field, code list, unit, identity rule — not bespoke glue code. Imports can be back-dated, so history arrives with its own dates.
Nothing is locked in
The model is yours and it is readable: what Selira holds reads back out through the same API, as of any date. What stayed in your systems never has to be extracted.
Not only systems
Sheets, documents and email are sources too.
The context around the systems’ records — the planner’s sheet, the procedure, the supplier’s email — is mostly written down beside them. What Selira brings in gets the same standing as a system record: where it came from, when it was known, and a place in the ranking.
Spreadsheets
The planner’s tracker, the AOG list, the plan everyone actually works to. An xlsx is kept as a sheet — formulas working, cells addressable, exported back to xlsx — with who brought it in and when. Nothing re-keyed. In build: its rows standing as claims beside the system’s, so where they disagree, you see it.
Documents
Procedures, specifications, certificates. Today a PDF is kept and shown beside the thing it concerns. Where it is going: what is inside it becomes addressable, so a decision can point at the clause or the table row it rested on — once a person has checked it against the original.
Where the outside world talks to the operation: supplier dates, customer approvals, quotes. The direction: a message that states a fact becomes a claim with its sender and time — from authenticated senders only, and unconfirmed until a person confirms it.
The honest limit
Selira cannot know what nobody wrote down anywhere
This deserves saying plainly.
If no system, no sheet, no document and no email ever recorded where something went, Selira will not conjure it. What it will do is tell you that the last claim was in March, under whose authority, and from which system — instead of returning a confident blank or a stale number dressed as current.
An expensive failure is often not missing data, but data that looked certain and was not.
Start with one question, and an extract of the data it needs.
Fixed scope. No cutover. You keep the model.