What a Verified System Actually Guarantees: Refinement and the Trusted Boundary Codex (AI) | Commissioned review v1 | 2026-10-22 Formal verification can establish universal properties of software within a stated model, but the phrase verified system is incomplete without the specification, refinement relation, and trusted assumptions. This review uses seL4, CertiKOS, and IronFleet to examine how such boundaries are constructed. An executable counter example shows a finite-width implementation agreeing with an unbounded specification until overflow, while two analytical figures quantify state-space growth and the probability that random testing misses a rare trigger. We distinguish functional correctness, security properties, liveness, and empirical performance, and explain why none follows automatically from another. The proposed review method treats the proof statement and its assumptions as a maintained engineering artifact. The local examples are bounded checks of a toy model, not a new proof of any cited system. A proof has a statement, not a halo A verified component is evidence about a particular property of a particular artifact under particular assumptions. The specification may describe legal return values, preservation of memory ownership, or allowed observable traces. The proof may relate source code to an abstract state machine, or connect multiple implementation layers. Without those objects, the adjective verified communicates little that a reviewer can test. Consider a counter that records accepted jobs. An unbounded mathematical counter and an eight-bit machine counter behave identically for many short executions, then disagree when the machine counter wraps. Both can be correctly implemented relative to different specifications. The important question is which specification expresses the service's intended behavior. Verification can make the mismatch explicit, but it cannot determine the intended product requirement without a separate engineering judgment. Three demonstrations of different proof boundaries The original seL4 work establishes functional correctness from an abstract kernel specification to its C implementation while naming assumptions about the compiler, assembly, and hardware. CertiKOS develops a layered approach to a concurrent kernel, using contextual refinement to reason about modules and interleavings. IronFleet combines verification techniques for practical distributed systems and addresses both safety and liveness within its framework. These sources demonstrate that substantial verification is possible, but their results are not interchangeable certificates. A sequential kernel model, a concurrent contextual refinement, and a distributed-system liveness argument quantify over different environments. This review therefore avoids counting verified lines as a universal assurance score. The proof boundary, rather than code volume alone, determines which failures the result excludes. References: cs-05-1, cs-05-2, cs-05-3 Refinement restricts observable behavior A useful abstract view says that every observable implementation behavior must be allowed by the specification, after applying an abstraction map. The implementation may use caches, internal bookkeeping, or additional steps that have no externally visible counterpart. Those internal steps can be treated as stuttering when the refinement relation permits it. Trace inclusion is a safety-oriented statement unless termination and progress are also handled. An implementation that never returns can satisfy some weak formulations that only forbid bad finite outputs. A system expected to respond needs a liveness obligation with explicit fairness or scheduling assumptions. Similarly, a specification that permits every output is trivially easy to refine but practically useless. Review must test the specification's discriminating power, not only whether a checker accepts the proof. The overflow witness Define the abstract state as a nonnegative integer c and increment as c plus one. Define an implementation state as a b-bit unsigned integer with modular increment. Starting from zero, the two states agree for fewer than two raised to b increments. At the next increment the implementation becomes zero while the abstract state continues to two raised to b. The supplied example executes this comparison for small widths and records the first mismatch. An alternative specification that explicitly permits modular arithmetic restores agreement, but it also changes what the system promises. The correct repair depends on the application: reject further increments, widen the representation, prove a bound on lifetime operations, or adopt modular semantics. Calling the wraparound intentional without revising the external contract would merely hide the original error. What bounded exploration can establish A model checker can exhaustively explore a finite state space and reject a violating trace. That is stronger than sampling within that finite model, but the bound remains part of the result. A model with three clients does not automatically establish correctness for every client count. A proof of a cutoff or a separate inductive argument is needed to justify such extrapolation. The first figure shows the number of bit patterns, two raised to b, for increasing state width. It is not a prediction of a particular verifier's runtime: symbolic representations and invariants can avoid explicit enumeration. Its purpose is to expose why an apparently small representation change can make naive exploration infeasible. A report should distinguish the number of concrete states from the representation used by the verification method and from the states actually explored. A quantitative limit of random testing Suppose one of the two raised to b uniformly sampled input states triggers a defect. After N independent samples, the probability of missing that state is one minus two to the negative b, raised to N. For b equal to sixteen and N equal to one thousand, the miss probability is still approximately 0.9849. This constructed example explains why many passing tests may provide little evidence about a rare boundary. The model deliberately assumes uniform independent sampling. Real fuzzers can target boundaries and cover structured inputs more effectively; real bugs may occupy larger or smaller regions. The calculation is therefore not a criticism of testing in general. It is a warning against interpreting an unspecified test count as universal assurance. Proof, systematic exploration, and testing answer different questions and should be combined with their scopes intact. The trusted base is a dependency graph A proof checker, logical axioms, compiler, runtime, hardware, and imported models can all affect the conclusion, depending on where the proof ends. Some dependencies may themselves be verified; others may be tested or assumed. The boundary should be represented as a graph from the user-visible property down to the artifacts needed to establish it. This graph prevents a common reporting error: claiming end-to-end correctness after verifying one source-level module while using an unmodeled serialization library, device interface, or persistence mechanism around it. The practical task is not to eliminate every assumption before shipping software. It is to identify the assumptions that can invalidate the specific guarantee and to attach appropriate evidence or monitoring to each. A small explicit trusted base is easier to assess than an invisible one. References: cs-05-1, cs-05-2 Functional correctness is not every security property A function can follow its specification while revealing a secret through timing, exhausting a shared resource, or implementing an access policy that was incorrectly specified. Functional refinement excludes deviations from the modeled behavior; it does not automatically establish noninterference, availability under adversarial load, or resistance to every hardware side channel. A security claim must therefore identify the observer and the information they may obtain. Two executions with different secrets may need to be related, which is a different shape of property from checking one execution's output. Likewise, a confidentiality theorem may assume an initial access-control configuration that a deployment tool can violate. The configuration process then becomes part of the end-to-end argument. Strong formal results become more useful, not less, when these distinctions are stated openly. Maintenance can invalidate a once-correct argument A patch can change semantics without altering the most visible source file. Compiler flags, generated interfaces, a new foreign-function boundary, or a modified hardware target can move the implementation outside the proof's assumptions. Proof maintenance therefore belongs in the release process, with versions of the specification, implementation, checker, and imported dependencies tied together. A proposed release record should state exactly which theorem was checked and which executable artifact it covers. If a proof stops at source code, the binary relationship needs separate evidence. If a model changes, previous successful runs should remain as historical records rather than being relabeled as evidence for the new model. This is especially important when a proof repair weakens the specification: the checker may pass while the user-visible guarantee becomes smaller. A review protocol for a verified-system claim Begin by translating the theorem into a plain-language claim with quantifiers. Identify initial states, environment behaviors, failure modes, and observations. Attempt to construct a behavior that is allowed by the specification but unacceptable to the user. Then inspect the refinement chain and every trusted assumption. Finally, check whether the shipped artifact and configuration match the proof inputs. Re-run small negative controls such as the overflow witness to confirm that the validation harness rejects a known mismatch. For a real system, independent proof replay and adversarial specification review would be appropriate. They were not performed here. Our local work contributes an inspectable explanatory model and a checklist of logical obligations, not a certification of seL4, CertiKOS, IronFleet, or any production deployment. Conclusion: preserve the theorem when presenting the system Formal verification is most persuasive when the public claim retains the shape of the theorem: what is related, what is observed, what is assumed, and what is excluded. Replacing that structure with a blanket assurance discards precisely the information that makes the evidence valuable. The counter example illustrates how a specification mismatch can remain invisible in many executions. The sampling calculation explains why test volume cannot replace a universal argument. The selected systems show that substantial proofs can coexist with explicit trusted boundaries. A mature engineering practice maintains those boundaries alongside the software and treats changes to the guarantee as changes to the product. Executed finite checks Finite-width counter and a mismatched specification 515 assertions passed. Exhaustive increment traces for 2-8 bits, not verification of seL4, CertiKOS or IronFleet. { "2": 4, "3": 8, "4": 16, "5": 32, "6": 64, "7": 128, "8": 256 } Code: analysis/examples.py; results: analysis/example-results.json Equations (1) \operatorname{Obs}(\operatorname{Traces}(I))\subseteq\operatorname{Traces}(S) A schematic observable trace-refinement condition. The exact trace model, abstraction, and treatment of termination must be defined. (2) c_{k+1}=c_k+1,\qquad \hat c_{k+1}=(\hat c_k+1)\bmod 2^b Unbounded specification and finite-width implementation, both starting at zero. (3) |\mathcal S_b|=2^b Number of b-bit patterns, not necessarily the number of reachable states or the cost of symbolic verification. (4) P_{\mathrm{miss}}=(1-2^{-b})^N One defective input among all b-bit states; N independent uniform samples with replacement. Analytical figures Figure 1. Bit width expands the raw state space All bit patterns counted, without reachability reduction or symmetry. The count is not a model-checker runtime prediction. figures/verified-systems-boundaries-1.csv Figure 2. Random testing can miss one rare bad state Exactly one bad state among all equally likely b-bit patterns, sampling with replacement. This model excludes systematic tests and biased sampling. figures/verified-systems-boundaries-2.csv Comparison Evidence | Establishes within scope | Does not automatically establish Functional refinement | Implementation follows specification | Specification matches user intent Bounded model exploration | No violating trace in the explored model | Unbounded clients, steps, or inputs Security theorem | Named property for a defined observer | All side channels or denial-of-service resistance Passing tests | Observed cases behaved as asserted | Universal correctness Proposed validation protocol 1. Write the precise theorem, initial-state assumptions, and observable behavior in a reviewable record. 2. Inspect the specification for vacuity and unacceptable permitted behaviors. 3. Map the refinement chain and trusted dependencies to versioned artifacts. 4. Run the finite-width counter witness as a negative control. 5. Distinguish bounded exploration, proof replay, integration tests, and performance evaluation. 6. Revalidate the artifact relationship after changing compiler settings, interfaces, configuration, or models. Limitations 1. The local examples use ordinary Python assertions and finite enumeration, not a theorem prover. 2. The rare-trigger model assumes a single defective uniformly sampled state. 3. No proof artifacts of the cited systems were independently replayed. 4. Historical proof boundaries are described as reported in the cited work, not as a complete audit of current releases. Research questions 1. Which unacceptable user-visible behavior is still permitted by the specification? 2. What dependency changes can move a release outside the checked refinement chain? 3. Can proof replay and configuration validation be tied to the exact shipped artifact? Source evidence cs-05-1: The original seL4 paper connects an abstract kernel specification to a C implementation and explicitly names trusted assumptions. Boundary: The original result should not be expanded into every security property or every later platform. Locator: Abstract and verification assumptions. cs-05-2: CertiKOS uses layered contextual refinement to address concurrent kernel modules and interleavings. Boundary: The theorem applies to its specified contexts and modeled implementation. Locator: USENIX abstract and layered-verification description. cs-05-3: IronFleet develops verification methods for practical distributed systems, including safety and liveness reasoning. Boundary: Its assumptions and implementation scope remain part of each result. Locator: Microsoft Research publication and paper overview. References cs-05-1. Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, Thomas Sewell, Harvey Tuch, Simon Winwood. seL4: formal verification of an OS kernel. Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles (2009). https://sel4.org/Research/pdfs/sel4-formal-verification-os-kernel.pdf | DOI: 10.1145/1629575.1629596 cs-05-2. Ronghui Gu, Zhong Shao, Hao Chen, Xiongnan Wu, Jieung Kim, Vilhelm Sjoberg, David Costanzo. CertiKOS: An Extensible Architecture for Building Certified Concurrent OS Kernels. USENIX OSDI (2016). https://www.usenix.org/conference/osdi16/technical-sessions/presentation/gu cs-05-3. Chris Hawblitzel, Jon Howell, Manos Kapritsos, Jacob R. Lorch, Bryan Parno, Michael L. Roberts, Srinath Setty, Brian Zill. IronFleet: proving practical distributed systems correct. Proceedings of the 25th Symposium on Operating Systems Principles (2015). https://www.microsoft.com/en-us/research/publication/ironfleet-proving-practical-distributed-systems-correct/ | DOI: 10.1145/2815400.2815428 cs-05-1 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-05-2 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-05-3 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. Provenance A focused analytical review of three selected foundational primary sources, with original worked examples. This is not an exhaustive or systematic survey of the literature through 2026. Source access and version notes are recorded with the bibliography. Written and technically self-reviewed by Codex (AI). References identify the original researchers; the analytical constructions and proposed evaluation designs are attributed to this article. Covers are conceptual ImageGen illustrations. Technical figures are computed from declared models or finite examples, with Python and CSV supplied. They are not measurements of deployed products or reproduced performance benchmarks. This local draft has no independent peer-review or journal-acceptance record. Bounded executable examples check the stated small models; they are not formal verification of the cited systems.