×

Code

Challenges

  • Behavioral requirements are often scattered between code, tests, and prose.
  • Regression suites sample behavior but cannot enumerate every execution path.
  • Interfaces and assumptions drift as systems and dependencies change.
  • Critical guarantees need evidence that remains connected to implementation.

Problems We Solve

  • Specification Modeling Express interfaces, invariants, and assumptions explicitly.
  • Property Checking Evaluate implementation behavior against stated properties.
  • Counterexample Search Explore paths that violate a proposed guarantee.
  • Regression Assurance Track which guarantees remain valid after a change.
  • Proof Artifacts Keep machine-checkable evidence with the relevant code.

Domain portfolio

Application patterns

Compare two formal-assurance approaches, then explore the domain workflows as interactive state machines.

Software assurance connects specifications, implementation assumptions, proof obligations, regression constraints, tests, and release evidence. Verified readback can help engineers turn a prose property into a setup-scoped Agda proposition and inspect its deterministic reading before adopting it as intended specification. It complements, but does not replace, proof construction, static analysis, model checking, testing, code review, or operational validation. A type-correct proposition may still be false, too weak, inconsistent with policy, unrelated to the shipped implementation, or different from what its author meant.
01 Authorization-policy specification for service APIs Explore pattern

System/use case

A security-engineering workbench for reviewing authorization invariants across service endpoints, principal roles, resources, tenant boundaries, and delegated capabilities. It formalizes narrowly stated claims that otherwise live across threat models, middleware code, route configuration, and integration tests.

Operational setting

Platform and product-security engineers use the workbench during API design and change review. A setup names abstract principals, resources, operations, policy decisions, tenancy relations, authentication states, and audit events. It deliberately excludes credentials and production request data. Existing policy engines remain responsible for runtime decisions.

Decision/claim boundary

The checked claim concerns the modeled authorization relation—for example, that every permitted cross-tenant read requires an explicitly modeled delegation. It does not show that identity data are genuine, that the policy is appropriate, that middleware enforces it, that side channels are absent, or that the service is secure. Security owners retain authority over threat acceptance and release.

Candidate checked statements

Illustrative controlled-English propositions for a future setup include:

  • “Every permitted resource mutation has an authenticated principal.”
  • “A principal without cross-tenant delegation cannot read another tenant’s protected resource.”
  • “Revoked capability state cannot produce a permit decision.”
  • “Every privileged policy override produces an accountable audit event.”

These are candidate schemas, not implemented policies or already proved security properties.

Example architecture

An interface-definition pipeline and policy repository export versioned semantic identifiers to a curated setup. FF Scribe runs in the engineering environment and has no path to production authorization or secrets. It stores the setup revision, proposed type, compiler result, deterministic reading family, and explicit reviewer decision. A separate verification pipeline may connect accepted propositions to policy-engine proofs, static analysis, generated tests, and negative integration tests. Deployment tooling admits artifacts only through the organization’s existing approval and provenance controls. Human security reviewers own threat-model alignment and exceptions.

Where verified readback fits

An engineer states the intended invariant in natural language. The proposal step may use only the setup vocabulary and either returns one Agda type or requests clarification. Agda checks formation, names, applications, and types. If the checked structure is supported by the partial readback translator, ff-readback renders a finite audited family while preserving binders and premise order; otherwise it fails visibly. The engineer compares successful readings with the intended policy, explicitly accepts one, or gives feedback. Confirmation records the specification’s meaning; it neither proves the proposition nor deploys a policy.

Potential benefits

This makes quantifier scope, deny/permit polarity, tenancy relations, and override prerequisites visible during review. The accepted artifact can provide a stable join point among threat-model claims, enforcement code, and regression tests. Setup-version changes can identify properties needing reassessment when roles, endpoints, or decision semantics evolve.

Limits/adoption considerations

Type correctness is distinct from factual truth about runtime requests, correctness of the security policy, real-world security, proof completion, and user-intent confirmation. Those need authenticated evidence, security governance, implementation and adversarial validation, an actual proof or analysis result, and explicit practitioner acceptance. Incomplete endpoint inventories, confused-deputy paths, caching, and distributed enforcement may invalidate a small abstraction. Setup ownership and exact mapping to shipped middleware are therefore central.
02 Idempotent event-processing and retry assurance Explore pattern

System/use case

A distributed-systems specification assistant for event consumers and workflow orchestrators, focused on delivery duplication, idempotency keys, retry transitions, deduplication windows, commit ordering, compensation, and terminal failure handling.

Operational setting

Service owners and reliability engineers use it while designing event-driven workflows or reviewing changes to brokers, consumers, and state stores. A setup represents abstract messages, operation identifiers, processing states, side-effect records, acknowledgements, retries, and compensations. Production traces can be linked as evidence but are not sent into the formalization loop by default.

Decision/claim boundary

The proposition describes the abstract processing protocol, such as whether repeated delivery of the same operation identifier is required to preserve an externally visible result. It does not establish broker behavior, atomicity of a concrete database transaction, correctness of identifier generation, or exactly-once execution. Architecture and operational owners decide whether the protocol and evidence support deployment.

Candidate checked statements

Possible controlled-English propositions include:

  • “Repeated delivery of one committed operation does not create a second modeled side effect.”
  • “Acknowledgement occurs only after the associated outcome is durably recorded.”
  • “Every exhausted retry transitions either to compensation or to manual intervention.”
  • “A compensated operation cannot also be marked successfully completed.”

They illustrate potential formal statements rather than guarantees of a particular platform.

Example architecture

An architecture registry supplies stable event, workflow-state, and storage-operation names. FF Scribe produces accepted type/readback pairs in a design repository. A separate model checker or proof project analyzes state transitions, while property-based tests exercise adapters and fault-injection runs produce empirical evidence for failure paths. Telemetry links deployed workflow versions to observed outcomes. The proposition authoring service cannot publish messages, mutate state, or change orchestrator definitions. Service owners review consistency among the abstraction, implementation, and runbooks.

Where verified readback fits

The engineer describes a retry or consistency property. Translation yields a setup-scoped candidate proposition; ambiguous distinctions such as delivery versus processing or recorded versus externally visible outcome prompt clarification. Agda checks type correctness. The separate partial readback stage either exposes a supported premise-and-conclusion structure through the deterministic audited family or reports unsupported structure. The engineer accepts only if message identity, scope, and terminal states match the intended semantics; otherwise feedback begins a new bounded pass.

Potential benefits

The workflow can prevent an informal “exactly once” claim from concealing narrower assumptions. It gives application, platform, and SRE teams a common review object and can drive targeted failure-injection scenarios. Explicitly modeled fail states and compensations improve traceability between architectural intent and operational recovery procedures.

Limits/adoption considerations

A well-typed proposition is not a fact about a live broker, evidence that a consistency policy is appropriate, proof of safe behavior under every failure, a completed proof, or confirmation of meaning. Runtime instrumentation, architectural judgment, verification and chaos testing, proof artifacts, and human acceptance remain separate. Clocks, partitions, crash recovery, external side effects, and retention boundaries must be represented when material; omitting them can make a true model property irrelevant to production.
03 Compiler intermediate-representation transformation review Explore pattern

System/use case

A compiler-engineering assistant for stating preservation obligations around intermediate-representation (IR) lowering, optimization passes, control-flow rewrites, and backend code generation. It focuses on the exact proposition a proof or translation-validation step is expected to discharge.

Operational setting

Compiler developers work against a setup containing source and target IR categories, evaluation or simulation relations, typing judgments, observations, and pass identifiers. The setup may reference existing mechanized semantics, but FF Scribe proposes only a type expression and never synthesizes or claims the proof. Continuous integration separately builds the compiler and proof artifacts.

Decision/claim boundary

The checked proposition can state semantic preservation, typing preservation, or refinement in the declared formal model. It does not show the theorem is inhabited, the semantics match deployed machines, the implementation corresponds to the modeled transformation, or generated code is defect-free. Compiler maintainers decide whether evidence is sufficient to merge or release.

Candidate checked statements

Illustrative propositions include:

  • “Every well-typed source program transformed by constant folding has an observationally equivalent target program.”
  • “If a source step is simulated, the corresponding target execution preserves the declared observation.”
  • “Every accepted lowering result is well typed in the target intermediate representation.”
  • “A failed transformation cannot be classified as a successful compilation result.”

These are possible goal shapes, not proof-complete theorems or claims of current adapter coverage.

Example architecture

The mechanized-semantics repository owns definitions and quoted names; a setup curator exposes a small audited vocabulary and readback profile. FF Scribe inserts a candidate only into a designated proposition hole, and Agda checks it in an isolated generated module. Accepted propositions enter code review beside proof files, translation validators, differential tests, and compiler revisions. CI verifies those independent artifacts. The readback service has no authority to merge changes or mark a theorem proved, and maintainers inspect the assumptions and implementation mapping.

Where verified readback fits

A compiler engineer describes the intended obligation. Setup-scoped translation produces one type, with clarification for ambiguous equivalence, termination, or observation notions. Agda verifies that the expression is meaningful in the formal environment. ff-readback then either renders a supported checked type through audited candidates or fails visibly; it never invents a prose summary for unsupported structure. The engineer confirms whether a successful reading captures the goal. Only a separately supplied proof term, successful model analysis, or other accepted evidence can establish the proposition.

Potential benefits

Verified readback can help a reviewer catch a preservation goal stated in the wrong direction, a missing well-typedness premise, or unintended quantification before proof work begins; it does not discover those defects on its own. It also provides reviewers unfamiliar with Agda syntax a stable, provenance-bearing view of the theorem interface and helps keep proof obligations connected to pass changes.

Limits/adoption considerations

Type correctness does not mean the proposition is true, the chosen refinement policy is correct, generated programs are safe, a proof is complete, or the wording matches the author. Definitions can also be vacuous or too weak. Reviewers must inspect semantic adequacy, assumptions, proof terms, implementation correspondence, trusted computing base, and explicit intent. Rich dependent or existential results may exceed current readback support and must fail visibly rather than be paraphrased incompletely.
04 Embedded-control firmware release invariants Explore pattern

System/use case

A release-assurance tool for safety- or mission-relevant embedded firmware, used to express mode-transition, actuator-command, watchdog, initialization, and degraded-operation invariants across software revisions.

Operational setting

Firmware, controls, verification, and systems engineers use a setup that names controller modes, inputs, command states, timing abstractions, fault states, and permitted transitions. The artifact links to source revisions, interface-control documents, hardware-in-the-loop campaigns, and requirements coverage. FF Scribe remains outside the build signer, flashing tools, and target control path.

Decision/claim boundary

The proposition states a property of the abstract controller model, such as command inhibition in a fault state or initialization before enabling an output. It does not demonstrate sensor validity, deadline satisfaction on hardware, adequacy of the control law, binary equivalence, or system safety. Accountable engineering and release authorities own approval.

Candidate checked statements

Potential controlled-English propositions include:

  • “Every transition to actuator-enabled mode requires completed initialization.”
  • “An active critical fault inhibits every modeled actuator command.”
  • “Every watchdog-expiry transition enters a declared degraded or safe state.”
  • “A manual override remains represented in every autonomous control mode.”

They are illustrative statement forms, not certified requirements or verified firmware guarantees.

Example architecture

A requirements repository and model exporter generate a reviewed setup with stable identifiers. FF Scribe checks and reads back proposed requirements, recording explicit engineer acceptance. A verification pipeline separately links each accepted proposition to proofs, static-analysis results, unit and integration tests, hardware-in-the-loop evidence, compiler configuration, and signed binaries. Runtime monitors may observe related states but do not consume informal readbacks as executable policy. Existing independence, change-control, and release gates remain authoritative.

Where verified readback fits

An engineer supplies the natural-language invariant. The agent constructs a setup-scoped proposition, and Agda validates its type. If the separate partial translation supports that structure, ff-readback produces a finite audited family tied to the checked declaration; unsupported structure fails visibly. The engineer checks trigger, state, quantifier, and exception semantics and explicitly accepts or provides feedback. The accepted result is a reviewed specification artifact, not evidence that the firmware satisfies it.

Potential benefits

This creates precise anchors for regression coverage and change-impact analysis. It can expose confusion between fault detection and fault response, or between output request and physical actuation, before those ambiguities spread into tests. Deterministic readings help systems and verification specialists review formal requirements without relying on generated prose.

Limits/adoption considerations

Type correctness, factual behavior of the binary and hardware, policy adequacy, real-world safety, proof completion, and user-intent confirmation are independent. Traceable build evidence, governed requirements, target-level validation, proofs or analyses, and explicit practitioner review are all necessary. Timing, concurrency, interrupt behavior, numeric error, toolchain assumptions, and hardware failure modes can make a transition-only model insufficient. Adoption requires configuration control and a defensible mapping from model states to the delivered system.

Applicability frame

MLTTDB is most plausible here as a governed catalog of proof-assistant terms. Row types and :T: table declarations remain in Agda, Lean, or Rocq source; the SQLite term store keeps ordered source-language rows, UUIDs, projection values, and metadata; and a proof assistant performs semantic checking. The store can orchestrate a validation process but does not itself establish program correctness. Repository, CI, identity and access management, runtime enforcement, source-system reconciliation, and release approval stay outside the MLTTDB boundary. Agda currently supports UUID-based finite-table lookup in stored bodies; Lean and Rocq preprocessors validate generated definitions but do not provide that lookup.

Current data mode checks fetched rows as separate definitions; it does not expose a table to application proofs as an enumerable, first-class collection. Whenever an example below claims whole-snapshot coverage, uniqueness, graph acyclicity, or aggregate compatibility, the architecture therefore assumes either a finite domain declared in proof source or an external snapshot compiler that emits a reconciled aggregate manifest/certificate term. The proof assistant checks that aggregate term, while external reconciliation establishes that it represents the table export supplied to CI.

01 Versioned API and protocol contract catalog Explore pattern

Operational context

A platform organization operates public REST endpoints, asynchronous event schemas, and service-to-service protocols across independently released teams. OpenAPI or schema-registry checks catch syntactic incompatibility, but architectural constraints also concern request-state transitions, idempotency keys, error refinement, authorization scopes, and which older consumers a release must preserve. Reviewers need to distinguish a changed declaration from a change that actually invalidates an approved compatibility argument.

Why MLTTDB fits

The stable part of this problem is a typed vocabulary of protocol versions, operations, transition preconditions, and compatibility witnesses; the changing part is the catalog of approved contract instances. MLTTDB can keep those instances as ordered proof-language terms and rerun their proofs when the source model evolves. UUIDs provide durable row identities for review and cross-system references, while the proof assistant—not the store—checks that a witness inhabits the declared compatibility type.

Example architecture

OpenAPI / AsyncAPI / IDL repositories
              |
      external contract compiler
              v
candidate typed rows + provenance manifest
              |
      reviewed admin/API import
              v
   SQLite MLTTDB term store
              |
   CI data-mode validation
              v
   Agda / Lean / Rocq checker
              |
     signed CI result bundle
              v
  release policy and human approval

The external compiler normalizes source contracts and proposes proof-language rows; it also records repository commit, generator version, and source pointer in an ordinary provenance system. A contract-model repository owns the row types and compatibility predicates. The term store owns approved ordered terms and identifiers. CI selects the matching checker path and publishes generated source, diagnostics, and commit linkage. A separate release controller consumes the result under organization policy.

Representative typed artifacts

Illustrative row types include EndpointVersion, Transition, ConsumerAssumption, and CompatibilityCase old new. Tables might be declared as supportedVersions :T: EndpointVersion and requiredCases :T: CompatibilityCase. A reconciled ContractCatalogManifest aggregate term enumerates the versions, assumptions, breaking changes, and case UUIDs whose whole-snapshot coverage is checked. A row can encode that POST /payments in version 3 refines the documented outcomes of version 2 under a named assumption set. In Agda, a case may use finite lookup to refer to an earlier version by UUID; in Lean or Rocq, the preprocessing workflow must instead use ordinary generated identifiers or self-contained rows.

Checks and evidence

For the compiler-reconciled manifest, the checker can establish that every enumerated breaking change has an explicit migration disposition, every enumerated consumer assumption is covered by a compatibility case, transition refinements preserve modeled invariants, and references resolve within the declared finite domain. Negative fixtures should demonstrate rejection of missing cases and invalid witnesses. Evidence should retain source commit, exact table snapshot or export, manifest digest and reconciliation, checker version, generated file where applicable, stdout/stderr, and policy decision. MLTTDB does not prove that deployed handlers implement the modeled contract; conformance and integration tests provide that separate evidence.

Potential benefits

Teams gain a reviewable compatibility argument rather than a collection of schema diffs. Rechecking localizes drift when shared assumptions change, and stable UUIDs let issue trackers and waivers point to the same catalog entries. Machine checking can reduce inconsistent interpretation across service teams while leaving ownership and release authority explicit.

Deployment boundary

Run this as CI or release-time assurance on reviewed snapshots, not in the request path. Protect administrative writes through external IAM and change control. Raw specifications are not ingested by MLTTDB without a reviewed adapter, and a passing proof is only evidence about the formalized model. Qualified API owners and formal-methods reviewers must approve the mapping and decide whether the evidence is sufficient.
02 Authorization policy change assurance Explore pattern

Operational context

A multi-tenant SaaS platform manages role, relationship, and attribute-based access rules across control-plane APIs. Proposed changes arrive as policy-as-code pull requests, entitlement catalog updates, and temporary exception requests. Security engineers need to know whether a change introduces cross-tenant access, violates separation of duties, leaves a privileged action without a review path, or broadens an emergency role beyond its approved resource set.

Why MLTTDB fits

Authorization assurance has a compact typed core: subjects, tenant boundaries, resources, actions, grants, denials, delegations, and invariants. The approved scenarios and exception terms change more frequently than the proof framework. MLTTDB can separate the proof-owned authorization model from an editable term catalog, then ask the proof assistant to validate that each stored grant or change witness meets the declared constraints. It is an assurance layer; it does not evaluate live requests.

Example architecture

IAM catalog + policy repository + ticketing
                   |
     external reconciler and candidate builder
                   v
          isolated review workspace
                   |
   MLTTDB records with ticket/source metadata
                   |
   store-owned verify endpoint or local CI
                   v
          proof-assistant checker
                   |
    security review packet and approval
                   v
      external policy deployment pipeline

The reconciler joins identities, policy declarations, and exception tickets, then emits candidates; source reconciliation remains its responsibility. Reviewers edit or accept proof-language records in a restricted workspace. Store-owned verification may launch the configured Agda, Lean, or Rocq validation backend, but returned success is the subprocess result. The deployment pipeline independently verifies approvals, commits, and environment targeting.

Representative typed artifacts

Useful types include PrincipalClass, ResourceScope, Action, Grant, Constraint, and ApprovedException. Tables such as baselineGrants :T: Grant and changeCases :T: AuthorizationChange can express tenant-preservation, non-escalation, and two-person administration obligations. A change artifact may carry a proposed grant together with a proof that its resource scope is a subset of the role’s approved scope. Another can model a time-bounded exception at the type level while leaving wall-clock evaluation to the surrounding workflow.

Checks and evidence

Validation can reject a grant whose tenant indices differ, a delegation that escapes its modeled parent scope, a privileged action with no modeled approval class, or incompatible roles assigned in the same reviewed scenario. It can require each exception to name a control owner and a formally valid compensating constraint. Evidence combines checker output with the policy commit, candidate-generation manifest, reviewer identities, and external reconciliation report. Live directory membership, ticket validity, current time, and deployed policy state are external facts; the formal check only covers their encoded snapshot.

Potential benefits

Security review becomes focused on explicit counterexamples and assumptions instead of diffuse policy text. Typed changes can expose unintended privilege expansion before deployment, and repeatable validation provides consistent regression evidence when common roles or invariants change. The model also gives reviewers a precise vocabulary for distinguishing a policy defect from stale or incorrectly reconciled source data.

Deployment boundary

Keep MLTTDB outside the production authorization decision point and fail no live request solely on its availability. Use a protected pre-production workspace and an external approval/deployment service. Do not claim completeness unless the reconciler’s coverage is independently measured. Security owners must review the formal policy abstraction, and production rollout should retain native policy-engine tests, canary controls, rollback, and monitoring.
03 Safety-critical embedded configuration baseline Explore pattern

Operational context

An embedded-controls program ships product variants with calibrated thresholds, sensor channel assignments, actuator limits, watchdog timings, and feature interlocks. Values are maintained by systems, controls, and manufacturing engineers and ultimately transformed into generated headers or calibration images. A locally plausible value can still violate a cross-parameter invariant, select hardware absent from a variant, or invalidate an established timing budget.

Why MLTTDB fits

Configuration baselines are finite, highly structured, and amenable to dependent typing: a channel assignment can be indexed by hardware variant, a threshold by engineering unit and admissible range, and an interlock by the states in which it must hold. MLTTDB can store reviewed source-language configuration terms independently of the proof model and validate them as a release snapshot. This supplements, but cannot replace, system safety analysis and target testing.

Example architecture

requirements + hardware definition + calibration tool
                      |
   controlled external transformation and review
                      v
      variant-specific MLTTDB database
                      |
     locked release candidate snapshot
                      |
        Agda data-mode validation
                      v
   checked ordinary definitions / diagnostics
                      |
   qualified generator and build pipeline
                      v
   HIL tests, safety review, signed release

Requirements management and hardware tools remain authoritative for their respective facts. A controlled adapter proposes typed terms and a reconciliation report. The proof source owns units, ranges, compatibility relations, and variant indexes. The term store maintains the ordered candidate baseline. Agda is attractive when later rows must refer to earlier catalog entries through literal UUID finite lookup; if Lean or Rocq is selected, rows must use the supported generated-definition model without that lookup.

Representative typed artifacts

Types might include Channel variant sensorKind, Bounded unit low high, WatchdogBudget taskSet, and Interlock machineState actuator. Tables such as sensors :T: SensorBinding VariantA and parameters :T: CalibratedParameter VariantA hold concrete selections. A motor-current limit can be represented as a value carrying evidence that it lies within the variant’s electrical and thermal envelope. A watchdog row can carry a proof that the declared period dominates the modeled worst-case execution allowance.

Checks and evidence

The proof assistant can check range membership, uniqueness of modeled channel assignments, compatibility between sensor type and input circuit, monotonic alarm thresholds, and completeness against a finite list represented in the formal model. The release packet should include the term snapshot, source requirements references, transformation report, proof source revision, checker/toolchain fingerprint, and generated configuration digest. It must also record simulation, hardware-in-the-loop, fault-injection, and traceability results because MLTTDB does not establish plant behavior, compiler correctness, hardware conformance, or coverage of the safety requirements.

Potential benefits

The approach can make configuration assumptions executable, catch invalid variant combinations before expensive target testing, and provide reproducible evidence that a released baseline satisfied a specific formal model. Separating row data from the proof source lets calibration changes be reviewed without weakening the invariants, while UUIDs support stable linkage to engineering change records.

Deployment boundary

Use MLTTDB only in a qualified release workflow with read-only candidate snapshots during validation. It is not a certified configuration-management system, code generator, or safety case. Existing configuration control, independence requirements, tool qualification arguments, target verification, and responsible engineer sign-off remain mandatory. Any production use requires a domain-specific hazard assessment and qualified review of both the formalization and data transformation.
04 Database migration compatibility dossier Explore pattern

Operational context

A data platform performs rolling migrations across application versions: column splits, enum evolution, backfills, index changes, and event/outbox transitions. During a zero-downtime window, old and new binaries may read and write the same logical data. Migration tooling can order DDL, but teams still need evidence that mixed-version reads are defined, transformations preserve modeled invariants, retries are idempotent, and rollback remains possible at each declared stage.

Why MLTTDB fits

A migration plan is naturally a finite collection of schema states, transformations, compatibility obligations, and stage witnesses. MLTTDB can hold the current plan as typed proof-language records while a proof repository defines what makes each stage safe. Revalidation after a schema or transformation change exposes which witnesses no longer type-check. Explicit StageIndex and predecessor/successor relations in a reconciled plan manifest carry sequence semantics; the store preserves deterministic presentation and generated-definition emission order, not a proof-visible ordinal.

Example architecture

migration DSL + schema history + application contracts
                       |
      external plan extractor and test generator
                       v
    MLTTDB migration dossier (review branch)
                       |
        project-owned CI validation
                       v
         Lean / Rocq / Agda checker
                       |
   proof result + generated source + DB tests
                       v
   change advisory and deployment orchestrator

The extractor builds candidate terms from migration and application repositories; it does not gain authority over either source. The formal model defines abstract rows, transformations, mixed-version operations, and required obligations. MLTTDB stores reviewed plan instances. CI validates the terms and also runs database-native migration, rollback, and property tests. The deployment orchestrator controls locks, sequencing, observation windows, and abort criteria.

Representative typed artifacts

Candidate types include SchemaState, MigrationStep from to, BackwardRead old new, ForwardWrite old new, and RollbackWitness stage. Tables might be stages :T: MigrationStage and obligations :T: StageObligation. A column-split step can carry total abstract encode/decode functions and proofs for the modeled round trip. A backfill stage can state that old readers remain defined while dual-write is active. For Agda, finite UUID lookup can link an obligation to an earlier stored stage; Lean and Rocq workflows should encode those relationships through ordinary preprocessed definitions.

Checks and evidence

Checks can cover stage ordering, modeled transform totality, round-trip or refinement properties, presence of compatibility witnesses for supported application-version pairs, and rollback obligations before destructive steps. The dossier should bind results to migration commits, application contract versions, database engine/version, generated source, and executable integration-test reports. Formal proofs do not guarantee SQL semantics, production data quality, lock behavior, query-plan stability, or that the extracted model matches every caller; those are separate validation targets.

Potential benefits

Reviewers receive a coherent compatibility case rather than independent DDL, runbook, and test artifacts. A change to a shared schema state triggers focused rechecking of dependent obligations. Stable row identities improve linkage among migration tickets, test results, and exceptions, while explicit stages make rollback assumptions visible before deployment.

Deployment boundary

This is pre-deployment and change-window assurance, never the migration executor. Run validation against immutable release candidates and require database-native rehearsals on representative copies. External IAM, approvals, backup verification, observability, and rollback control remain authoritative. Database owners and application teams must review the abstraction and evidence; MLTTDB should not authorize or automatically initiate a production migration.

These read-only, pan-and-zoom models expose three abstraction levels for each workflow. They are explanatory examples, not live operational or decision systems.

01

Distributed transaction coordination

About this workflow

This example represents coordination of one logical transaction across services or resource managers that cannot rely on a single local database commit. It models the practical guarantees around reservations, durable prepare decisions, commit propagation, compensation, retries, and ambiguous outcomes. The workflow assumes messages may be delayed or repeated and that a participant may fail after completing work but before acknowledging it.

The transaction begins by recording the externally required atomic outcome, the participating systems, and the consistency assumptions. Resource reservation requests bounded holds and records participant versions and expiry times. A conflict routes to compensation, because any work already performed or reserved must be released in dependency order. Complete reservations move to the prepared state only after durable acknowledgements are verified and the coordinator’s decision context has been persisted.

Once a commit decision is durable, it is propagated with retry-safe identifiers. Confirmed acknowledgements lead to a completed transaction and an evidence record of the externally visible result. A timeout during prepare triggers compensation, but uncertainty after commit cannot safely be treated as failure: a participant may already have committed. That path enters outcome review, quarantines the ambiguous case, and resolves the authoritative result from durable coordinator and participant evidence. Review may confirm completion or authorize a safe retry. Failed compensation also enters review rather than silently beginning a second transaction.

These controls matter because an unqualified retry can duplicate a charge, shipment, booking, or ledger movement, while an unqualified rollback can contradict an already committed participant. Reservation versions and expiries protect against stale holds; durable decisions prevent the coordinator from changing its answer after recovery; idempotency identifiers make redelivery safe; and outcome review creates an explicit operational state for “unknown” instead of forcing it into success or failure. The result is a reproducible protocol trace that engineering and operations can use to reconcile customer-visible outcomes.

Layer 1 — Transaction guarantee lifecycle

This layer describes the guarantee from request through reservation, preparation, commit, completion, compensation, or outcome review. It is the architecture and incident-management view of whether the logical transaction is pending, decided, visible, reversed, or uncertain. It excludes participant API calls, retry counters, and persistence commands so the global consistency story remains understandable.

Layer 2 — Participant coordination

This layer shows how the coordinator manages resource holds, prepare acknowledgements, a durable decision, commit delivery, dependency-ordered compensation, and authoritative outcome review. It includes the protocol boundaries and recovery routes between participants. It intentionally excludes the business implementation inside each participant and the low-level mechanics of individual reads, writes, and messages.

Layer 3 — Protocol checks and actions

This layer contains the concrete protocol work: collect versions and expiries, validate durable prepare records, persist decision context, publish commit with an idempotency key, reconcile acknowledgements, issue compensations, and inspect durable evidence. It provides enough scope for instrumentation and automated checks while leaving the overall customer outcome and cross-service guarantee to the higher layers.
02

Rolling deployment assurance

About this workflow

This example represents a production release managed as a sequence of evidence-backed decisions rather than a single “deploy” operation. It connects the approved release intent and artifact identity to pre-deployment requirements, canary behavior, progressive fleet expansion, final verification, and rollback. The goal is to preserve stated service and compatibility guarantees while exposing a change gradually enough to contain regressions.

The workflow begins when a release is planned. The team records the behavior being changed, the guarantees that must remain true, and the exact artifacts and configuration covered by the deployment specification. Requirements validation checks interface and configuration preconditions and runs the admission suite—tests, property checks, or other regression evidence required for that service. A failed admission returns the release for rework rather than allowing operational confidence to substitute for a missing prerequisite.

An admitted release reaches a canary population. Its signals are compared with an explicit acceptance envelope, not merely watched for obvious crashes. Healthy observation permits fleet expansion in bounded batches, with health and compatibility reevaluated at every boundary. A canary regression or later batch regression freezes expansion and activates rollback. Rollback restores the last compatible artifact and configuration, verifies that restoration, and returns the work to release planning. Even after fleet-wide verification, a post-release regression can reopen rollback; the verified state is evidence, not an irreversible declaration of success.

These controls matter because distributed production systems can pass build-time tests yet fail under real traffic, data shape, dependency behavior, or gradual capacity changes. Binding artifacts to requirements prevents deploying something different from what was reviewed. Canary and batch gates limit blast radius, while an explicit rollback path avoids improvising under incident pressure. Retaining the release-to-evidence trace lets engineering, SRE, and change reviewers reproduce why each rollout boundary was crossed.

Layer 1 — Deployment assurance lifecycle

This layer is the release owner’s end-to-end view: planned, admitted, canaried, expanding, verified, or rolling back. It shows the major assurance gates and every route that returns the change to planning. It deliberately excludes individual cluster operations, metric queries, and test invocations so stakeholders can understand release posture and risk containment across the whole campaign.

Layer 2 — Release orchestration

This is the working view for release engineering and SRE. It covers artifact binding, prerequisite admission, canary scope, acceptance envelopes, rollout batches, health evaluation, rollback coordination, and final evidence capture. It includes when orchestration must stop, advance, or restore a checkpoint, but excludes tool-specific commands and the implementation of each probe or deployment action.

Layer 3 — Deployment checks and actions

This layer contains the executable control steps: validate configuration and interfaces, run regression checks, place canary instances, query service signals, compare thresholds, advance a batch, freeze deployment, restore artifacts, and verify service objectives. It is detailed enough to automate and audit a gate. It intentionally leaves release-wide approval and risk posture to the higher layers.
03

Versioned API and data migration

About this workflow

This example represents a compatibility-led change to an API contract and its stored data. Instead of treating schema conversion, client adoption, and traffic cutover as separate projects, it keeps them in one controlled lifecycle: proposed invariants, compatibility review, shadow conversion, dual operation, cutover, legacy retirement, and remediation. This is suitable for changes where old and new readers or writers coexist for a meaningful period.

The workflow begins by stating interface and data invariants and inventorying every consumer, writer, and stored version affected. Compatibility review compares old and new assumptions and searches for representative counterexamples, such as an old client omitting a newly required field or a conversion losing domain meaning. A rejected review returns to design. An accepted design moves to shadow migration, where a replayable cohort is converted without becoming authoritative and source and target results are compared semantically rather than only byte-for-byte.

Converged shadow results permit dual operation: versioned reads and writes run in parallel while adoption and data convergence are measured. Drift opens remediation. Once consumers have adopted the new version, cutover moves traffic across a controlled boundary and verifies checkpoints before fallback routes are retired. Divergence, dual-run drift, or a failed cutover is classified and repaired; the repair may be replayed through shadow migration or the known fallback restored in dual operation. Legacy mutation paths are disabled only after cutover verification, and the compatibility evidence is retained with the retired version.

These controls matter because a superficially successful backfill can still change business meaning, while a correct new API can fail when an overlooked consumer continues using an older contract. Replayable cohorts make fixes testable, dual operation exposes live incompatibilities without an abrupt one-way switch, and checkpoints make recovery bounded. The retained proof and regression constraints help prevent the next version from reintroducing a previously solved incompatibility.

Layer 1 — Compatibility migration lifecycle

This layer is the program-level view from proposal to verified legacy retirement. It shows readiness, coexistence, cutover, and every remediation loop, allowing service owners to answer whether the migration is reversible and what remains dependent on the old version. It deliberately excludes endpoint fields, conversion records, and individual consumer calls so the overall compatibility posture stays visible.

Layer 2 — Version and data operations

This is the working view for platform, application, and data teams. It covers contract review, consumer inventory, shadow cohorts, semantic comparison, dual reads and writes, adoption tracking, traffic cutover, fallback routes, repair replay, and legacy shutdown. It includes the operational boundaries shared across teams but excludes the exact assertions, transforms, feature-flag operations, and data commands.

Layer 3 — Migration checks and actions

This layer describes executable checks and changes: validate contract assumptions, generate counterexamples, convert and replay a cohort, compare source and target semantics, measure convergence, verify checkpoints, shift traffic, repair mappings, and disable legacy mutations. It is scoped for automation and audit. It intentionally leaves migration-wide authorization and compatibility status to the higher layers.
Interactive state machine

Workflow demo
Skip to content

Domains

Code

Placeholder domain page for code rules involving specifications, proofs, and regression constraints.

  • specifications
  • proofs
  • regression constraints

Problems we solve

Checked boundaries and evidence

  • Behavioral requirements are often scattered between code, tests, and prose.
  • Regression suites sample behavior but cannot enumerate every execution path.
  • Interfaces and assumptions drift as systems and dependencies change.
  • Critical guarantees need evidence that remains connected to implementation.
Specification Modeling

Express interfaces, invariants, and assumptions explicitly.

Property Checking

Evaluate implementation behavior against stated properties.

Counterexample Search

Explore paths that violate a proposed guarantee.

Regression Assurance

Track which guarantees remain valid after a change.

Proof Artifacts

Keep machine-checkable evidence with the relevant code.

Application patterns

Imported product records

These panels use the same generated application portfolio as the desktop workbench.

FF Scribe4 patterns
Software assurance connects specifications, implementation assumptions, proof obligations, regression constraints, tests, and release evidence. Verified readback can help engineers turn a prose property into a setup-scoped Agda proposition and inspect its deterministic reading before adopting it as intended specification. It complements, but does not replace, proof construction, static analysis, model checking, testing, code review, or operational validation. A type-correct proposition may still be false, too weak, inconsistent with policy, unrelated to the shipped implementation, or different from what its author meant.
01Authorization-policy specification for service APIs

System/use case

A security-engineering workbench for reviewing authorization invariants across service endpoints, principal roles, resources, tenant boundaries, and delegated capabilities. It formalizes narrowly stated claims that otherwise live across threat models, middleware code, route configuration, and integration tests.

Operational setting

Platform and product-security engineers use the workbench during API design and change review. A setup names abstract principals, resources, operations, policy decisions, tenancy relations, authentication states, and audit events. It deliberately excludes credentials and production request data. Existing policy engines remain responsible for runtime decisions.

Decision/claim boundary

The checked claim concerns the modeled authorization relation—for example, that every permitted cross-tenant read requires an explicitly modeled delegation. It does not show that identity data are genuine, that the policy is appropriate, that middleware enforces it, that side channels are absent, or that the service is secure. Security owners retain authority over threat acceptance and release.

Candidate checked statements

Illustrative controlled-English propositions for a future setup include:

  • “Every permitted resource mutation has an authenticated principal.”
  • “A principal without cross-tenant delegation cannot read another tenant’s protected resource.”
  • “Revoked capability state cannot produce a permit decision.”
  • “Every privileged policy override produces an accountable audit event.”

These are candidate schemas, not implemented policies or already proved security properties.

Example architecture

An interface-definition pipeline and policy repository export versioned semantic identifiers to a curated setup. FF Scribe runs in the engineering environment and has no path to production authorization or secrets. It stores the setup revision, proposed type, compiler result, deterministic reading family, and explicit reviewer decision. A separate verification pipeline may connect accepted propositions to policy-engine proofs, static analysis, generated tests, and negative integration tests. Deployment tooling admits artifacts only through the organization’s existing approval and provenance controls. Human security reviewers own threat-model alignment and exceptions.

Where verified readback fits

An engineer states the intended invariant in natural language. The proposal step may use only the setup vocabulary and either returns one Agda type or requests clarification. Agda checks formation, names, applications, and types. If the checked structure is supported by the partial readback translator, ff-readback renders a finite audited family while preserving binders and premise order; otherwise it fails visibly. The engineer compares successful readings with the intended policy, explicitly accepts one, or gives feedback. Confirmation records the specification’s meaning; it neither proves the proposition nor deploys a policy.

Potential benefits

This makes quantifier scope, deny/permit polarity, tenancy relations, and override prerequisites visible during review. The accepted artifact can provide a stable join point among threat-model claims, enforcement code, and regression tests. Setup-version changes can identify properties needing reassessment when roles, endpoints, or decision semantics evolve.

Limits/adoption considerations

Type correctness is distinct from factual truth about runtime requests, correctness of the security policy, real-world security, proof completion, and user-intent confirmation. Those need authenticated evidence, security governance, implementation and adversarial validation, an actual proof or analysis result, and explicit practitioner acceptance. Incomplete endpoint inventories, confused-deputy paths, caching, and distributed enforcement may invalidate a small abstraction. Setup ownership and exact mapping to shipped middleware are therefore central.
02Idempotent event-processing and retry assurance

System/use case

A distributed-systems specification assistant for event consumers and workflow orchestrators, focused on delivery duplication, idempotency keys, retry transitions, deduplication windows, commit ordering, compensation, and terminal failure handling.

Operational setting

Service owners and reliability engineers use it while designing event-driven workflows or reviewing changes to brokers, consumers, and state stores. A setup represents abstract messages, operation identifiers, processing states, side-effect records, acknowledgements, retries, and compensations. Production traces can be linked as evidence but are not sent into the formalization loop by default.

Decision/claim boundary

The proposition describes the abstract processing protocol, such as whether repeated delivery of the same operation identifier is required to preserve an externally visible result. It does not establish broker behavior, atomicity of a concrete database transaction, correctness of identifier generation, or exactly-once execution. Architecture and operational owners decide whether the protocol and evidence support deployment.

Candidate checked statements

Possible controlled-English propositions include:

  • “Repeated delivery of one committed operation does not create a second modeled side effect.”
  • “Acknowledgement occurs only after the associated outcome is durably recorded.”
  • “Every exhausted retry transitions either to compensation or to manual intervention.”
  • “A compensated operation cannot also be marked successfully completed.”

They illustrate potential formal statements rather than guarantees of a particular platform.

Example architecture

An architecture registry supplies stable event, workflow-state, and storage-operation names. FF Scribe produces accepted type/readback pairs in a design repository. A separate model checker or proof project analyzes state transitions, while property-based tests exercise adapters and fault-injection runs produce empirical evidence for failure paths. Telemetry links deployed workflow versions to observed outcomes. The proposition authoring service cannot publish messages, mutate state, or change orchestrator definitions. Service owners review consistency among the abstraction, implementation, and runbooks.

Where verified readback fits

The engineer describes a retry or consistency property. Translation yields a setup-scoped candidate proposition; ambiguous distinctions such as delivery versus processing or recorded versus externally visible outcome prompt clarification. Agda checks type correctness. The separate partial readback stage either exposes a supported premise-and-conclusion structure through the deterministic audited family or reports unsupported structure. The engineer accepts only if message identity, scope, and terminal states match the intended semantics; otherwise feedback begins a new bounded pass.

Potential benefits

The workflow can prevent an informal “exactly once” claim from concealing narrower assumptions. It gives application, platform, and SRE teams a common review object and can drive targeted failure-injection scenarios. Explicitly modeled fail states and compensations improve traceability between architectural intent and operational recovery procedures.

Limits/adoption considerations

A well-typed proposition is not a fact about a live broker, evidence that a consistency policy is appropriate, proof of safe behavior under every failure, a completed proof, or confirmation of meaning. Runtime instrumentation, architectural judgment, verification and chaos testing, proof artifacts, and human acceptance remain separate. Clocks, partitions, crash recovery, external side effects, and retention boundaries must be represented when material; omitting them can make a true model property irrelevant to production.
03Compiler intermediate-representation transformation review

System/use case

A compiler-engineering assistant for stating preservation obligations around intermediate-representation (IR) lowering, optimization passes, control-flow rewrites, and backend code generation. It focuses on the exact proposition a proof or translation-validation step is expected to discharge.

Operational setting

Compiler developers work against a setup containing source and target IR categories, evaluation or simulation relations, typing judgments, observations, and pass identifiers. The setup may reference existing mechanized semantics, but FF Scribe proposes only a type expression and never synthesizes or claims the proof. Continuous integration separately builds the compiler and proof artifacts.

Decision/claim boundary

The checked proposition can state semantic preservation, typing preservation, or refinement in the declared formal model. It does not show the theorem is inhabited, the semantics match deployed machines, the implementation corresponds to the modeled transformation, or generated code is defect-free. Compiler maintainers decide whether evidence is sufficient to merge or release.

Candidate checked statements

Illustrative propositions include:

  • “Every well-typed source program transformed by constant folding has an observationally equivalent target program.”
  • “If a source step is simulated, the corresponding target execution preserves the declared observation.”
  • “Every accepted lowering result is well typed in the target intermediate representation.”
  • “A failed transformation cannot be classified as a successful compilation result.”

These are possible goal shapes, not proof-complete theorems or claims of current adapter coverage.

Example architecture

The mechanized-semantics repository owns definitions and quoted names; a setup curator exposes a small audited vocabulary and readback profile. FF Scribe inserts a candidate only into a designated proposition hole, and Agda checks it in an isolated generated module. Accepted propositions enter code review beside proof files, translation validators, differential tests, and compiler revisions. CI verifies those independent artifacts. The readback service has no authority to merge changes or mark a theorem proved, and maintainers inspect the assumptions and implementation mapping.

Where verified readback fits

A compiler engineer describes the intended obligation. Setup-scoped translation produces one type, with clarification for ambiguous equivalence, termination, or observation notions. Agda verifies that the expression is meaningful in the formal environment. ff-readback then either renders a supported checked type through audited candidates or fails visibly; it never invents a prose summary for unsupported structure. The engineer confirms whether a successful reading captures the goal. Only a separately supplied proof term, successful model analysis, or other accepted evidence can establish the proposition.

Potential benefits

Verified readback can help a reviewer catch a preservation goal stated in the wrong direction, a missing well-typedness premise, or unintended quantification before proof work begins; it does not discover those defects on its own. It also provides reviewers unfamiliar with Agda syntax a stable, provenance-bearing view of the theorem interface and helps keep proof obligations connected to pass changes.

Limits/adoption considerations

Type correctness does not mean the proposition is true, the chosen refinement policy is correct, generated programs are safe, a proof is complete, or the wording matches the author. Definitions can also be vacuous or too weak. Reviewers must inspect semantic adequacy, assumptions, proof terms, implementation correspondence, trusted computing base, and explicit intent. Rich dependent or existential results may exceed current readback support and must fail visibly rather than be paraphrased incompletely.
04Embedded-control firmware release invariants

System/use case

A release-assurance tool for safety- or mission-relevant embedded firmware, used to express mode-transition, actuator-command, watchdog, initialization, and degraded-operation invariants across software revisions.

Operational setting

Firmware, controls, verification, and systems engineers use a setup that names controller modes, inputs, command states, timing abstractions, fault states, and permitted transitions. The artifact links to source revisions, interface-control documents, hardware-in-the-loop campaigns, and requirements coverage. FF Scribe remains outside the build signer, flashing tools, and target control path.

Decision/claim boundary

The proposition states a property of the abstract controller model, such as command inhibition in a fault state or initialization before enabling an output. It does not demonstrate sensor validity, deadline satisfaction on hardware, adequacy of the control law, binary equivalence, or system safety. Accountable engineering and release authorities own approval.

Candidate checked statements

Potential controlled-English propositions include:

  • “Every transition to actuator-enabled mode requires completed initialization.”
  • “An active critical fault inhibits every modeled actuator command.”
  • “Every watchdog-expiry transition enters a declared degraded or safe state.”
  • “A manual override remains represented in every autonomous control mode.”

They are illustrative statement forms, not certified requirements or verified firmware guarantees.

Example architecture

A requirements repository and model exporter generate a reviewed setup with stable identifiers. FF Scribe checks and reads back proposed requirements, recording explicit engineer acceptance. A verification pipeline separately links each accepted proposition to proofs, static-analysis results, unit and integration tests, hardware-in-the-loop evidence, compiler configuration, and signed binaries. Runtime monitors may observe related states but do not consume informal readbacks as executable policy. Existing independence, change-control, and release gates remain authoritative.

Where verified readback fits

An engineer supplies the natural-language invariant. The agent constructs a setup-scoped proposition, and Agda validates its type. If the separate partial translation supports that structure, ff-readback produces a finite audited family tied to the checked declaration; unsupported structure fails visibly. The engineer checks trigger, state, quantifier, and exception semantics and explicitly accepts or provides feedback. The accepted result is a reviewed specification artifact, not evidence that the firmware satisfies it.

Potential benefits

This creates precise anchors for regression coverage and change-impact analysis. It can expose confusion between fault detection and fault response, or between output request and physical actuation, before those ambiguities spread into tests. Deterministic readings help systems and verification specialists review formal requirements without relying on generated prose.

Limits/adoption considerations

Type correctness, factual behavior of the binary and hardware, policy adequacy, real-world safety, proof completion, and user-intent confirmation are independent. Traceable build evidence, governed requirements, target-level validation, proofs or analyses, and explicit practitioner review are all necessary. Timing, concurrency, interrupt behavior, numeric error, toolchain assumptions, and hardware failure modes can make a transition-only model insufficient. Adoption requires configuration control and a defensible mapping from model states to the delivered system.
MLTTDB4 patterns
These illustrative applications develop the Code domain brief in ~/nn-ff-web/content/domains/code.md: explicit specifications, property checking, regression constraints, and machine-checkable evidence connected to implementation. They describe candidate production architectures, not certified products. The formal models, translations from engineering standards, and acceptance criteria require review by the responsible software, security, safety, and assurance specialists.
01Versioned API and protocol contract catalog

Operational context

A platform organization operates public REST endpoints, asynchronous event schemas, and service-to-service protocols across independently released teams. OpenAPI or schema-registry checks catch syntactic incompatibility, but architectural constraints also concern request-state transitions, idempotency keys, error refinement, authorization scopes, and which older consumers a release must preserve. Reviewers need to distinguish a changed declaration from a change that actually invalidates an approved compatibility argument.

Why MLTTDB fits

The stable part of this problem is a typed vocabulary of protocol versions, operations, transition preconditions, and compatibility witnesses; the changing part is the catalog of approved contract instances. MLTTDB can keep those instances as ordered proof-language terms and rerun their proofs when the source model evolves. UUIDs provide durable row identities for review and cross-system references, while the proof assistant—not the store—checks that a witness inhabits the declared compatibility type.

Example architecture

OpenAPI / AsyncAPI / IDL repositories
              |
      external contract compiler
              v
candidate typed rows + provenance manifest
              |
      reviewed admin/API import
              v
   SQLite MLTTDB term store
              |
   CI data-mode validation
              v
   Agda / Lean / Rocq checker
              |
     signed CI result bundle
              v
  release policy and human approval

The external compiler normalizes source contracts and proposes proof-language rows; it also records repository commit, generator version, and source pointer in an ordinary provenance system. A contract-model repository owns the row types and compatibility predicates. The term store owns approved ordered terms and identifiers. CI selects the matching checker path and publishes generated source, diagnostics, and commit linkage. A separate release controller consumes the result under organization policy.

Representative typed artifacts

Illustrative row types include EndpointVersion, Transition, ConsumerAssumption, and CompatibilityCase old new. Tables might be declared as supportedVersions :T: EndpointVersion and requiredCases :T: CompatibilityCase. A reconciled ContractCatalogManifest aggregate term enumerates the versions, assumptions, breaking changes, and case UUIDs whose whole-snapshot coverage is checked. A row can encode that POST /payments in version 3 refines the documented outcomes of version 2 under a named assumption set. In Agda, a case may use finite lookup to refer to an earlier version by UUID; in Lean or Rocq, the preprocessing workflow must instead use ordinary generated identifiers or self-contained rows.

Checks and evidence

For the compiler-reconciled manifest, the checker can establish that every enumerated breaking change has an explicit migration disposition, every enumerated consumer assumption is covered by a compatibility case, transition refinements preserve modeled invariants, and references resolve within the declared finite domain. Negative fixtures should demonstrate rejection of missing cases and invalid witnesses. Evidence should retain source commit, exact table snapshot or export, manifest digest and reconciliation, checker version, generated file where applicable, stdout/stderr, and policy decision. MLTTDB does not prove that deployed handlers implement the modeled contract; conformance and integration tests provide that separate evidence.

Potential benefits

Teams gain a reviewable compatibility argument rather than a collection of schema diffs. Rechecking localizes drift when shared assumptions change, and stable UUIDs let issue trackers and waivers point to the same catalog entries. Machine checking can reduce inconsistent interpretation across service teams while leaving ownership and release authority explicit.

Deployment boundary

Run this as CI or release-time assurance on reviewed snapshots, not in the request path. Protect administrative writes through external IAM and change control. Raw specifications are not ingested by MLTTDB without a reviewed adapter, and a passing proof is only evidence about the formalized model. Qualified API owners and formal-methods reviewers must approve the mapping and decide whether the evidence is sufficient.
02Authorization policy change assurance

Operational context

A multi-tenant SaaS platform manages role, relationship, and attribute-based access rules across control-plane APIs. Proposed changes arrive as policy-as-code pull requests, entitlement catalog updates, and temporary exception requests. Security engineers need to know whether a change introduces cross-tenant access, violates separation of duties, leaves a privileged action without a review path, or broadens an emergency role beyond its approved resource set.

Why MLTTDB fits

Authorization assurance has a compact typed core: subjects, tenant boundaries, resources, actions, grants, denials, delegations, and invariants. The approved scenarios and exception terms change more frequently than the proof framework. MLTTDB can separate the proof-owned authorization model from an editable term catalog, then ask the proof assistant to validate that each stored grant or change witness meets the declared constraints. It is an assurance layer; it does not evaluate live requests.

Example architecture

IAM catalog + policy repository + ticketing
                   |
     external reconciler and candidate builder
                   v
          isolated review workspace
                   |
   MLTTDB records with ticket/source metadata
                   |
   store-owned verify endpoint or local CI
                   v
          proof-assistant checker
                   |
    security review packet and approval
                   v
      external policy deployment pipeline

The reconciler joins identities, policy declarations, and exception tickets, then emits candidates; source reconciliation remains its responsibility. Reviewers edit or accept proof-language records in a restricted workspace. Store-owned verification may launch the configured Agda, Lean, or Rocq validation backend, but returned success is the subprocess result. The deployment pipeline independently verifies approvals, commits, and environment targeting.

Representative typed artifacts

Useful types include PrincipalClass, ResourceScope, Action, Grant, Constraint, and ApprovedException. Tables such as baselineGrants :T: Grant and changeCases :T: AuthorizationChange can express tenant-preservation, non-escalation, and two-person administration obligations. A change artifact may carry a proposed grant together with a proof that its resource scope is a subset of the role’s approved scope. Another can model a time-bounded exception at the type level while leaving wall-clock evaluation to the surrounding workflow.

Checks and evidence

Validation can reject a grant whose tenant indices differ, a delegation that escapes its modeled parent scope, a privileged action with no modeled approval class, or incompatible roles assigned in the same reviewed scenario. It can require each exception to name a control owner and a formally valid compensating constraint. Evidence combines checker output with the policy commit, candidate-generation manifest, reviewer identities, and external reconciliation report. Live directory membership, ticket validity, current time, and deployed policy state are external facts; the formal check only covers their encoded snapshot.

Potential benefits

Security review becomes focused on explicit counterexamples and assumptions instead of diffuse policy text. Typed changes can expose unintended privilege expansion before deployment, and repeatable validation provides consistent regression evidence when common roles or invariants change. The model also gives reviewers a precise vocabulary for distinguishing a policy defect from stale or incorrectly reconciled source data.

Deployment boundary

Keep MLTTDB outside the production authorization decision point and fail no live request solely on its availability. Use a protected pre-production workspace and an external approval/deployment service. Do not claim completeness unless the reconciler’s coverage is independently measured. Security owners must review the formal policy abstraction, and production rollout should retain native policy-engine tests, canary controls, rollback, and monitoring.
03Safety-critical embedded configuration baseline

Operational context

An embedded-controls program ships product variants with calibrated thresholds, sensor channel assignments, actuator limits, watchdog timings, and feature interlocks. Values are maintained by systems, controls, and manufacturing engineers and ultimately transformed into generated headers or calibration images. A locally plausible value can still violate a cross-parameter invariant, select hardware absent from a variant, or invalidate an established timing budget.

Why MLTTDB fits

Configuration baselines are finite, highly structured, and amenable to dependent typing: a channel assignment can be indexed by hardware variant, a threshold by engineering unit and admissible range, and an interlock by the states in which it must hold. MLTTDB can store reviewed source-language configuration terms independently of the proof model and validate them as a release snapshot. This supplements, but cannot replace, system safety analysis and target testing.

Example architecture

requirements + hardware definition + calibration tool
                      |
   controlled external transformation and review
                      v
      variant-specific MLTTDB database
                      |
     locked release candidate snapshot
                      |
        Agda data-mode validation
                      v
   checked ordinary definitions / diagnostics
                      |
   qualified generator and build pipeline
                      v
   HIL tests, safety review, signed release

Requirements management and hardware tools remain authoritative for their respective facts. A controlled adapter proposes typed terms and a reconciliation report. The proof source owns units, ranges, compatibility relations, and variant indexes. The term store maintains the ordered candidate baseline. Agda is attractive when later rows must refer to earlier catalog entries through literal UUID finite lookup; if Lean or Rocq is selected, rows must use the supported generated-definition model without that lookup.

Representative typed artifacts

Types might include Channel variant sensorKind, Bounded unit low high, WatchdogBudget taskSet, and Interlock machineState actuator. Tables such as sensors :T: SensorBinding VariantA and parameters :T: CalibratedParameter VariantA hold concrete selections. A motor-current limit can be represented as a value carrying evidence that it lies within the variant’s electrical and thermal envelope. A watchdog row can carry a proof that the declared period dominates the modeled worst-case execution allowance.

Checks and evidence

The proof assistant can check range membership, uniqueness of modeled channel assignments, compatibility between sensor type and input circuit, monotonic alarm thresholds, and completeness against a finite list represented in the formal model. The release packet should include the term snapshot, source requirements references, transformation report, proof source revision, checker/toolchain fingerprint, and generated configuration digest. It must also record simulation, hardware-in-the-loop, fault-injection, and traceability results because MLTTDB does not establish plant behavior, compiler correctness, hardware conformance, or coverage of the safety requirements.

Potential benefits

The approach can make configuration assumptions executable, catch invalid variant combinations before expensive target testing, and provide reproducible evidence that a released baseline satisfied a specific formal model. Separating row data from the proof source lets calibration changes be reviewed without weakening the invariants, while UUIDs support stable linkage to engineering change records.

Deployment boundary

Use MLTTDB only in a qualified release workflow with read-only candidate snapshots during validation. It is not a certified configuration-management system, code generator, or safety case. Existing configuration control, independence requirements, tool qualification arguments, target verification, and responsible engineer sign-off remain mandatory. Any production use requires a domain-specific hazard assessment and qualified review of both the formalization and data transformation.
04Database migration compatibility dossier

Operational context

A data platform performs rolling migrations across application versions: column splits, enum evolution, backfills, index changes, and event/outbox transitions. During a zero-downtime window, old and new binaries may read and write the same logical data. Migration tooling can order DDL, but teams still need evidence that mixed-version reads are defined, transformations preserve modeled invariants, retries are idempotent, and rollback remains possible at each declared stage.

Why MLTTDB fits

A migration plan is naturally a finite collection of schema states, transformations, compatibility obligations, and stage witnesses. MLTTDB can hold the current plan as typed proof-language records while a proof repository defines what makes each stage safe. Revalidation after a schema or transformation change exposes which witnesses no longer type-check. Explicit StageIndex and predecessor/successor relations in a reconciled plan manifest carry sequence semantics; the store preserves deterministic presentation and generated-definition emission order, not a proof-visible ordinal.

Example architecture

migration DSL + schema history + application contracts
                       |
      external plan extractor and test generator
                       v
    MLTTDB migration dossier (review branch)
                       |
        project-owned CI validation
                       v
         Lean / Rocq / Agda checker
                       |
   proof result + generated source + DB tests
                       v
   change advisory and deployment orchestrator

The extractor builds candidate terms from migration and application repositories; it does not gain authority over either source. The formal model defines abstract rows, transformations, mixed-version operations, and required obligations. MLTTDB stores reviewed plan instances. CI validates the terms and also runs database-native migration, rollback, and property tests. The deployment orchestrator controls locks, sequencing, observation windows, and abort criteria.

Representative typed artifacts

Candidate types include SchemaState, MigrationStep from to, BackwardRead old new, ForwardWrite old new, and RollbackWitness stage. Tables might be stages :T: MigrationStage and obligations :T: StageObligation. A column-split step can carry total abstract encode/decode functions and proofs for the modeled round trip. A backfill stage can state that old readers remain defined while dual-write is active. For Agda, finite UUID lookup can link an obligation to an earlier stored stage; Lean and Rocq workflows should encode those relationships through ordinary preprocessed definitions.

Checks and evidence

Checks can cover stage ordering, modeled transform totality, round-trip or refinement properties, presence of compatibility witnesses for supported application-version pairs, and rollback obligations before destructive steps. The dossier should bind results to migration commits, application contract versions, database engine/version, generated source, and executable integration-test reports. Formal proofs do not guarantee SQL semantics, production data quality, lock behavior, query-plan stability, or that the extracted model matches every caller; those are separate validation targets.

Potential benefits

Reviewers receive a coherent compatibility case rather than independent DDL, runbook, and test artifacts. A change to a shared schema state triggers focused rechecking of dependent obligations. Stable row identities improve linkage among migration tickets, test results, and exceptions, while explicit stages make rollback assumptions visible before deployment.

Deployment boundary

This is pre-deployment and change-window assurance, never the migration executor. Run validation against immutable release candidates and require database-native rehearsals on representative copies. External IAM, approvals, backup verification, observability, and rollback control remain authoritative. Database owners and application teams must review the abstraction and evidence; MLTTDB should not authorize or automatically initiate a production migration.
State Machine Studio3 demos
SMDistributed transaction coordination

This example represents coordination of one logical transaction across services or resource managers that cannot rely on a single local database commit. It models the practical guarantees around reservations, durable prepare decisions, commit propagation, compensation, retries, and ambiguous outcomes. The workflow assumes messages may be delayed or repeated and that a participant may fail after completing work but before acknowledging it.

The transaction begins by recording the externally required atomic outcome, the participating systems, and the consistency assumptions. Resource reservation requests bounded holds and records participant versions and expiry times. A conflict routes to compensation, because any work already performed or reserved must be released in dependency order. Complete reservations move to the prepared state only after durable acknowledgements are verified and the coordinator’s decision context has been persisted.

Once a commit decision is durable, it is propagated with retry-safe identifiers. Confirmed acknowledgements lead to a completed transaction and an evidence record of the externally visible result. A timeout during prepare triggers compensation, but uncertainty after commit cannot safely be treated as failure: a participant may already have committed. That path enters outcome review, quarantines the ambiguous case, and resolves the authoritative result from durable coordinator and participant evidence. Review may confirm completion or authorize a safe retry. Failed compensation also enters review rather than silently beginning a second transaction.

These controls matter because an unqualified retry can duplicate a charge, shipment, booking, or ledger movement, while an unqualified rollback can contradict an already committed participant. Reservation versions and expiries protect against stale holds; durable decisions prevent the coordinator from changing its answer after recovery; idempotency identifiers make redelivery safe; and outcome review creates an explicit operational state for “unknown” instead of forcing it into success or failure. The result is a reproducible protocol trace that engineering and operations can use to reconcile customer-visible outcomes.

Layer 1 — Transaction guarantee lifecycle

This layer describes the guarantee from request through reservation, preparation, commit, completion, compensation, or outcome review. It is the architecture and incident-management view of whether the logical transaction is pending, decided, visible, reversed, or uncertain. It excludes participant API calls, retry counters, and persistence commands so the global consistency story remains understandable.

Layer 2 — Participant coordination

This layer shows how the coordinator manages resource holds, prepare acknowledgements, a durable decision, commit delivery, dependency-ordered compensation, and authoritative outcome review. It includes the protocol boundaries and recovery routes between participants. It intentionally excludes the business implementation inside each participant and the low-level mechanics of individual reads, writes, and messages.

Layer 3 — Protocol checks and actions

This layer contains the concrete protocol work: collect versions and expiries, validate durable prepare records, persist decision context, publish commit with an idempotency key, reconcile acknowledgements, issue compensations, and inspect durable evidence. It provides enough scope for instrumentation and automated checks while leaving the overall customer outcome and cross-service guarantee to the higher layers.
Open interactive model
SMRolling deployment assurance

This example represents a production release managed as a sequence of evidence-backed decisions rather than a single “deploy” operation. It connects the approved release intent and artifact identity to pre-deployment requirements, canary behavior, progressive fleet expansion, final verification, and rollback. The goal is to preserve stated service and compatibility guarantees while exposing a change gradually enough to contain regressions.

The workflow begins when a release is planned. The team records the behavior being changed, the guarantees that must remain true, and the exact artifacts and configuration covered by the deployment specification. Requirements validation checks interface and configuration preconditions and runs the admission suite—tests, property checks, or other regression evidence required for that service. A failed admission returns the release for rework rather than allowing operational confidence to substitute for a missing prerequisite.

An admitted release reaches a canary population. Its signals are compared with an explicit acceptance envelope, not merely watched for obvious crashes. Healthy observation permits fleet expansion in bounded batches, with health and compatibility reevaluated at every boundary. A canary regression or later batch regression freezes expansion and activates rollback. Rollback restores the last compatible artifact and configuration, verifies that restoration, and returns the work to release planning. Even after fleet-wide verification, a post-release regression can reopen rollback; the verified state is evidence, not an irreversible declaration of success.

These controls matter because distributed production systems can pass build-time tests yet fail under real traffic, data shape, dependency behavior, or gradual capacity changes. Binding artifacts to requirements prevents deploying something different from what was reviewed. Canary and batch gates limit blast radius, while an explicit rollback path avoids improvising under incident pressure. Retaining the release-to-evidence trace lets engineering, SRE, and change reviewers reproduce why each rollout boundary was crossed.

Layer 1 — Deployment assurance lifecycle

This layer is the release owner’s end-to-end view: planned, admitted, canaried, expanding, verified, or rolling back. It shows the major assurance gates and every route that returns the change to planning. It deliberately excludes individual cluster operations, metric queries, and test invocations so stakeholders can understand release posture and risk containment across the whole campaign.

Layer 2 — Release orchestration

This is the working view for release engineering and SRE. It covers artifact binding, prerequisite admission, canary scope, acceptance envelopes, rollout batches, health evaluation, rollback coordination, and final evidence capture. It includes when orchestration must stop, advance, or restore a checkpoint, but excludes tool-specific commands and the implementation of each probe or deployment action.

Layer 3 — Deployment checks and actions

This layer contains the executable control steps: validate configuration and interfaces, run regression checks, place canary instances, query service signals, compare thresholds, advance a batch, freeze deployment, restore artifacts, and verify service objectives. It is detailed enough to automate and audit a gate. It intentionally leaves release-wide approval and risk posture to the higher layers.
Open interactive model
SMVersioned API and data migration

This example represents a compatibility-led change to an API contract and its stored data. Instead of treating schema conversion, client adoption, and traffic cutover as separate projects, it keeps them in one controlled lifecycle: proposed invariants, compatibility review, shadow conversion, dual operation, cutover, legacy retirement, and remediation. This is suitable for changes where old and new readers or writers coexist for a meaningful period.

The workflow begins by stating interface and data invariants and inventorying every consumer, writer, and stored version affected. Compatibility review compares old and new assumptions and searches for representative counterexamples, such as an old client omitting a newly required field or a conversion losing domain meaning. A rejected review returns to design. An accepted design moves to shadow migration, where a replayable cohort is converted without becoming authoritative and source and target results are compared semantically rather than only byte-for-byte.

Converged shadow results permit dual operation: versioned reads and writes run in parallel while adoption and data convergence are measured. Drift opens remediation. Once consumers have adopted the new version, cutover moves traffic across a controlled boundary and verifies checkpoints before fallback routes are retired. Divergence, dual-run drift, or a failed cutover is classified and repaired; the repair may be replayed through shadow migration or the known fallback restored in dual operation. Legacy mutation paths are disabled only after cutover verification, and the compatibility evidence is retained with the retired version.

These controls matter because a superficially successful backfill can still change business meaning, while a correct new API can fail when an overlooked consumer continues using an older contract. Replayable cohorts make fixes testable, dual operation exposes live incompatibilities without an abrupt one-way switch, and checkpoints make recovery bounded. The retained proof and regression constraints help prevent the next version from reintroducing a previously solved incompatibility.

Layer 1 — Compatibility migration lifecycle

This layer is the program-level view from proposal to verified legacy retirement. It shows readiness, coexistence, cutover, and every remediation loop, allowing service owners to answer whether the migration is reversible and what remains dependent on the old version. It deliberately excludes endpoint fields, conversion records, and individual consumer calls so the overall compatibility posture stays visible.

Layer 2 — Version and data operations

This is the working view for platform, application, and data teams. It covers contract review, consumer inventory, shadow cohorts, semantic comparison, dual reads and writes, adoption tracking, traffic cutover, fallback routes, repair replay, and legacy shutdown. It includes the operational boundaries shared across teams but excludes the exact assertions, transforms, feature-flag operations, and data commands.

Layer 3 — Migration checks and actions

This layer describes executable checks and changes: validate contract assumptions, generate counterexamples, convert and replay a cohort, compare source and target semantics, measure convergence, verify checkpoints, shift traffic, repair mappings, and disable legacy mutations. It is scoped for automation and audit. It intentionally leaves migration-wide authorization and compatibility status to the higher layers.
Open interactive model
Explore patternsReview product applications

Cabinet index

Explore Formal Foundry

Book a meeting Explore libraries

Trusted systems. Mathematical proofs.

Search the archive

Find a page

Type to search the published content.