How it works

A decision is a record that stays intact from evidence to outcome.

Nervos gives a consequential decision one continuous record. What was known, what was assumed, what was chosen, who authorized it, what happened, and what was learned stay connected, and each entry carries the kind of knowledge it is.

The record moves through seven verbs. The same seven run the product and the demo.

Walk through a decision How it is enforced

The lifecycle

Seven verbs. Each adds something to the record and is forbidden one thing.

The verbs are not stages a decision passes and leaves behind. Each layer owns one job and never overreaches into its neighbor. That discipline is what makes a conclusion traceable from its first piece of evidence to the write that executed and the outcome that scored it.

01Frameevidence
02Understandbelief
03Exploreoptions · simulation
04Challengecontradiction · critique
05Governdecided · authorized
06Actexecuting · verified
07Learnoutcome recorded
The dashed return from Learn to Frame closes the loop.

Seven verbs, one line. Beneath each, the phases of the decision record it covers; under Challenge, the checks that run inside it. The dashed return is learning: an outcome re-enters as evidence for the next decision.

The seven verbs of the decision lifecycle, what each adds to the record, and what each may never do
Verb	What the record gains	What it may never do
Frame	The objective, its constraints, and the question being decided, in the decision’s own words.	Presuppose an answer.
Understand	Evidence with its source and its status: verified, inferred, simulated, or pending. Beliefs derived from that evidence. In the sample record, each belief’s ceiling is set by its weakest source.	Raise confidence by combining weak sources.
Explore	The alternatives considered, including the one not taken. Futures as ranges, P10 to P90, from a seeded simulation over stated assumptions.	Show a simulated figure as an observed one.
Challenge	Contradictions between credible sources, held open rather than averaged. A deterministic critique of the record. Disagreement recorded under a name.	Resolve a conflict silently.
Govern	Whether the record is ready: the invariants it must satisfy and who may authorize it. An approval by the proposer on record is refused. Until a pending migration is applied, a member can set who is on record (SOD-01).	Accept an approval from the proposer on record.
Act	The write into the system of record. In our repository, it goes out only under a server-recorded human authorization (AUTHZ-01), at most once per approval (IDEMP-01). Its steps are appended to a hash-chained ledger, and a compensating action is prepared where one exists.	Write without an approval on file.
Learn	Independent confirmation from the system of record. Where predictions are enabled, each is scored against the outcome and calibration is tracked across decisions. The record becomes evidence for the next one.	Edit a prediction after the fact.

Built to be unable

Five things the system cannot do, and what stops it.

Most of what makes a decision trustworthy is what the system refuses to do. These five refusals are built into the code and the database in our repository, not into a policy document. Some of these controls are not yet in the build we run. Where a refusal is partial, its row says what remains.

Enforced: blocking, verifiable from source
Partial: part holds, or is not yet shown to hold where we run it; the row names what remains

Each is covered by tests that CI is configured to run; the claims register records whether they run (CI-02). Identifiers such as SOD-01 refer to that register, which gives each claim’s status in each environment and is described on the trust page.

01
An analysis’s confidence cannot exceed its least-grounded perspective.
Each perspective’s grounding is scored, and the analysis is capped at the weakest one that contributed. In the sample record, every belief also inherits the status of its weakest piece of evidence. That general rule is proven in tests and is not yet wired into production code. In a deployment, the decision record that carries these statuses is off by default.
Enforcedanalysis cap
02
A member cannot edit a registered prediction.
Where predictions are enabled, each is written before the outcome is knowable, with the resolution date and criterion recorded. The database has no update or delete policy for them, and there is deliberately no status column to change. Once a pending migration is applied, the server cannot rewrite or delete one either (KNOW-02).
Partialno update policy
03
In our repository, nothing is written to a system of record without a server-recorded human authorization.
In our repository, the authorization is bound to the proposal as it stands, and the engine checks it again before the send (AUTHZ-01). Separation of duties is a database trigger and a dispatch check, not a setting. An approval by the proposer on record is refused, at approval and again at dispatch. Until a pending migration is applied, a member can set who is on record (SOD-01).
Partialtrigger · dispatch check
04
A simulated figure is not presented as an observed one.
In the sample record, every figure carries its status. In a deployment, the decision record that carries these statuses is off by default. Shipped copy is checked for unqualified claims by a lint that fails on them, and CI is configured to run it (CI-02). The lint reads copy, not the values a page computes.
Partialstatus tags · lint
05
A signed-in member reads only their own organization’s records.
Row-level security is on every table in the public schema (RLS-01). In our repository, each tenant table’s policies scope rows to the caller’s organization, from the session and never from a parameter a caller supplies (TEN-01). The service role bypasses row-level security, so server code scopes by organization itself. Isolation is covered by tests that CI is configured to run (CI-02). Its status in the service we run follows our next production verification.
Partialrow-level security

Systems of record

Reads by default. Writes only behind an approval.

Every connector reads first. In our repository, a write is dispatched only under a server-recorded human authorization (AUTHZ-01), one dispatch per approval, and each step is appended to the ledger. Against a NetSuite RESTlet older than 2.2.0, a retried attempt may still write twice, and the ledger records that doubt (IDEMP-01). Where a compensating action exists, it is prepared before the write.

The reference workflow is a vendor bill tied to a purchase order in NetSuite.

Systems of record Nervos reads and writes
System	Reads	Governed writes	If it must be undone	Status
NetSuite	Purchase orders, vendors, bills, and the general ledger by SuiteQL.	Vendor bill tied to a purchase order; purchase order create and amend.	Deletion of the created transaction as the compensating write.	Implemented; not yet exercised against a live account
Salesforce	Opportunities, accounts, and cases.	Task, opportunity, account, and case creation.	Deletion of the created record.	Implemented; not yet exercised against a live account
Snowflake	Role-scoped, time-bounded queries.	A tagged row with an identifier Nervos generates, approval-gated. Free-form statements are not a governed write.	Deletion of the tagged row by that identifier.	Implemented; not yet exercised against a live account
Slack	—	Signed approval requests; approve or reject inline. Every decision is role-checked and logged.	—	Implemented; not yet exercised against a live account
Workday · SAP · BigQuery · Databricks	—	—	—	Not yet available

Credentials are encrypted and decrypted only on the server, and the application never sends one to a browser. In our repository, a member cannot read or replace a colleague’s stored credential (SECRETS-01). A connector you need that is not listed is scoped inside a pilot.

Built on

Ordinary, inspectable parts.

Nothing here is exotic on purpose. A buyer’s security team should be able to read this list and know what to ask.

Data: Postgres on Supabase; Row-level security on every table. Vector index for memory.
Inference: Groq, by default; The model is set per deployment, and a fallback takes over if one is retired. No training on customer data. Provider agreement available.
Embeddings: OpenAI, optional; Used only for semantic recall. Configurable off.
Secrets: AES-256-GCM, moving to Supabase Vault; The application never sends a connector credential to the client.
Ledger: SHA-256 hash chain; A changed step breaks the chain. Re-verifiable in your browser.
Hosting: Vercel · Supabase on AWS us-west-2; Content Security Policy enforced.

Verify a ledger export Reproduce our claims

For engineering teams

No public API reference yet.

The surface is still stabilizing and we would rather not document what may change. Teams in a pilot work directly with the engineer who built the connector they need.

What is public today: the ledger verifier, the control mapping on the trust page, and the demo, which runs the same simulation and hashing code as the product.

Typecheck and tests: Configured to run on every push and pull request; Including the write-gate, idempotency, and the RLS tripwire. A failing run blocks a merge only where CI runs and the main branch is protected (CI-02).
Talk to an engineer: Contact us; Forty-five minutes, technical end to end.

Experience it

Operate one decision from evidence to outcome.

A sample decision, step by step, with a hash-chained ledger you can break and a prediction you cannot edit. No sign-up.

Walk through a decision Who it is for