Technology and evidence

Can the claim survive inspection?

We publish bounded results, exact denominators, known limitations, and the status of the mechanism being tested. The purpose is not to make the work sound mathematical. It is to make clear what was established, what remains unknown, and what evidence would change the answer.

Our method

Proof is a status, not a mood.

A test can prove one behavior without proving a product is production-ready. We keep those states separate so a result cannot quietly inherit more authority than its evidence supports.

01

Freeze the subject

Bind the exact candidate, source revision, rules, evaluator, assumptions, authority, and time boundary being examined.

02

Return 0, 1, or UNKNOWN

A bounded predicate fails, passes, or cannot be established. Missing, contradictory, stale, or unsupported evidence does not become an optimistic pass.

03

Attack the claim

Positive, negative, malformed, stale, replay, authority, and fault cases examine how the claim fails—not only how the happy path succeeds.

04

Disclose the ceiling

We label whether evidence is designed, bounded-model checked, implemented, demonstrated, deployed, or customer-established.

05

Preserve the basis

Canonical inputs, digests, counts, results, limits, and corrections stay attached so another reviewer can reproduce the same bounded question.

06

Promote only with evidence

A later stage requires its own evidence. A diagram cannot become runtime authority, and a demonstration cannot become customer authorization.

Public proof ledger · August 9, 2026

What the current evidence actually establishes.

These are bounded engineering results, not claims that the complete Serapis kernel or a customer deployment is live.

Exhaustive bounded model

44 states · 70 transitions · 710 invariant evaluations

The deliberately small Atom model examines every reachable state and transition in its finite boundary and catches ten disabled-guard mutants. It proves ten named invariants for that model—not total correctness of deployed software.

Bounded reducer and controlled demonstration

72 truth-table cases · deterministic 0 / 1 / UNKNOWN

The frozen reducer exhausts its small input domain. A synthetic case then demonstrates refusal, correction, named human disposition, a revision-bound package, and separate-process verification. Neither result creates customer-system, operational, legal, compliance, or mission effect.

Inactive brownfield observation

3 snapshots · 2,386 entries · 76 explicit unknowns

Exact selected-tree enumeration classified 2,310 path shapes and retained 76 unclassified entries. It read zero blob bytes and produced zero Atom candidates; currentness, inventory completeness, semantic completeness, and admitted product truth all remained UNKNOWN.

Implemented foundation · Non-serving

Append, replay, identity, cuts, and conflict handling

The event-store foundation exercises canonical records, expected-head checks, idempotent replay, bounded multi-stream append, consistent cuts, and fail-closed conflicts. It remains a dormant foundation until the ordered kernel layers and bounded POST are complete.

Recorded internal-plan snapshot · Not merged authority

893-case planned inventory

The recorded snapshot partitions 561 production-routed cases, 266 focused-test stand-ins, four proof-only construction-rejection cases, and 62 deferred cases. It exposes a planned denominator and deferral; it is not merged authority and does not certify a deployed product.

Formalization path · Planned after kernel closure

Model the small, high-risk core

The next formal targets are UNKNOWN-no-effect, no authority escalation, exact replay without second mutation, one CAS winner, stale evidence unable to publish, and append-only lineage—followed by differential traces against the running implementation.

The mathematics

Operational mathematics before decorative complexity.

Serapis uses three-valued decision semantics, canonical identity and digest algebra, bounded fixed points, state-transition invariants, partial-identification bounds, discovery-credit accounting, and queue-capacity models. Those tools are useful only when their assumptions and operating scope remain visible.

We do not treat a digest as truth, a confidence score as authority, a model proof as implementation proof, or a stable queue equation as a latency guarantee. The intended chain is: state the claim, expose the assumptions, check the bounded obligation, test the implementation against it, then gather operational evidence.

StatementThe exact property and boundary being claimed.
AssumptionsInputs, independence, freshness, scope, trust base, and excluded conditions.
MechanismFormula, model, checker, trace, test, or reviewer used.
Result0, 1, or UNKNOWN with the full denominator and failure carrier.
BridgeHow the model or test maps to the exact implementation and release.
CeilingWhat the result does not establish.
OUTCOME

Three-valued precedence

The bounded reducer returns 0 on explicit disqualification or prohibited effect; 1 only when approval, non-disqualification, complete adjudication, and both failure flags are clear; otherwise it returns UNKNOWN.

Y = 0 if A = 0 ∨ D = 1 ∨ prohibited_side_effect ∨ terminal_failure
Y = 1 if A = 1 ∧ D = 0 ∧ adjudication_complete ∧ ¬prohibited_side_effect ∧ ¬terminal_failure
Y = UNKNOWN otherwise
DISCOVERY

Shared credit conserves findings

When multiple independent reviews find the same root, each receives a fractional share. The shares sum to one unit per unique root instead of inflating the result.

Cᵦ = Σ 1 / m(r)
Σ Cᵦ = | ⋃ Rᵦ |
CAPACITY

Load is not a latency promise

Queue utilization is a planning condition under declared arrival, service-time, and worker assumptions. A stable mean does not by itself establish a response-time objective or tail latency.

ρ = λ · E[S] / k
ρ < 1 is necessary, not sufficient
Standards watch · Current as of August 9, 2026

Reference targets—not marketing badges.

Framework status changes. We date the note, name the source, and keep assessment, contracting, authorization, and risk acceptance with the designated Government authorities.

CMMC / DFARS

System-scoped evidence

DoD announced suspension of Phase II and later CMMC milestones on July 13, 2026; Phase I self-assessment requirements remain. Current CMMC status attaches to a specific contractor information system and contract requirement—not to Serapis as a product badge.

Read the current DoD CMMC status →
NIST SP 800-171

Version the mapping

Revision 3 is NIST’s current publication, while the current CMMC program posture continues to use Revision 2. A useful evidence system must identify the exact catalog and revision rather than blending them.

Read NIST SP 800-171 Rev. 3 →
Continuous authorization

Evidence for Government authority—not a vendor certification

Serapis is designed to support continuous evidence, traceable releases, control gates, risk views, and secure supply-chain artifacts. ATO and cATO decisions remain with the designated Government authorization authorities for the defined system boundary.

Read the DoD cATO evaluation criteria →

Serapis does not certify CMMC or NIST compliance, grant ATO or cATO, determine mission suitability, or accept customer risk. Framework mapping and assessment evidence must be established for the exact customer system and engagement.

Responsible transparency

Publish assurance. Protect attack paths.

The mathematics is not the security risk. Unbounded operational detail is. Public evidence should let a reviewer understand the claim, method, denominator, limitation, and reproducibility without exposing a customer or teaching an attacker how to bypass a live defense.

Detailed customer control mappings, architecture and data-flow diagrams, assessment workpapers, SBOM/VEX packages, and deployment evidence belong in a customer-controlled or NDA boundary.

PublicNamed invariants, aggregate hostile-test results, bounded example data, exact assurance states, limitations, corrections, and non-sensitive verifiers.
Customer-controlledSystem-specific control mappings, topology, data flows, threat models, assessment evidence, and supply-chain packages.
Never before remediationLive vulnerabilities, bypass thresholds, secrets, tenant data, internal inventories, unpatched versions, or sensitive authorization-boundary details.
Correction is part of proofA public brief should retain what changed, why the prior result was insufficient, and which evidence now supports the revision.
Ask for the basis

Do not trust us because the language sounds rigorous.

Choose one bounded claim. We will show the stage, the method, the current evidence, the limitation, and the next proof required.