LLM-assisted diagnostics for simulation–reality discrepancies in manufacturing systems
Concept 1: SAT (Boolean Satisfiability)
What is it?
SAT is the problem of determining whether there exists an assignment of true/false values to variables that makes a logical formula true.
Simple Example:
Formula: (A OR B) AND (NOT A OR C)
Question: Can we find values for A, B, C that satisfy this?
Answer: Yes → A=true, B=anything, C=true ✓
Why it matters:
Real World Use:
┌─────────────────────────────────────┐
│ Security Check Example │
│ │
│ "Can a user access resource X │
│ given these permission rules?" │
│ │
│ → Encode rules as SAT formula │
│ → If satisfiable = access possible │
│ → If unsatisfiable = access blocked │
└─────────────────────────────────────┘
Key Takeaway:
SAT solvers answer YES/NO questions about logical conditions, making them powerful for finding security vulnerabilities
Concept 2: SMT (Satisfiability Modulo Theories)
What is it?
SMT is SAT's more powerful cousin. It extends SAT by adding theories (mathematical domains) beyond just true/false.
Comparison Table:
┌─────────────────┬──────────────────────────────┐
│ SAT │ SMT │
├─────────────────┼──────────────────────────────┤
│ Only booleans │ Integers, strings, arrays │
│ A=true/false │ x > 5, name="admin" │
│ Simpler │ More expressive │
│ Faster │ Handles real-world data │
└─────────────────┴──────────────────────────────┘
Example:
# SMT can reason about:
# "Is there a user age where this policy applies?"
age > 18 AND age < 65 AND role == "employee"
# SMT solver finds: age=30, role="employee" → SATISFIABLE
Real Application at AWS:
AWS Policy: "Allow access if user is in region us-east-1
AND request time < 6pm"
SMT encodes this mathematically and checks:
→ Are there conditions that bypass this policy?
→ Do two policies conflict with each other?
Concept 3: BDDs (Binary Decision Diagrams)
What is it?
A data structure that efficiently represents and manipulates boolean functions as a directed graph.
Visual Representation:
Formula: (A AND B) OR (NOT A AND C)
[A]
/ \
[B] [C]
/ \ / \
TRUE FALSE TRUE FALSE
Reading paths:
→ A=true, B=true → TRUE
→ A=true, B=false → FALSE
→ A=false, C=true → TRUE
→ A=false, C=false→ FALSE
Why BDDs are useful:
┌──────────────────────────────────────┐
│ BDD Advantages │
│ │
│ ✓ Compact representation of │
│ complex boolean functions │
│ │
│ ✓ Fast equivalence checking │
│ (Are two policies the same?) │
│ │
│ ✓ Efficient for hardware/software │
│ verification │
└──────────────────────────────────────┘
Concept 4: Formal Verification
What is it?
Using mathematical proof to guarantee that a system behaves correctly — not just testing, but proving correctness.
Testing vs Formal Verification:
┌─────────────────────────────────────────────┐
│ TESTING │
│ "I tried 1000 inputs, it worked" │
│ → Cannot guarantee ALL cases work │
│ → Bugs can hide in untested paths │
└─────────────────────────────────────────────┘
vs
┌─────────────────────────────────────────────┐
│ FORMAL VERIFICATION │
│ "I mathematically proved it works for │
│ ALL possible inputs" │
│ → Absolute guarantee │
│ → No hidden bugs in logic │
└─────────────────────────────────────────────┘
Real Example - AWS Zelkova:
AWS IAM Policy:
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
Formal Verification asks:
→ "Is this policy equivalent to another policy?"
→ "Does this policy allow unintended access?"
→ PROVEN mathematically, not just tested
Concept 5: Theorem Proving
What is it?
Automatically or interactively constructing mathematical proofs that a program or system satisfies its specification.
How it works:
Step 1: Write SPECIFICATION (what should happen)
"The sort function always returns
elements in ascending order"
Step 2: Write IMPLEMENTATION (the actual code)
def sort(arr): ...
Step 3: Theorem Prover PROVES specification
matches implementation
Step 4: Result = Mathematical Guarantee ✓
Types:
┌──────────────────┬───────────────────────────┐
│ Automated │ Interactive │
│ Theorem Proving │ Theorem Proving │
├──────────────────┼───────────────────────────┤
│ Computer does │ Human guides the │
│ everything │ computer │
│ │ │
│ Faster but │ Slower but handles │
│ limited scope │ complex proofs │
│ │ │
│ Example: Z3 │ Example: Coq, Isabelle │
└──────────────────┴───────────────────────────┘
Concept 6: Constraint Solving
What is it?
Finding values for variables that satisfy a set of constraints (rules/conditions).
Simple Example:
Constraints:
x + y = 10
x > 3
y > 3
x and y are integers
Constraint Solver finds:
x = 5, y = 5 ✓
x = 4, y = 6 ✓
x = 6, y = 4 ✓
Security Application:
┌─────────────────────────────────────────┐
│ "Find a set of permissions that: │
│ │
│ ✓ Allows developers to deploy code │
│ ✓ Prevents access to production DB │
│ ✓ Satisfies compliance requirement X │
│ ✓ Doesn't conflict with policy Y" │
│ │
│ Constraint solver finds the answer! │
└─────────────────────────────────────────┘
Concept 7: Automated Reasoning
What is it?
The umbrella concept combining all above techniques — using computers to reason logically about systems automatically.
How all concepts connect:
┌─────────────────────────────────────────────┐
│ AUTOMATED REASONING │
│ │
│ ┌─────────┐ ┌─────────┐ ┌────────┐ │
│ │ SAT │ │ SMT │ │ BDDs │ │
│ └────┬────┘ └────┬────┘ └───┬────┘ │
│ │ │ │ │
│ └──────────────┴─────────────┘ │
│ │ │
│ ┌───────┴────────┐ │
│ │ Formal │ │
│ │ Verification │ │
│ └───────┬────────┘ │
│ │ │
│ ┌───────┴────────┐ │
│ │ Theorem │ │
│ │ Proving │ │
│ └───────┬────────┘ │
│ │ │
│ ┌───────┴────────┐ │
│ │ Constraint │ │
│ │ Solving │ │
│ └────────────────┘ │
└─────────────────────────────────────────────┘
AWS Real-World Application:
AWS Access Analyzer (uses Automated Reasoning):
User writes IAM policy
↓
Automated Reasoning analyzes it
↓
Checks: "Does this expose resources publicly?"
↓
Mathematical proof generated
↓
User gets GUARANTEED answer, not just a guess
Summary Table
┌──────────────────┬─────────────────────┬──────────────────────┐
│ Concept │ Core Question │ AWS Use Case │
├──────────────────┼─────────────────────┼──────────────────────┤
│ SAT │ True/False possible?│ Policy reachability │
│ SMT │ Math conditions met?│ Complex policy checks│
│ BDDs │ Efficient storage │ Policy comparison │
│ Formal │ Proven correct? │ Zelkova project │
│ Verification │ │ │
│ Theorem Proving │ Can we prove it? │ Security guarantees │
│ Constraint │ Find valid values? │ Permission synthesis │
│ Solving │ │ │
│ Automated │ All of the above │ Access Analyzer │
│ Reasoning │ automatically │ │
└──────────────────┴─────────────────────┴──────────────────────┘
Key Takeaway
These techniques move security from "we think it's secure" to "we have mathematically proven it's secure" — which is the fundamental value proposition of AWS's Automated Reasoning teams like Zelkova and Access Analyzer.