Engineers reviewing AI generated software behavior with blueprint, topology, and evidence overlays in a dark technical workspace.
Back to archive
CMS

How AI Intuition Becomes Reviewable

How AI intuition can become reviewable through bounded software blueprints, evidence metadata, and independent verification workflows.

2026-03-22T00:00:00.000Z

Carlos E. Perez (@IntuitMachine) says AI is intuition, not intelligence. He is right. And that is exactly why we need something AI cannot override.

The Intuition Revolution

Carlos E. Perez, a former IBM Watson Research engineer turned independent AI researcher, has been making an argument that most of the AI industry still refuses to hear: deep learning is not artificial intelligence. It is artificial intuition. And that distinction changes everything.

In his Artificial Cognition trilogy and his Quaternion Process Theory (QPT), Perez takes Kahneman's dual-process model, System 1 fast, System 2 slow, and adds a second axis: Fluency versus Empathy. The result is four cognitive modes: fast-fluent pattern recognition, slow-fluent mathematical reasoning, fast-empathic social reading, and slow-empathic moral deliberation. Four quadrants that map the entire space of cognition.

His central observation is devastating in its simplicity: today's large language models operate almost entirely on the Fluency axis. They complete patterns. They generate plausible text. They write code that looks correct. But they lack the Empathy axis entirely, the ability to model the internal states of other agents, to understand consequences from another perspective, to grasp what their output actually means for the humans who depend on it.

LLMs do not reason. They intuit. And Perez is absolutely right about that.

But here is the question nobody is answering: what do you do with a machine that has extraordinary intuition but zero accountability?

The Problem Perez Identified

To his credit, Perez does not stop at diagnosis. He identifies what he calls the verification bottleneck: AI systems now generate code, text, and decisions faster than any human team can review them. The gap between generation speed and verification capacity grows wider every single month. We are drowning in AI output that nobody can verify.

His proposed solution is autoformalization, using semantic embedding spaces to bridge informal human reasoning and formal mathematical proof. The concept is elegant: let the AI's intuition guide the search, then verify the result formally. Preserve the creative leap, but land on solid ground.

But there is a fundamental problem. Circularity.

When an AI generates code and then generates the tests for that code, who verified the verifier? When an AI produces a formal proof sketch and another AI checks it, you have two intuition machines agreeing with each other. That is not verification. That is consensus. And consensus among unreliable agents is not the same as correctness. It never will be.

Perez has identified exactly the right problem. But the solution he proposes still lives inside the same system it is trying to verify. The intuition checks itself. That is like asking a surgeon to grade their own exam. No matter how skilled the surgeon, the conflict of interest is structural.

Intuition Needs Bones

Consider a pilot with thirty years of experience. Their intuition is extraordinary, they can feel turbulence patterns before instruments register them, sense mechanical anomalies from the subtlest vibration, make split-second decisions that save hundreds of lives. Nobody questions the value of that intuition.

But no airline on Earth lets a pilot fly without TCAS, the Traffic Collision Avoidance System. No matter how experienced the pilot is, when TCAS says "DESCEND NOW," the pilot descends. The system does not debate. It does not negotiate. It does not care about the pilot's thirty years of experience. It overrides.

The same principle applies to every car on the road. ABS does not care about your driving skills. ESC does not ask if you meant to oversteer. These systems exist because intuition, no matter how refined, no matter how experienced, operates on incomplete information and is subject to failure modes that the intuitive agent cannot predict or even perceive.

Even the human body follows this architecture. The brain is creative, adaptive, brilliantly intuitive. But it sits inside a skeleton that constrains its range of motion. Bones do not think. They do not need to. They prevent the body from moving in ways that would destroy itself. The brain proposes. The bones constrain.

Intuition is the most powerful cognitive tool we have ever encountered, in humans or in machines. But it needs structure that it cannot override. That is not a limitation. That is what makes it safe.

Software built by intuitive AI agents has the exact same problem. The generation is impressive. The fluency is genuinely remarkable. But without an independent structural layer that certifies correctness, without bones, the system is a brain floating in space. Capable of anything. Constrained by nothing. And that is terrifying.

The Circuit Layer

This is where Digital Circuitality enters the picture, not as a replacement for artificial intuition, but as the bones it has always needed.

Digital Circuitality treats software the way hardware has always worked: a finite set of review-scoped atomic operations, monomers, composed through algebraic laws, EVA algebra, review-scoped by an independent engine, the TCE, that measures informational closure. When a program achieves closure check passed, the circuit is closed. Every input maps deterministically to an output. Zero information leakage. Zero ambiguity. Zero "it depends."

The key insight is the finite space. An LLM can generate any program in supported targets, an infinite space where verification is undecidable. But when that program is analyzed by the BRIK64 Lifter, it maps onto a bounded set of 64 core operations. In a finite space, exhaustive verification becomes possible.

What the Lifter maps to core monomers gets review-scoped with closure check passed, deterministic, proven, permanent. What maps to extended monomers gets a CONTRACT score, trusted by agreement, declared honestly. What cannot be mapped at all stays outside the review-scoped boundary, clearly flagged as unverifiable. Complete transparency. No hand-waving.

The LLM intuits. The circuit certifies. These are fundamentally different operations performed by fundamentally different systems with fundamentally different guarantees. The certification does not depend on the generator's opinion of its own work. It does not care if the code was written by a human, by GPT, by Claude, or by a random number generator. It depends on algebraic properties that hold regardless of how the code was produced.

This is what breaks the circularity that Perez's autoformalization cannot escape. The verifier is not another AI. It is not another intuition machine agreeing with the first one. It is a mathematical structure. And mathematical structures do not have opinions. They have proofs.

Two Layers, One System

The intellectual frameworks of Carlos E. Perez and Digital Circuitality are not competing. They are not even in the same arena. They describe different layers of the same system, and they need each other.

Layer 1: Generation. This is Perez's domain, and it is extraordinary. LLMs operate with artificial intuition: pattern completion, creative leaps, fluent production at superhuman speed. QPT's four cognitive modes describe how these systems think, or approximate thinking. The Fluency axis generates code, text, decisions. The Empathy axis, when it arrives, will model consequences and stakeholder impact. This layer is powerful. It is creative. And it is fundamentally, structurally unreliable.

Layer 2: Certification. This is Digital Circuitality's domain. A finite algebra of review-scoped operations. An independent coherence engine. Hardware enforcement through the BPU that cannot be bypassed, negotiated, or jailbroken, not by software, not by the AI, not by anyone. This layer is rigid. It is deterministic. And it is fundamentally, structurally trustworthy.

RLHF teaches an AI to want to do the right thing. Policy circuits prevent it from doing the wrong thing. Education fails every day. Physics does not. That is the difference between Layer 1 and Layer 2.

The two-layer model resolves a tension that neither side can address alone. Pure intuition without verification produces impressive but untrustworthy output, the verification gap that costs $2.41 trillion annually in software failures. Pure verification without intuition produces correct but trivial programs, nobody wants to write everything in a 64-operation algebra by hand. You need both.

Together, they form something that has never existed before: a system where AI generates ambitiously and structure certifies rigorously. The creative power of intuition, bounded by the bounded review evidence of circuitry. The brain inside the skeleton. The pilot with TCAS. The future of safe AI.

The Debt We Owe

Digital Circuitality did not emerge in a vacuum, and intellectual debts should be paid in public. Perez's Quaternion Process Theory helped shape this architecture in ways that deserve full acknowledgment.

It was QPT's insistence on the Fluency–Empathy axis that clarified what verification alone cannot cover. When we designed the two-tier certification model, CORE (closure check passed, deterministic) and CONTRACT (extended monomers, trusted by agreement), we were drawing a line that QPT had already mapped: the boundary between what can be supported by bounded evidence and what requires a fundamentally different kind of trust.

The decision to separate the decision space from the execution space in BRIK64's policy circuit architecture came directly from engaging with Perez's framework. Empathy operates in the decision space, what should the system do? Which action best serves the user's needs? Determinism operates in the execution space, given a decision, does the implementation produce the correct result? QPT made this distinction legible.

A pilot decides to divert based on intuition and empathy for passengers. TCAS verifies the new altitude is safe. These are not the same operation, they compose. That compositional insight, that safety requires both an intelligent proposer and a rigid verifier working in concert, owes a genuine debt to the cognitive architecture Perez described.

Digital Circuitality provides the bones. Quaternion Process Theory helped us understand what the bones need to hold. And together, they point toward a future where AI is not just powerful, it is trustworthy.

Carlos E. Perez publishes as @IntuitMachine on X, writes at Intuition Machine on Medium, and shares books and research products through Intuition Machine on Gumroad.

More reading

Continue the archive

Full archive
Evidence pack folder beside a secure workstation showing software logic blueprints on office monitors.
SOFTWARE EVIDENCESoftware Governance

Software Logic Evidence Infrastructure: The Evidence Layer for AI-Generated Code

AI makes code generation cheap. It does not make software understanding cheap. Software Logic Evidence Infrastructure turns software logic into reviewable, traceable evidence.

Open article
Software logic blueprint with connected monomer nodes, evidence lanes, and registry handoff paths.
Blueprints

What BRIK64 Can Do With Logic Blueprints

BRIK64 creates software logic blueprints for planning, lifting, AI review, migration, CI/CD gates, evidence, agent governance, ownership, and reuse.

Open article
Editorial software engineering review room with abstract blueprint and evidence overlays on dark monitors.
CMS

Reviewable AI Coding Pipelines: From Prompt to Blueprint

AI-generated code workflows become more reviewable when teams separate the prompt, generated code, structural blueprint, human review, and target compilation.

Open article
BRIK64 editorial image showing AI-generated software becoming inspectable, certified, and compiled across targets.
CMS

Making AI-Generated Software Reviewable

AI-generated software can move quickly, but it still needs structure, traceability, and review boundaries. BRIK64 helps teams preserve the blueprint behind generated code.

Open article
Editorial cover for AI Governance Workflows Need Reviewable Technical Evidence
CMS

AI Governance Workflows Need Reviewable Technical Evidence

How bounded software evidence can help teams carry AI governance reviews into compliance workflows without implying full legal coverage.

Open article
Editorial cover for Compiler Evidence: Targets, Proof Files, and Test Scope
CMS

Compiler Evidence: Targets, Proof Files, and Test Scope

A summary of the public numbers that can be stated responsibly and the limits of what those numbers prove.

Open article
Editorial cover for Safety-Critical Software Needs a Readable Assurance Path
CMS

Safety-Critical Software Needs a Readable Assurance Path

How bounded software evidence can support engineering review in high-consequence domains without replacing the broader safety program.

Open article
Editorial cover for Bounded Contract Logic Before Deployment
CMS

Bounded Contract Logic Before Deployment

Why smart contract workflows benefit from explicit state boundaries, value constraints, and reviewable rule sets before deployment.

Open article
Editorial cover for What the Proof Material Means for Users
CMS

What the Proof Material Means for Users

A practical note on the proof files behind the compiler and what remains invisible to a normal authoring workflow.

Open article
Editorial cover for Why a New Format Instead of Another General-Purpose Language
CMS

Why a New Format Instead of Another General-Purpose Language

Why BRIK64 introduces PCD as a bounded computational format rather than extending a conventional language with another annotation layer.

Open article
Editorial cover for Adversarial Testing Against the Compiler Chain
CMS

Adversarial Testing Against the Compiler Chain

How the team tries to break the compiler and what those tests can and cannot prove about the formal system.

Open article
Editorial cover for Translation Validation Across Two Targets
CMS

Translation Validation Across Two Targets

A look at cross-target output comparison, what it can support, and what still depends on the bounded intermediate form.

Open article
Editorial cover for Why Tests Passing Is Not the Same as Closure
CMS

Why Tests Passing Is Not the Same as Closure

A look at sampled testing versus bounded verification, with examples of logic that passed tests but still required stronger structural checks.

Open article
Editorial cover for One Blueprint Across Multiple Targets
CMS

One Blueprint Across Multiple Targets

How the transpilation chain uses PCD as a bounded intermediate form, what 10 source languages and 14 targets mean in practice, and where the equivalence claim stops.

Open article
Editorial cover for API and MCP Access Around the Registry
CMS

API and MCP Access Around the Registry

How discover-and-execute workflows expose registry and platform operations to humans and agents without enlarging the proof claim.

Open article
Editorial cover for Blueprints Before Refactors
CMS

Blueprints Before Refactors

How extracting bounded computation from an existing codebase can make rewrites and target changes easier to review.

Open article
Editorial cover for A Bounded JavaScript-to-Rust Workflow
CMS

A Bounded JavaScript-to-Rust Workflow

Lift the logic, review the bounded blueprint, then emit a target language while keeping the claim attached to the intermediate circuit.

Open article
Editorial cover for Lifting Existing Code into a Reviewable Blueprint
CMS

Lifting Existing Code into a Reviewable Blueprint

What the Lifter preserves, where liftability evidence exists in the repo, and how bounded blueprints help before migration.

Open article
Editorial cover for COBOL Migration Through Bounded Lift-and-Review
CMS

COBOL Migration Through Bounded Lift-and-Review

Why legacy modernization benefits from lifting review-critical logic into a bounded blueprint before transpilation or replacement.

Open article
Editorial cover for Why AI-Generated Code Needs Blueprints and External Checks
CMS

Why AI-Generated Code Needs Blueprints and External Checks

Generated code and generated tests can fail together. This note explains why BRIK64 keeps verification outside the model loop.

Open article
Editorial cover for Which Parts of a Codebase Are Ready for Stronger Review?
CMS

Which Parts of a Codebase Are Ready for Stronger Review?

Use lifting and bounded analysis to identify review-critical functions before migration or certification work.

Open article
Editorial cover for Laszlo B. Kish and the Information-Theory Thread
CMS

Laszlo B. Kish and the Information-Theory Thread

A research profile on the ideas that influenced the information-theoretic framing behind Digital Circuitality.

Open article
Editorial cover for Informational Entropy Is Not Thermal Entropy
CMS

Informational Entropy Is Not Thermal Entropy

Why the distinction matters for the foundations story and how it sharpens the claim boundary around Digital Circuitality.

Open article
Editorial cover for From Preferences to Enforced Action Boundaries
CMS

From Preferences to Enforced Action Boundaries

Why robotics and agent systems need explicit action gates, bounded state, and reviewable fallback paths.

Open article
Editorial cover for First PCD Circuit: A Minimal Walkthrough
CMS

First PCD Circuit: A Minimal Walkthrough

Install the CLI, write a small circuit, and inspect the bounded output path. A practical introduction to the format and the compile step.

Open article
Editorial cover for EVA Algebra: Sequence, Parallel, Conditional
CMS

EVA Algebra: Sequence, Parallel, Conditional

How three composition operators carry sequencing, fan-out, and branching through the circuit model, and what that means for compiler readability and closure.

Open article
Editorial cover for Working with the SDKs Without Leaving the Bounded Model
CMS

Working with the SDKs Without Leaving the Bounded Model

How the Rust, JavaScript, and Python SDKs expose BRIK64 patterns while keeping the formal core distinct from host-language code.

Open article
Editorial cover for Why Software Verification Still Looks Different from Hardware
CMS

Why Software Verification Still Looks Different from Hardware

A comparison between sampled software testing and the compositional review posture hardware teams expect.

Open article
Editorial cover for 128 Operations and the Boundary Between Core and Bridges
CMS

128 Operations and the Boundary Between Core and Bridges

A tour of the reviewed core, the contract-bounded extensions, and what that split means for technical scope.

Open article
Editorial cover for PCD for AI Agents: A Small Format with an External Proof Loop
CMS

PCD for AI Agents: A Small Format with an External Proof Loop

How a finite grammar helps agents author bounded logic while the compiler and policy checks stay outside the model.

Open article
Editorial cover for Precision as a Declared Domain
CMS

Precision as a Declared Domain

Why bounded numeric domains matter for floating behavior, decimal handling, and reviewable arithmetic.

Open article
Editorial cover for BPU: Policy Enforcement as a Hardware Roadmap
CMS

BPU: Policy Enforcement as a Hardware Roadmap

Why software-only guardrails share execution context with the model they constrain, and how the BPU roadmap moves policy enforcement toward FPGA and silicon.

Open article
Editorial cover for Policy Circuits for AI Safety Workflows
CMS

Policy Circuits for AI Safety Workflows

How external policy circuits can gate generated code and agent actions without claiming to solve general alignment.

Open article
Editorial cover for What Digital Circuitality Tries to Formalize
CMS

What Digital Circuitality Tries to Formalize

A bounded programming model built from reviewed operations, explicit composition, and closure checks.

Open article