NELEUS

Explained

Architecture.

Three ideas hold the system up: the vault is a graph rather than a pile of documents, every action passes two locks, and every record is linked to the one before it. Drawn below, because they are easier to see than to read.

One · the vault

A graph, not a folder of documents.

Compliance facts are related to each other, and a filing system throws those relationships away. Neleus keeps them: domains hold layered hierarchies, hierarchies hold nodes, and typed links between nodes carry meaning a query can follow.

The shape of the governed vault A domain contains a layered hierarchy. The hierarchy contains nodes. Typed links join nodes to each other, such as a policy being implemented by a control, and a control compensating a risk. DOMAIN, ONE OF EIGHTEEN Layer 1 your structure, in your own vocabulary Layer 2, up to seven deep Node a policy, a risk, an incident IS IMPLEMENTED BY Control owned by a named person COMPENSATES Risk scored, reviewed, dated
Domains are configured per organisation rather than hard-wired, so the same rails carry a structure you recognise instead of one we imposed.

Two · access

Two locks, and the smaller one wins.

An agent acting for you can never do more than you can, and never more than it has been permitted itself. Both locks are checked on every action, and the effective permission is the smaller of the two. A seat gives read access. It never gives write access on its own.

How the two locks combine The person may read, write and approve. The agent acting for them may read and write, but not approve. The effective permission is read and write: the smaller of the two locks. LOCK A, THE PERSON Read Write Approve LOCK B, THE AGENT Read Write Not permitted WHAT ACTUALLY HAPPENS Read Write Refused The smaller of the two, on every single action.
An agent can never be the accountable owner of a record. A foreign key in the database schema forbids it, and a build check proves that constraint still holds.

Three · evidence

Each record carries the one before it.

Every change is cryptographically linked to its predecessor. Documents freeze into immutable evidence, and files are re-verified against the chain when they are served. Altering a record after the fact does not quietly succeed. It breaks the arithmetic from that point onward.

The hash-chained evidence log Four records in sequence. Each carries the hash of the record before it. If one is altered after the fact, every link after it stops matching, so the tampering is visible rather than silent. Record 1 the first entry GENESIS Record 2 carries hash of 1 VERIFIES Record 3 altered after the fact HASH NO LONGER MATCHES Record 4 and everything after BREAKS TOO The tampering does not have to be caught by a person noticing. The numbers stop adding up on their own, and the original is still there to show an auditor.
This is why a refusal is worth as much as an approval in the log. Both are recorded, and both are chained.

Where the models sit

Models never touch the vault directly. An agent proposes an action, the broker decides whether it is permitted, and only then does anything reach the record. The model plane and the key handling are drawn out on the runtime page.

What we do not claim

Static hosting cannot set response headers, so this website carries no content security policy of its own. That is a real limitation of the hosting choice, it is recorded as an accepted risk in our own register, and we would rather write it here than have you find it.

We hold no security certification today. ISO 27001 is on our roadmap and is not our current posture. Every number on this site is checked against the code before it is published.

Ask us to prove any of it.

The demo worth having is the one where you pick the claim and we show you the code, the schema or the refusal behind it.

Book a demo