Serapis.ioProbabilistic Intelligence.
Describe the outcome. Your AI builds it. Serapis leads the work required to make it a product you can own, sell and operate.
Request a private trial“I have not yet begun to fight.” — JOHN PAUL JONES · 1779, HMS SERAPIS
Every governed claim carries its evidence
Receipts, not reassurance
Your agent reports done. Serapis treats that as a claim, not a fact. Eligible claims are checked against a versioned contract and pass, fail, or remain unknown. Each verdict binds what was checked, how, and when. Independent review stands between the producing agent and the accepted record.
The map, honestly held
Serapis is being built around one map that separates what was observed, what was admitted, and what remains unknown. When evidence goes stale, dependent conclusions are marked for re-evaluation instead of silently preserved. Architectural memory sits outside the chat so accepted decisions can survive model and session changes.
First light on your project
A bounded first observation
Private trials begin with an exact, bounded snapshot of a project you already own. Serapis inventories what it can actually observe, preserves coverage gaps as unknown, and keeps candidates separate from accepted state. MCP and plugin access are planned entry paths over this same boundary; they are not represented here as live integrations.
The first scan
The first bounded observation produces an exact inventory, explicit coverage gaps, and evidence-backed candidates for what to examine next. It does not infer completeness from silence. The result is a record of what was seen, what was not established, and what requires correction or human authority.
Ownership, kept whole
Your agent, your subscription
Serapis is designed to orchestrate customer-selected AI rather than resell inference. Customer keys remain in the deployment boundary disclosed for that profile, and the verification lane stands apart from the producing model. That separation matters because the party checking the work should not silently inherit the producer’s assumptions.
Your boundary, your database
Customer-boundary deployment, customer databases, portable records, and named human authority are part of the product architecture. The exact custody, anchoring, and availability profile will be disclosed for each deployment. AI may draft or supply evidence; it does not silently become the decision authority.
Free to start, and yours to leave with
The planned public tiers begin with a free customer-key path and preserve export as a product requirement, not a retention trap. Paid tiers are intended to sell durable memory, receipts, coordination, and portfolio scale. Until public enrollment opens, the current path is a bounded private trial.
Your project should not forget itself
Every conversation window ends. The question is whether the reasoning ends with it.
This preview illustrates decisions, constraints, and evidence in one field. Clusters represent subsystems; spacing demonstrates the relationship model, not measured project distance.
What architectural memory actually is
Not a longer chat history. Architectural memory is a typed record of the decisions a project is made of. Each Atom can carry constraints, evidence, provenance, and reason outside any one conversation. The next connection step is making supported agents read the relevant bounded record before they write.
Why that matters
When a window closes, the reasoning goes with it: the constraint agreed on Tuesday, the approach already tried and rejected, the thing that must never change. Without a record, every session re-derives your project from whatever is still on screen, and an agent will confidently contradict a decision nobody wrote down. That is how projects stall at eighty percent, and how the same mistake gets made twice.
What is moving through it
This synthetic run shows the intended operating view: named agents crossing a governed record, blocked and unknown counts exposed, and one work item held at a gate rather than silently accepted.
What actually changes it
Not merely that a record exists, but that something other than the model holds it. The Serapis kernel is being built to preserve what was accepted, what remains open, and what may happen next while giving an agent only bounded work. The model can propose; it cannot write its own authority or quietly promote its own memory.
Why it is held as a graph
Because decisions depend on each other, and a list cannot say how. The target graph plane gives each admitted atom explicit upstream and downstream relationships, allowing stale evidence to produce a visible impact set instead of quiet decay. The graph carries lineage; governed authority determines what may become current.
One fact, and everything leaning on it
All the way down to a single atom: what it rests on, what rests on it, and who is waiting at the gate for it. This is why stale evidence cannot rot quietly.
One running map, recorded at three distances. Synthetic estate, real renderer, no mockups.
We ran it on ourselves
We wanted to add something to Serapis, so we checked it the way we check anything. Run it twice from the same place and it gave the same answer, exactly. Run it from somewhere else and it did not. And a part of the work it was meant to read, it never saw at all.
That last part is the one that matters. It did not come back wrong. It came back unknown. We treat those differently, because “we could not check this” and “this is fine” are not the same sentence, and only one of them is safe to act on.
The answer was no. We retained the exact internal record and its fingerprints so the decision can be replayed. A public verification packet will be linked here only after its release boundary is independently checked.
A verdict is only worth something if it can come back against you.
The rules the record has to obey are written down. Ten of them, each with a name. Then we break each one on purpose, one at a time, and require the matching check to catch it. Ten deliberate breaks, ten catches. A test that has never failed has not been tested.
The finite Atom model is small enough to examine exhaustively: 44 reachable states, 70 transitions, and 710 invariant evaluations. That establishes ten named invariants for this bounded model—not total correctness of a deployed system. State identity is exact canonical bytes, with a digest recording which bytes were checked.
The end product Serapis is building toward: Chat-to-reliable software. A nontechnical customer describes a business or application, then receives secure, monetizable, deployable, maintained software—with product leadership, engineering, operations, and compliance support built into the path.
- An AI-built app approaching its first dollar. Auth, payments, data custody, and release evidence before real customers make every shortcut load-bearing.
- A brownfield system nobody fully understands. A bounded, exact inventory, explicit coverage gaps, and a governed map instead of inferred facts presented as truth.
- A stalled build or hardening pass. An evidence-backed next step, carried through correction and re-verification.
- A release or high-impact change. Deterministic gates, named approval, and a revision-bound receipt before the change becomes state.
- A team of people and agents. Scoped work, decisions, handoffs, and corrections that leadership can inspect without slowing every operator.
- A recurring operational determination. Exact source revision, explicit rules, a named human decision, and a replayable case file.
- An incident, vulnerability, or dependency change. Trace what is exposed, what is affected, what is still unknown, and which prior decisions became stale.
- SOC 2, CMMC, diligence, or an asset handoff. Portable evidence, receipts, and declared gaps retained inside the customer’s boundary.
Your people define the rules and retain authority. Models may propose; the engine checks only what can be established and records what cannot. Within a governed path, missing or contradictory evidence holds rather than silently becoming approval. Serapis makes no mission, legal, compliance, or business determination for you.