What the record is

Syderial is the system of record for intelligence. For every person and agent that uses it, Syderial does four jobs.

1. It decides what a model is given. A model receives only what the person or agent is cleared to see, cited and signed. We call that the context of record.
2. It limits what an agent can do to what that ground supports. An action the record doesn’t support doesn’t run, or waits for a person.
3. It records what the agent knew, was allowed to see and did, with a signed receipt for each call.
4. It admits what it doesn’t know. When the record has nothing on a question, the door says so.

The record doesn’t claim to know what is true. It shows what is in it, where each part came from and on whose authority. Memory tools recall. Syderial keeps the record.

What you get as a developer

• The request formats you already use. Syderial doors accept OpenAI chat completions, Anthropic messages and OpenAI responses requests and return the matching responses. Your client changes its base URL and its credential. See the Quickstart.
• Answers from the record. Before a call reaches a model, Syderial compiles the context of record the caller is cleared to see and grounds the call in it. The answer comes back with the evidence it rests on.
• Separation you don’t write yourself. Every line in the record has a label, and every request has a clearance. A line reaches a reader only when the clearance dominates the label on every axis, so your application code filters nothing. See Labels and information flow.
• A receipt for every call. Syderial signs a receipt for each answer, each abstention and each tool decision, and a reviewer can replay them. See Receipts and verification.
• Tools under the same rule. A tool or MCP call is proposed, checked against authority and recorded under the same labels as a read. See the MCP door.

Available to design partners as it ships.

The record in one paragraph

The record is a journal of signed entries. Each entry is posted once and chained to the entry before it. An entry contains lines, and each line cites its evidence, either a quote from a retained source or a pointer to an entry already posted. A correction is a new entry that cites the entry it corrects. Every entry keeps two clocks: when a claim applied according to its source, and when the record learned it. The chain of entries is the ledger, and Syderial rebuilds every graph and index from it.

How a call moves through Syderial

Every write and every read passes through six stations.

1. 01CaptureEvery turn, with its author.
2. 02BoundLabels on every line, the lattice on every read.
3. 03EntailEvidence must support the claim.
4. 04CompileA hashed packet of cleared context.
5. 05GatePolicy before any tool call runs.
6. 06ReceiptSigned, hash-chained, replayable.

Figure 1. The six stations. Every write and every read passes through them in order.

1. Capture keeps every turn with its author.
2. Bound labels every line when it’s written and checks the reader’s clearance on every read.
3. Entail commits a line to the record only when its cited evidence supports it.
4. Compile builds the context of record for a call as a hashed packet, drawn only from lines the reader is cleared to see.
5. Gate checks policy before any tool call runs.
6. Receipt signs and chains what happened so a reviewer can replay it.

The six stations page covers each one.

Where Syderial fits

Syderial doesn’t chat. The applications and agents that chat call it. Vector stores, retrieval libraries, orchestration frameworks and observability tools can all run on top of a record, and Syderial is the record they read from.

A model can’t reason over what it isn’t given. With Syderial, an agent can’t act beyond it.

Where to go next

• New here: read The journal, then run the Quickstart.
• Wiring an agent: see Coding harnesses and the MCP door.
• Evaluating the design: read the research.

Access

Syderial issues door addresses and credentials to design partners. Request a briefing to apply.