Cryptographic Proofs and Governable Rules in Defense AI

"Systems will go through rigorous hardware and software verification and validation (V&V) and realistic system developmental and operational test and evaluation (T&E) ... to minimize the probability and consequences of failures."

The requirement comes from DoD Directive 3000.09, which sets the baseline for how the United States military treats autonomous and semi-autonomous weapon systems. It defines auditability in concrete terms: systems must be testable, verifiable, and predictable under realistic conditions.

For defense programs that increasingly rely on machine learning, this requirement splits into two distinct problems. Designers must show that model computations ran as claimed, and they must show that the surrounding decision logic is understandable and governable by the relevant authorities.

Two different technology families address these needs. Zero-knowledge machine learning, or zkML, aims to provide cryptographic proofs of correct model execution. Decision tables and rules engines, often standardized as Decision Model and Notation, or DMN, supply deterministic, human-readable decision logic.

In high-consequence settings, the interaction between these approaches matters more than the novelty of either one.

Zero-Knowledge Machine Learning as Verifiable Computation

Zero-knowledge proofs are cryptographic protocols in which a prover convinces a verifier that a computation was carried out correctly without revealing sensitive intermediate data. Applied to machine learning, zkML systems compile neural network inference into arithmetic circuits and generate succinct proofs that a specified output followed from a given input and model.

"We present the first framework, ZKML, to produce ZK-SNARKs for realistic ML models, including state-of-the-art vision models, a distilled GPT-2, and the ML model powering Twitter's recommendations."

That description from a 2024 paper in the ACM Digital Library captures the current state of the field. Earlier work could only handle small, artificial models, which limited practical deployment. The newer ZKML framework targets real-world architectures, including large language models in distilled form and complex recommendation pipelines.

"recent work has proposed using zero-knowledge proofs (specifically a form called ZK-SNARKs) for certifying computation with private models but has only been applied to unrealistically small models."

The same research line emphasizes that extending zero-knowledge techniques to realistic models required new compiler and circuit design work. According to the EuroSys ZKML paper, implementation choices in circuit construction can shift performance by up to a factor of 24, which illustrates how tightly the cryptographic layer is bound to engineering details of the model representation.

In zkML systems, the dominant cost is usually proving rather than verification. The ZKML authors report that verification can be orders of magnitude cheaper than proof generation, which is consistent with broader explanations of SNARKs that stress short proofs and fast verification.

A 2023 explainer from a16z crypto describes succinct proofs as small and quick to verify, while acknowledging heavy prover workloads.

"Zero-Knowledge Proofs (ZKPs) offer a cryptographic solution that enables provers to demonstrate, through verified computations, adherence to set requirements without revealing sensitive model details or data."

An arXiv survey on zero-knowledge proofs for machine learning describes proof-of-inference as a way to show adherence to specification without exposing private model parameters or inputs. In multi-party or adversarial environments, this property is valuable: a central authority or external auditor can verify that an output was produced by running an approved model on a particular input, even if they never see the raw data or the proprietary weights.

However, this assurance comes with complexity. zkML stacks involve model-to-circuit compilation, constraint system design, proof generation infrastructure, and often a trusted setup or equivalent ceremony, depending on the proof system. Performance depends not only on the model but also on the selected curve, proof scheme, and optimization strategy.

From an audit perspective, zkML gives strong guarantees about computational integrity and provenance. It can answer the question of whether a claimed inference actually ran on specified inputs under an approved model version.

It does not, by itself, explain how policy decisions are made on top of those inferences or how those decisions change over time.

Decision Tables and Rules Engines as Governable Logic

Decision tables and rules engines address a different layer of the problem: how organizations represent and govern the logic that turns inputs into decisions. The Object Management Group describes DMN as a standard for specifying repeatable business decisions using models and notation that are easily readable by business people, analysts, and developers.

"DMN is easily readable by the different types of people involved in decision management."

DMN models typically express decision logic in tabular form, where conditions and actions are laid out explicitly. This design aims to remove ambiguity and to ensure that the same model can serve as both documentation and executable logic. The tables can be evaluated by compliant engines, which helps keep behavior consistent across implementations.

A Beige Media profile of the DTRules decision table engine describes one concrete deployment path. According to that account, Texas agencies used the engine to run more than 3,000 decision tables for Medicaid, SNAP, and related programs, with the rules maintained as spreadsheets to preserve traceability and transparency.

The same report notes that evaluations completed in seconds, even across thousands of tables, which illustrates how lightweight deterministic rule evaluation can be at scale.

"Texas used the engine to run more than 3,000 decision tables for Medicaid, SNAP and related programs."

IBM's documentation for its Operational Decision Manager explains that rules engines are used to separate decision logic from application code so that organizations can change policies without rewriting and redeploying core software. An IBM Redbooks paper on decision management emphasizes this separation as a way to manage change and maintain consistency in high-volume transactional systems.

The "rules as code" movement in public administration extends this idea further. A report from the Beeck Center at Georgetown University examines how translating benefit eligibility rules into structured, machine-executable forms can reduce ambiguity and improve service delivery. That work, which cites decision engines as implementation options, demonstrates that governments already treat encoded rules as a governance tool rather than a research experiment.

For defense and national security contexts, the key properties of decision tables are determinism, explainability, and shared readability. Program managers, operators, lawyers, and engineers can all inspect the same table, test it against scenarios, and approve or revise it through established governance processes.

There is no cryptographic machinery in the execution path, which keeps failure modes closer to conventional software bugs or policy mis-specification.

Two Notions of Auditability in Defense AI

When defense guidance calls for auditability, it is not referring to a single capability. DoD Directive 3000.09 stresses rigorous verification and validation and testing in realistic conditions to minimize the probability and consequences of failures.

"Explainable systems can be debugged and monitored more easily, and they lend themselves to more thorough documentation, audit, and governance."

– NIST AI Risk Management Framework, NIST AI 100-1

zkML aligns with the integrity side of this picture. It answers the question of whether a particular inference was executed as specified, which is essential when the infrastructure or data path is untrusted. Decision tables align with the governance side. They make it practical for domain experts to understand and modify the policies that turn model outputs into concrete actions.

This difference has operational consequences. zkML depends on advanced cryptography, typically zk-SNARK or related systems, that require careful parameter selection and sometimes trusted setup procedures. Many widely used SNARK constructions rely on elliptic-curve discrete logarithm assumptions, which a future large-scale quantum computer running Shor's algorithm could break.

A 2024 report from NIST highlights discrete log over elliptic curves as a class of problems vulnerable to such attacks.

By contrast, a decision table is not a cryptographic primitive. It is a set of deterministic condition-action rules executed by ordinary software. Quantum advances could affect the digital signature schemes used to authenticate logs or software updates, but they do not threaten the underlying logic in the way they threaten elliptic-curve-based proofs.

At the same time, it is important to note that not all zero-knowledge proof systems share the same posture: zk-STARK constructions, for example, rely on hash-based assumptions and are often presented as more post-quantum friendly, as discussed in recent work on STARKs available on arXiv.

Computational cost also differs. The EuroSys ZKML paper and related work emphasize that proving dominates runtime in zkML, and that circuit design choices can change performance by large factors. Even with optimizations that reduce proof size and verification cost, the end-to-end zkML pipeline introduces latency and infrastructure requirements that are hard to ignore in real-time control loops.

Decision tables, in comparison, evaluate like ordinary functions over structured data. The Texas DTRules deployment shows that thousands of tables can be processed in seconds in production environments. That behaviour does not depend on specialized hardware or cryptographic acceleration, which makes it easier to reason about worst-case performance envelopes in safety-critical systems.

The audit surface is simpler as well. To review a decision table, an auditor can inspect the conditions and outputs directly, run test cases, and compare the encoded logic to statutory or policy requirements.

To review a zkML system, the auditor must consider the model, the compilation process, the constraint system, and the cryptographic parameters, in addition to whatever policy logic sits on top.

Hybrid Stacks for Mission-Critical Autonomy

These contrasts do not imply that zkML and decision tables compete for the same role. They address different questions and can be combined in architectures that better match the layered assurance described in defense and AI governance documents.

A common pattern is to constrain machine learning to perception, ranking, or recommendation, then route its outputs through a layer of deterministic decision logic. In that structure, the neural network might classify sensor inputs or estimate risk scores, while decision tables specify thresholds, escalation paths, overrides, and final actions.

From the perspective of DoD Directive 3000.09, this separation helps V&V teams focus their most formal analysis effort on the policy layer that directly triggers or suppresses autonomous behaviors. Rules can be tested against scenarios that mirror operational conditions, and they can be adjusted as doctrine or legal interpretations change, without retraining the underlying model.

zkML fits into this picture when there is a need to prove to an external party that a specific model was used as approved and that its inference followed the documented path. For example, when multiple organizations or nations share a common system, or when regulators or program offices require cryptographic evidence that contractors are running certified models, zero-knowledge proofs offer an assurance channel that rules engines alone cannot supply.

An arXiv survey on ZKPs for ML notes that proofs can demonstrate adherence to requirements without revealing sensitive model details or operational data. This property is attractive when model weights are proprietary or when inputs contain classified or personal information that cannot be shared even with oversight bodies.

In those cases, zkML can upgrade trust in the model layer while decision tables continue to anchor policy governance.

The combination also aligns with NIST's emphasis on explainability. The AI Risk Management Framework ties explainability to better debugging, monitoring, and governance. A decision table that encodes explicit conditions and choices is inherently easier to explain than a large neural network.

Using zkML to attest to model execution without obscuring the rule layer lets organizations retain that explainability while still satisfying cryptographic provenance requirements where they apply.

What This Implies for System Design

In practice, this suggests a default architecture for high-gravity systems. Place deterministic, DMN-style decisions at the outer layer where actions are selected, and restrict machine learning to well-scoped roles behind that layer. Add zkML proofs selectively, where external verifiers need strong evidence that particular models and inputs were used, or where privacy constraints limit direct inspection.

Such a design does not remove the need for rigorous testing of the models themselves, but it concentrates formal assurance effort where it has the most immediate operational impact: the intelligible rules that govern when and how an autonomous system can act.

As defense and national security programs adopt more AI components, the distinction between cryptographic verification of computation and governance of decision logic will likely become more important. zkML and similar techniques expand what can be proven about opaque models in untrusted environments.

Decision tables and rules engines, by contrast, continue to offer a mature, institutionally familiar way to specify, review, and change the policies that ultimately determine system behavior.

For many mission-critical, real-time applications, especially where decision authority must remain transparent and contestable, that governance layer will remain the primary anchor for auditability.

Cryptographic proofs can add another line of defense, but they are most effective when integrated into architectures that already make the core decision process legible to the people responsible for its consequences.

Sources

• Chen, B.-J. et al. "ZKML: An Optimizing System for ML Inference in Zero-Knowledge Proofs." EuroSys '24 (ACM), 2024.
• Chen, B.-J. et al. "ZKML: An Optimizing System for ML Inference in Zero-Knowledge Proofs." EuroSys, 2024.
• Scaramuzza, F. et al. "Engineering Trustworthy Machine-Learning Operations with Zero-Knowledge Proofs." arXiv, 2025.
• Object Management Group. "Decision Model and Notation (DMN) — About the Specification (Version 1.6 beta)." OMG, 2024.
• Beige Media. "Rules You Can Audit: A Decision-Table Engine for Transparent Automation." Beige Media, 2025.
• Johnson, M. "IBM Operational Decision Manager: Enabling the Rule Engine to Augment the Decision Data." IBM Redbooks (Redpaper), 2016.
• Kennan, A., and Soka, S. "Benefit Eligibility Rules as Code: Reducing the Gap Between Policy and Service Delivery for the Safety Net." Beeck Center for Social Impact + Innovation, 2022.
• Thaler, J. "17 misconceptions about SNARKs (and why they hold us back)." a16z crypto, 2023.
• U.S. Department of Defense. "DoD Directive 3000.09: Autonomy in Weapon Systems." Department of Defense, 2023.
• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1)." NIST, 2023.
• National Institute of Standards and Technology. "Transition to Post-Quantum Cryptography Standards (NIST IR 8547 ipd): Initial Public Draft." NIST, 2024.
• Nainwal, A. et al. "A Comparative Analysis of zk-SNARKs and zk-STARKs: Theory and Practice." arXiv, 2025.