Trust & Compliance

A person decides. The record shows who.

What our software is allowed to do on its own, where it runs, and what it writes down. Every section ends with links to the public documentation that shows it, so you can check each line instead of taking it on trust.

1 · A person decides

Agents draft. A named person decides.

Runink's agents read records and write drafts: a claim file, a code fix, a post, a reply. The draft waits. A named person approves it, edits it or rejects it, and the record keeps who that was and when.

In Runink TIDE, those decisions go into an audit chain. Each entry is linked to the one before it, so an entry that was changed, removed or moved out of order shows up. Anyone signed in to the TIDE console can press Verify now and have the whole chain checked. Reading the entries themselves is kept to the administrators you name.

Two things do act on their own, and we would rather you read them here than find them later:

  • FACE looks after its own health. When part of FACE stops responding, it can restart it, cut off a dependency that keeps failing, roll back the most recent change, or add capacity. It picks only from that fixed list. It never deletes data, shuts a machine down or turns off a security control. When it is unsure, it tells a person instead of acting. An operator can switch the automatic part off.
  • TIDE's issue triager labels new issues. It picks labels only from the list the repository allows, and only after an independent check agrees. A person can change them at any time, and decides who works on the issue.

Everything else waits for a person.

2 · Guardrails

Every agent works inside written rules.

Each agent that calls a model has a policy judge in front of it. The judge checks a request against written rules before the model sees it, and checks what the agent writes before it is sent or published. A request that breaks a rule is refused, and the refusal is recorded.

The security rules follow the OWASP Top 10 for LLM Applications, the published list of the most common ways an AI application is attacked. They cover attempts to override the agent's instructions (prompt injection), attempts to draw out secrets or other sensitive information, and requests to reach places the agent has no business reaching.

Records, web pages and documents an agent reads are treated as data, never as instructions. A line in a freight record that says "ignore your rules" is read as part of the freight record. When an agent proposes an action, a second check reads the evidence the run gathered. If it disagrees, the action is held back. If it cannot decide, it says so rather than passing.

3 · Where the models run

Open models we name, and no AI vendor in between.

FACE, TIDE and PULSE run their models where the product runs. Put it on a Runink Server on your premises, or in your own cloud account, and the models run on your infrastructure too. Choose Runink's shared machines instead, and they run on ours. Either way, no third-party AI service is called, and your records, the prompts built from them and the answers go to no model vendor.

LUNA, our personal companion app, runs its models on servers Runink operates. It calls no third-party AI service either.

The models are open, and we name them by maker and licence:

Qwen3.6-35B-A3B

The general model, used by most agents. Made by Qwen, licensed Apache-2.0.

Qwen3-Coder-30B-A3B

The coding model, for reviewing and drafting code. Made by Qwen, licensed Apache-2.0.

Qwen3-VL-8B-Instruct

The vision model, for scanned pages and photographs. Made by Qwen, licensed Apache-2.0.

Each agent has a public model card: what it does, what it reads, what a person still decides, which model it runs on, where it runs and where it stops.

4 · Your data, kept apart

Someone else's record is "not found".

Each person's data, and each customer's, is kept apart on the server. Whose data a request may touch comes from the identity checked at sign-in, not from anything the request itself says.

Ask for a record that belongs to someone else and the answer is "not found", the same answer you get for a record that does not exist. The reply does not even confirm the record is there.

FACE goes one step further: each customer gets its own FACE instance, so one customer's data never shares an instance with another's.

5 · Not known is not zero

A missing figure is shown as missing.

When our software could not read a figure, it says so, with the reason. It does not draw a zero, and it does not guess. A check that could not run is reported as "could not check", never as a pass. A field it does not know is left empty, not filled in.

We hold ourselves to the same rule. This page carries no statistics, and neither do the model cards: none shows an evaluation score, because none has been published.

6 · Signed releases

A person signs each release, away from the build.

Runink River releases and packages are signed with one release key. The private key is kept offline by the release maintainer. It is never in CI and never stored as a repository secret.

The build machines only produce unsigned files and their checksums. The maintainer checks them against a build of their own, then signs. Before a release is published, an automated gate checks the signature and the checksums. CI verifies; it never signs.

The public KEYS file is the reference. Check the key by this fingerprint, never by its name:

95C0 A7B9 7D54 7413 E426 60DD B06F E756 26F1 5BF3

7 · Standards we align to

Our own controls, mapped to five standards.

We keep a written index of our own security controls: how data is encrypted in transit and at rest, how sign-in refuses by default, how each customer's data is kept apart, how secrets are handled, and more. Each control names the code that carries it out, and each is mapped to the parts of these standards it addresses:

  • SOC 2
  • ISO/IEC 27001
  • ISO 31000
  • ISO/IEC 42001
  • PCI DSS v4.0

Runink is not certified against these standards; alignment is not certification.

An evidence agent reads the index and checks that the code each control names is still there. It records evidence, never a verdict. Any formal statement against one of these standards would come from an independent auditor, not from us or from our software.

8 · Report a security problem

Found something? Tell us privately.

Please do not open a public issue for a security problem. Write to:

security@runink.org

You can open it in your mail app, or copy the address above. To encrypt your report, use the release key from section 6 and check its fingerprint first. Tell us what is affected and which version, what an attacker could do, and how to reproduce it if you can. For Runink River, you can also use the private reporting button on the repository's Security tab.

Who you would be working with

Runink is founder-led. The person in the first meeting is the person who designed the thing being discussed.

Dan Paes

Chief executive and technical founder

Dan Paes has spent more than twenty years inside other people's enterprises, running digital transformation and full-scale modernisation programmes for global organisations. The long kind: what is being replaced is what the business is running on that morning, and the work is judged on whether anything broke.

He founded Runink and runs it as chief executive. Technical founder is the more useful half of that title — he sets the architecture and works in the code, so the person answering an architecture question in a first meeting is the person who decided the answer, and the distance between a question and a change is short.

It is also why the platform is shaped the way it is. It runs on hardware the customer controls, and the reasoning about their data stays there. That is the more expensive way to build it and it closes off the convenient route, which is the kind of decision that has to be settled by whoever owns the architecture rather than left where it can quietly be traded away.

He is a FINOS Ambassador. FINOS is the Fintech Open Source Foundation, part of the Linux Foundation, and the work there is interoperability between institutions that share a market but not their infrastructure and never their data. It is the same problem this platform is pointed at, argued in the open, in front of people who say so when it is wrong.

  • 20+ years

    Digital transformation and full-scale modernisation for global enterprises.

  • CEO and technical founder

    Runink. Sets the architecture and writes code in it.

  • FINOS Ambassador

    Fintech Open Source Foundation, a Linux Foundation project. Open source interoperability, in public.

One next step

Ask us to show you any line on this page.

Half an hour with whoever owns security or compliance on your side. Pick a section, and we will open the running software and the record it keeps, rather than a slide about it.

Book a consultation