Every decision system, when you strip away the abstraction layers, reduces to a small set of primitives: compare a value against a threshold, rank a set of candidates, branch based on a condition. That is the entire vocabulary of decisions. And every one of those primitives is a greater-than (GT) comparison.
This is not a theoretical observation. It is a production reality. At H33, we have spent years building encrypted computation systems, and the single most important insight from that work is this: if you can do GT on encrypted data, you can build virtually any decision system that matters. Equality comparisons, while useful for a narrow class of operations, are not decision primitives. They are database primitives. The distinction matters enormously when you are engineering encrypted systems that need to make real decisions in real time.
The Anatomy of a Decision
Before we walk through specific applications, let us establish what a decision actually is in computational terms. A decision is a function that takes an input and produces a control signal -- a binary output that routes execution down one path or another. Sometimes the control signal selects between two branches. Sometimes it selects among many. But at the atomic level, every decision decomposes into one or more binary comparisons.
Consider what happens when a bank evaluates a transaction for fraud. The system checks whether the transaction amount exceeds a threshold. It checks whether the velocity of transactions in a time window exceeds another threshold. It checks whether a risk score exceeds a confidence boundary. Every single one of these checks is a GT comparison: is value A greater than value B?
Now consider what a decision system does NOT need to do. It does not need to check whether a transaction amount is exactly $147.32. It does not need to verify that a customer ID is precisely equal to a stored value. Those are lookup and matching operations -- they belong to the data layer, not the decision layer. When people conflate decision logic with data management, they end up optimizing the wrong primitive.
GT as the Universal Decision Primitive
In TFHE (Fully Homomorphic Encryption over the Torus), a GT comparison on n-bit encrypted values costs 2n-1 programmable bootstrapping (PBS) operations. For 8-bit values, that is 15 PBS operations. This is the fundamental unit of cost for encrypted decisions. Everything else builds from it.
The reason GT is so powerful is that it generates the full family of comparison operators through trivial transformations:
- Greater than (GT): Direct computation. Is A greater than B?
- Less than (LT): GT(B, A). Swap the operands.
- Greater than or equal (GTE): NOT(GT(B, A)). Negate the swapped comparison.
- Less than or equal (LTE): NOT(GT(A, B)). Negate the direct comparison.
Every inequality operator is a single GT computation plus at most one NOT gate, which is essentially free in TFHE (a negation of the ciphertext with no bootstrapping required). This means that when we say "GT is production-ready at 8-bit," we are really saying "all comparison operators are production-ready at 8-bit." That single fact covers the vast majority of decision logic in the real world.
Application 1: Fraud Detection (Threshold Decisions)
Fraud detection is the canonical threshold decision system. Every fraud rule, at its core, is a threshold comparison. Transaction amount exceeds $10,000? Flag it. Velocity exceeds 5 transactions per minute? Flag it. Risk score exceeds 0.85? Flag it. Geographic distance from last transaction exceeds 500 miles in under an hour? Flag it.
In an encrypted fraud detection pipeline, each of these checks is a single GT comparison on encrypted values. The transaction amount is encrypted. The threshold is encrypted (or can be a known plaintext constant encoded into the circuit). The GT circuit produces an encrypted Boolean: 1 if the threshold is exceeded, 0 otherwise. The downstream logic -- which can be as simple as an OR across all flag bits or as complex as a weighted voting scheme -- operates entirely on encrypted Booleans.
What fraud detection does NOT require is equality. You never need to check "is this transaction exactly $10,000?" You need to know whether it exceeds the threshold. The boundary condition (equal to the threshold) is handled by GTE, which is just NOT(GT(B, A)) -- a single GT plus a free negation.
The entire fraud pipeline -- ingest encrypted transaction, evaluate N threshold rules, combine flags, produce encrypted disposition -- runs without a single EQ operation. This is not a simplification. This is literally how production fraud systems work, even in plaintext. The encrypted version simply preserves the same logic while keeping all values hidden.
Application 2: Credit Scoring (Thresholds + Bands via GT)
Credit scoring introduces a slightly more complex pattern: band classification. A credit score is not just above or below a single threshold. It falls into a band -- Excellent, Good, Fair, Poor -- defined by multiple thresholds. But band classification is just a chain of GT comparisons.
To classify an encrypted credit score into bands, you evaluate a series of GT comparisons against the band boundaries. Score greater than 750? That is the "Excellent" boundary. Score greater than 700? "Good." Score greater than 650? "Fair." Everything else is "Poor." Four bands require three GT comparisons. The band assignment is computed entirely from the encrypted GT results.
This pattern generalizes to any banded classification system: income brackets for tax computation, age ranges for insurance pricing, severity levels for medical triage, priority tiers for service routing. In every case, the classification is a sequence of GT comparisons against known boundaries, producing an encrypted band identifier without ever revealing the underlying value.
The key engineering insight is that band boundaries are typically known constants. They are policy parameters, not secrets. This means the GT comparisons are between an encrypted value and a plaintext constant, which is computationally cheaper than comparing two encrypted values. The band structure of credit scoring actually makes it easier to encrypt, not harder.
Application 3: Classification (Argmax = Tournament of GT)
Machine learning classification produces a vector of scores -- one per class. The classification decision is the argmax: which class has the highest score? This is the most common decision operation in all of ML, and it is built entirely from GT comparisons.
Argmax over n encrypted scores uses a tournament bracket. Compare score 0 against score 1 using GT. Compare score 2 against score 3. Continue pairwise. Take the winners and compare them. Repeat until one remains. For n candidates, this requires n-1 GT comparisons -- the same as a single-elimination tournament.
Each GT comparison in the tournament operates on encrypted score values. The result is an encrypted index identifying the winning class. At no point does any system see the scores or the classification result. The server that runs the tournament learns nothing about which class won or by how much.
This matters enormously for privacy-preserving ML. When a hospital runs an encrypted diagnostic model, the classification output (e.g., "malignant" vs. "benign") is extremely sensitive. The argmax tournament ensures that the classification decision happens entirely in the encrypted domain. The server computes the answer without ever learning what the answer is.
For systems using 4096 SIMD slots, you can run multiple argmax tournaments in parallel across the slot dimension, classifying many inputs simultaneously. The throughput scales linearly with the number of slots, making batch classification practical even for high-volume production workloads.
Application 4: Routing (Decision Trees = Chains of GT)
Decision trees are the workhorse of interpretable ML and rule-based systems. Every internal node in a decision tree asks one question: "Is feature X greater than threshold T?" That question is a GT comparison. The entire tree is a chain of GT comparisons that routes an input from the root to a leaf.
In an encrypted decision tree, the features are encrypted and the thresholds may be either encrypted or plaintext (depending on whether the tree structure itself is secret). Each node evaluates a GT comparison and produces an encrypted routing bit. The routing bit selects the left or right child. At the leaf, the accumulated routing bits identify the classification or decision.
This is not a toy example. Decision trees and their ensemble variants (random forests, gradient-boosted trees) are used across finance, healthcare, insurance, and logistics for interpretable, auditable decisions. The ability to evaluate them on encrypted data -- using nothing but GT comparisons -- means these systems can be deployed in privacy-preserving configurations without architectural changes.
A tree with depth d requires d GT comparisons per path from root to leaf. A random forest with k trees requires k * d comparisons. This is linear in the number of trees and the depth, making it tractable for real-world ensemble sizes. The encrypted evaluation preserves the exact same logic as the plaintext version -- same splits, same thresholds, same leaf assignments -- while hiding all feature values from the server.
Application 5: Policy Enforcement (GTE = NOT(GT(b,a)))
Policy enforcement is where threshold logic meets governance. A policy says: "If the risk score meets or exceeds the regulatory threshold, escalate." That is a GTE comparison, which as we established is NOT(GT(B, A)) -- a single GT with a free negation.
Policy enforcement is distinct from fraud detection in an important way. Fraud detection flags anomalies for review. Policy enforcement produces binding decisions that trigger actions. The encrypted GT result does not just flag a record -- it activates a downstream process. An insurance claim exceeding a coverage threshold triggers automatic approval. A compliance score meeting a regulatory floor certifies the entity. A patient risk level exceeding a care threshold activates a treatment protocol.
In H33-Agent-Zero, every policy enforcement decision is backed by a cryptographic attestation. The GT comparison produces an encrypted Boolean. That Boolean feeds into an attestation circuit that produces a 74-byte proof: the decision was made, the threshold was evaluated, and the result is binding. The attestation is portable -- it can be verified by any system without re-evaluating the policy or accessing the underlying data.
This is the critical link between threshold logic and real-world enforcement. GT is not just a comparison operator. It is the primitive that converts encrypted data into encrypted authority.
Where EQ Actually Matters (And Why It Is Not a Decision Primitive)
We have made a strong claim: GT covers approximately 90% of decision systems. What about the other 10%? Where does EQ matter?
Equality comparisons serve three primary purposes in data systems:
- Exact matching: "Does this ID match that ID?" Used in database joins, record linkage, and authentication.
- Deduplication: "Have we seen this exact value before?" Used in data cleaning, caching, and idempotency checks.
- Join operations: "Find all records where field A in table 1 equals field B in table 2." The foundation of relational data management.
Notice what these have in common: they are all data management operations, not decision operations. Matching, deduplication, and joining are about organizing and linking data. They are the plumbing that feeds data into decision systems, but they are not the decisions themselves.
This distinction matters because EQ has different complexity characteristics than GT in TFHE. EQ works cleanly at 4-bit widths or less. At 8-bit, EQ requires TRLWE_N=1024 parameter expansion. This is a structural noise depth issue -- it is a parameter expansion, not a fundamental limitation. But it means that EQ at higher bit widths carries additional computational cost.
The honest framing is this: all core decision primitives -- thresholding, ranking, and branching -- are production-ready at 8-bit using GT-based circuits. Equality at higher bit widths is a parameter expansion, not a blocker for decision systems. If your application needs encrypted database joins, you need EQ and you will pay the parameter cost. If your application needs encrypted decisions, GT is ready now.
Agent-Zero's Three Confidence Modes: All GT
H33-Agent-Zero, our encrypted autonomous decision agent, operates in three confidence modes. Each mode represents a different level of certainty in the decision, and each is implemented entirely with GT-based threshold logic.
High Confidence Mode: The classification score exceeds a high threshold with a large margin. A single GT comparison confirms the margin. The agent acts autonomously -- the decision is final, the attestation is generated, and the downstream action is triggered without human review.
Medium Confidence Mode: The classification score exceeds the decision threshold but falls below the high-confidence threshold. Two GT comparisons bracket the score. The agent makes a provisional decision and flags it for lightweight review -- a human verifies the attestation but does not need to re-examine the data.
Low Confidence Mode: The classification score falls below the decision threshold, or the margin between top candidates is too narrow. GT comparisons against the threshold and the margin boundary identify this condition. The agent defers to human judgment, providing the encrypted classification outputs for manual review.
All three modes use GT comparisons exclusively. The confidence mode selection itself is a threshold decision -- which thresholds the score exceeds determines the mode. There is no EQ check anywhere in the pipeline. The agent does not need to know if a score is exactly 0.75. It needs to know if the score is above 0.80 (high confidence), above 0.60 (medium confidence), or below 0.60 (defer). Those are GT comparisons.
This design is not accidental. It reflects the fundamental nature of decision systems: decisions are about boundaries, not exact values. You route execution based on which side of a boundary a value falls on. GT tells you which side. EQ tells you if you are exactly on the boundary -- a measure-zero event that decision systems handle by convention (either the boundary belongs to the upper band or the lower band, defined by whether you use GT or GTE).
The Engineering Case for GT-First Architecture
Beyond the theoretical argument, there is a strong engineering case for building encrypted decision systems on GT as the primary primitive.
First, cost predictability. A GT comparison on n-bit values costs exactly 2n-1 PBS operations. This is deterministic and independent of the values being compared. You can budget computational resources precisely. An 8-bit GT is always 15 PBS. A decision tree of depth 10 on 8-bit features is always 150 PBS. There are no data-dependent branches that change the cost.
Second, composability. GT results are encrypted Booleans. Booleans compose with AND, OR, NOT, and XOR -- all of which are either free or very cheap in TFHE. This means complex decision logic (weighted voting, majority rules, priority cascades) composes cleanly from GT outputs without additional bootstrapping.
Third, noise management. Each GT comparison produces a bootstrapped output with refreshed noise. This means GT comparisons can be chained without noise accumulation becoming a problem. A decision tree of depth 20 has the same noise characteristics at the leaf as at the root, because each node refreshes the noise via bootstrapping. This is a profound advantage over schemes where noise accumulates and eventually corrupts the result.
Fourth, parallelism. Independent GT comparisons can run in parallel. In a random forest, all trees can evaluate simultaneously. In a multi-threshold fraud system, all threshold checks can run concurrently. The 4096 SIMD slots available in our parameter sets mean thousands of comparisons can execute in a single pass.
What About Sorting?
A natural question arises: can you sort encrypted data using only GT comparisons? The answer is yes, and it demonstrates the generality of the GT primitive.
Sorting networks (e.g., Batcher's odd-even merge sort or bitonic sort) are fixed sequences of compare-and-swap operations. Each compare-and-swap is a GT comparison followed by a conditional swap. In the encrypted domain, the GT produces an encrypted Boolean, and the conditional swap uses that Boolean to obliviously select which element goes to which position -- without revealing the comparison result or the element values.
Sorting n elements requires O(n log^2 n) comparisons in the best sorting networks. Each comparison is a GT, so the total cost is O(n log^2 n) GT operations. For practical sizes (sorting a few dozen encrypted scores for a ranked recommendation), this is well within production budgets.
Sorting is relevant because ranked outputs -- "give me the top 5 candidates" -- are a common decision pattern. Top-k selection is even cheaper than full sorting: a tournament tree of GT comparisons extracts the top k elements in O(n * k) comparisons. For top-1 (argmax), it is n-1 comparisons as discussed earlier.
The Competitive Landscape: Why Others Get This Wrong
Most encrypted computation frameworks treat GT and EQ as equally important primitives and optimize for both simultaneously. This is a mistake driven by trying to build general-purpose encrypted databases rather than purpose-built decision engines.
If your goal is an encrypted database that supports arbitrary SQL queries, you need EQ (for joins and WHERE clauses) as much as GT (for range queries and ORDER BY). But if your goal is an encrypted decision system -- one that classifies, routes, thresholds, and enforces -- you need GT and almost nothing else.
This architectural clarity has allowed us to optimize aggressively for the GT path. Our TFHE implementation is tuned for 8-bit GT comparisons as the primary workload. The parameter sets, the bootstrapping keys, the memory layout, the parallelization strategy -- everything is optimized for the operation that matters most for decisions.
Competitors who try to be general-purpose end up with mediocre performance on both GT and EQ. We chose to be exceptional at GT and honest about EQ. The result is a system that can make encrypted decisions at production speed, rather than a system that can theoretically do everything but practically does nothing fast enough to deploy.
Threshold Logic and Attestation
The final piece of the threshold logic story is what happens after the decision. A GT comparison produces an encrypted Boolean. That Boolean represents a decision: yes or no, above or below, approve or deny. But a decision without proof is just a claim.
In the H33 pipeline, every GT-based decision feeds into an attestation circuit. The 74-byte attestation proves three things: that a specific comparison was evaluated, that it was evaluated on data that was encrypted throughout, and that the result is bound to the specific input. The attestation is post-quantum secured with three independent hardness assumptions, making it durable against future cryptanalytic advances.
This is what transforms threshold logic from a computation technique into an enforcement mechanism. A bank does not just compute whether a transaction exceeds a threshold. It produces a cryptographic attestation that the threshold was evaluated on encrypted data and the result is binding. That attestation travels with the decision, enabling downstream systems to act on it without re-evaluation.
Conclusion: The Right Primitive, Deployed Now
The argument is not that EQ is unimportant. The argument is that EQ is not a decision primitive. Decisions are about boundaries, and boundaries are about GT. Threshold logic -- built from GT comparisons, composed with Boolean operations, and secured with cryptographic attestation -- covers the vast majority of real-world decision systems.
All core decision primitives -- thresholding, ranking, and branching -- are production-ready at 8-bit using GT-based circuits. Equality at higher bit widths is a parameter expansion, not a blocker for decision systems. If you are building encrypted fraud detection, credit scoring, classification, routing, or policy enforcement, the primitive you need is GT, and it is ready now.
H33-Agent-Zero's three confidence modes demonstrate this in production. Every decision the agent makes -- from high-confidence autonomous action to low-confidence human deferral -- is a GT comparison against a threshold. No equality checks. No exact matching. Just boundaries, evaluated on encrypted data, producing attested decisions.
Threshold logic is not a simplification. It is the right abstraction for the right problem. And it is all you need.