Your operation already wrote down what went wrong.
Runink FACE is Runink’s main product: the Fulfilment Autonomous Claims Engine, built for logistics and the claims, returns and compliance work that hangs off it. It reads the records you already hold, works out what the combined picture means, and drafts the action for a named person to approve.
What FACE is, and what it is not.
An entry held at the port for a missing paper while the daily charge runs. A pallet that came back and was never graded. A freight claim still inside its filing window that nobody had the morning to assemble. A reefer drifting warm overnight. In every case it was written down first, in a system you already run, and then read late, by sample, or not at all.
FACE is the product that reads all of it, and it is the one this company is built around. Everything described on this page is FACE. The two names you will see elsewhere on this site are not.
Runink FACE
The flagship. Logistics, fulfilment, forecasting, claims, returns and the compliance work around them. This page, and the whole of it.
Runink PULSE
A separate product, not a FACE feature. Market analysis, research and the material a marketing team publishes. It has its own paper.
Runink core
The platform underneath, not something bought on its own. It is the answer to where FACE runs and who can see what it reads.
Nine kinds of work, in three groups your operation already recognises.
What is coming and how it moves. What happens when it goes wrong. And being able to show, afterwards, why you did what you did.
Plan it, hold it, move it.
The three questions that decide the week before anything has gone wrong: how much is coming, whether it is on the shelf, and how it gets there. Planning, buying and dispatch usually answer them in three different systems, on three different days.
- Demand forecasting Your own order history is read as a series and put through the same sequence a statistician would run by hand: describe it, test whether it is stationary, look at the autocorrelation, then fit both a decomposition and an ARIMA and pick between them by backtest. What comes back names the model that won, quotes the stationarity test it was chosen against, and lists the points that did not fit. Under five observations it declines and says so rather than drawing a line through them. The planner argues from a stated method, not from seniority.
- Inventory fulfilment Stock, inventory and fulfilment records are read from the systems that actually hold them — your database, your warehouse platform, your ERP, your spreadsheets, your object storage — and set against the lines you have already promised, so a cover problem surfaces while ordering is still ordinary and has not yet become air freight. Every one of those reads is read-only, and structurally so: the query is checked character by character before it is sent, so a connection cannot become a way to write to your system of record. The F in FACE is fulfilment.
- Route optimisation A lane is put to the routing service you configure, and the distance and duration it returns come back attached to the request. If no routing service is configured, or routing returns nothing, the answer is the word unavailable — not an empty card with the fields blank, which is what a dispatcher would otherwise read as a measured route of zero. Refusing that particular answer is the whole of the work here.
The exception arrives named.
Three kinds of bad news, all of them recorded somewhere before anybody acts: something on the site, something coming back, something being claimed. Each has its own path through FACE rather than being a note appended to an order.
- Reactive logistics A frame reaches FACE one of three ways: a photograph taken on a handheld at the dock, text an edge device has already read off a label, or the address of a video feed you point it at. It is graded for what was damaged and where — the pallet, the crate, the container door, named, not reduced to a severity score. A cue can then be raised to the operating picture everyone is watching, and it says exactly what it is: a cue requested, broadcast to whoever is subscribed. It is not an instruction to a crane or a camera, because nothing here is wired to one, and a sensor type FACE does not recognise is refused rather than quietly filed as a camera.
- Reverse logistics A return is triaged on its own record: what came back, what condition it is in, and which disposition it belongs in. Returns are a dedicated path, because the cost of a return is decided in the hour somebody grades it.
- Insurance underwriting and claims Claims, reserves, premiums, deductibles and settlements are records FACE reads and types like any other: a claim is a reserve against a policy. It assembles the file and drafts the action. It does not decide the underwriting — an adjuster does, on the file FACE put in front of them.
Being able to show the reasoning.
Two of the hardest conversations in an operation are the one before a change and the one months after it. Both need the same thing: the records the decision rested on, still joined up.
- Supply chain management The relationships between your orders, suppliers, sites and shipments are built into one graph, so the operation can be read across systems that were never joined to each other. The twins take that picture and keep it current as the records change.
- Financial scenarios and hypothesis testing A change is stated as a hypothesis — a lane a week late, a supplier dropped, a different reserve assumption — together with the rules it touches. What comes back is the case laid out: which rules the change collides with, in what order they bite, and each consequence tied to the rule it follows from. It is reasoning you can argue with rather than a number to accept, it executes nothing, and the decision stays with the person accountable for it.
- Paralegal and compliance A compliance agent whose stated role is paralegal. It reads policy documents, the rules extracted from your own procedures, and the system's own logs; it cites the rule and the records behind a finding; and it drafts the functional remediation — the letter, the ticket, the notification. It reads and cites. A person decides.
The drafted action waits. Approving is what sends it.
All nine end in the same place. A finding is held as one specific proposed action, with the rule it invoked and the records it cited attached to it. A named person approves, edits or rejects it, and that decision is written down as an event with the actor on it — who approved, when, and what they changed — so the reason can be given later without assembling it again.
A new instance starts with an empty queue. FACE does not arrive holding findings about you; it holds none until it is connected to something and something is found, and it will show you an empty queue rather than fill one.
Approving is what sends the drafted action, and what comes back afterwards says which parts of it actually ran. Where a step could not be carried out — no mail connector configured, no write-back to your ERP — the response names that step and the reason it did not happen, on every reply, including one where some of the work went out and some did not. It is the difference between a system that reports success and one that tells you what it did.
- Your procedures, written down once The rules you already work to — the day you stop waiting on a carrier, the duplicate purchase order, the vendor request with nothing behind it — are stated once and checked against every record rather than remembered by whoever is on shift.
- Why it fired, on which records Afterwards you can open a finding and read the rule, the records underneath it and the reasoning that joined them. A drafted letter nobody can check is not worth signing.
- Documents arrive as documents A spreadsheet is read properly — the cells, the formulas behind them, the named ranges and the macros — because that is where the working usually is. A scanned page is transcribed by a model running on your own hardware, and where a page comes back unusable the result says so instead of returning a confident blank.
- Could not check is an answer Where a check could not run — nothing to read, an answer that came back unusable — the result is unable to assess, written out in words as not a finding that the thing is compliant. Zero and nobody-measured are kept as different values on purpose, and a connection nobody has contacted is never reported as verified. An assessor whose confident answers and whose blanks look the same is worth nothing by the second week.
Where it runs, and who can see it
This is usually the first question from information security and the last one to get a straight answer. These are properties of how FACE is built, not results anybody is reporting.
Your records stay on your machines
The order files, the customs papers, the sensor readings and the reasoning about them run on hardware you control. The model FACE reasons with is one you run yourself: there is no third-party model dependency anywhere in it and exactly one inference endpoint, which is the one you point it at. That is how it is built rather than a switch somebody could leave off — though it is an architectural property, not a machine-enforced one, and we would rather you heard that from us than found it.
Open-web research with no account attached to it
When an answer needs the open web — a carrier's standing, a customs ruling, a published tariff, a consignee you are unsure about — FACE runs the search from your own infrastructure through a public search endpoint, then fetches and reads the pages itself, and the extracted page comes attached to the finding. The search engine sees the query, as it would from any browser. What does not happen is the part that matters commercially: there is no vendor account, no API key and no per-question bill, so no supplier is building a history of the names your company has been asking about, filed under your company.
On Runink core, inside your boundary
FACE runs on Runink core, the platform underneath it. Services identify themselves to each other on every call and hold nothing long-lived. The cockpit your team uses is the same boundary your auditors are given.
Drawn — not a measured result
What this page deliberately does not say.
There is no figure on it, no customer named, and no outcome claimed. Everything above describes what FACE reads, what it produces and who approves it, drawn from the records these systems hold — not an account of what happened at somebody else's company. The figures that matter belong to you: each industry page carries the measures to write your own against, and a baseline stops being recoverable the moment things start improving. Write yours down first.
The questions that actually get asked.
Straight answers, including where the answer is no.
Is FACE the same thing as Runink PULSE?
Has this been run on an operation like mine?
Does FACE decide, or do we?
Do we have to replace our WMS, ERP or claims system?
What happens when it cannot check something?
Our team follows the SOPs loosely. How does that help?
Where does our data go?
Is there anything we can put in someone's hands today?
What does it cost?
Bring one lane, one claim, or one month of invoices.
Half an hour, with whoever owns the problem in the room, and we will walk one real example of yours end to end. If the losses you carry are not the shape this addresses, we will say so.