Executable Knowledge Architecture for AI in Professional Work

A framework for integrating AI into professional work while preserving expertise, improving reproducibility, and closing the governance gap around AI-generated output.

AI explanations can be unfaithful. Answers to Critics explains the need for independent verification.

Anyone can now ask ChatGPT questions they once needed experts to answer. That access puts pressure on the value of expertise and on how professionals use AI.

Oracle use means asking AI questions and using its answers. Verifying those answers requires the expertise to produce them yourself. This verification paradox prevents professional accountability in the oracle pattern.

In assistant pattern, AI translates expert intent into executable code. The expert verifies the code and delivers the results.

I call this pattern Executable Knowledge Architecture (EKA). It rests on a simple foundation: knowledge is the capability to reliably produce outcomes. This makes human-AI collaboration coherent. The expert has one kind of capability (specifying intent, verifying alignment). The AI has another (producing executable implementations). Neither constitutes complete knowledge alone. Together, through a verification loop, they produce validated solutions.

The Problem with AI as Oracle

Oracle pattern exists on a spectrum. At one end is weak oracle: ask a question, get a confident answer, no dialogue. At the other end is strong oracle: real conversation, clarifying questions, probed assumptions, structured synthesis at the end.

Strong oracle makes context and assumptions more explicit and produces output more relevant to the user’s situation.

Strong oracle leaves the governance problem unresolved, while making it less obvious.

Thorough dialogue, retrieval-augmented generation, citations, and other tools leave three problems.

First, opaque reasoning, unverifiable sources, and uninspectable methodology leave no audit trail. A thorough conversation cannot provide a defensible account of how the conclusion was obtained.

Second, repeated questions or analyses may produce different answers. That inconsistency undermines ongoing work and periodic reporting.

Third, the verification paradox requires the expertise to produce the answer before you can verify it.

The verification paradox explains why organizations still need experts even as information becomes commoditized.

The Shift to Assistant Pattern

EKA solves these problems by changing what we ask AI to do. Instead of asking AI to provide answers, we ask it to translate expert intent into executable code.

The workflow has five steps:

1. Expert describes the analysis in professional language. You articulate what you want to examine, what methodology you want to apply, what comparisons you want to make. You use your domain expertise to frame the problem.

2. AI translates to executable code. It implements the specified method in code that computes the answer.

3. Expert reviews and approves the code. Reviewing a method with testable outputs differs from verifying a direct answer. The understanding asymmetry means you can understand a method without being able to invent it. You can inspect its implementation, test edge cases, and verify the logic without reproducing the entire analysis.

4. Code executes deterministically. Once approved, the code runs. It produces the same output every time given the same input. The stochastic element has been removed from the execution path.

5. Results are reproducible and auditable. Every deliverable traces back to inspectable code. Every conclusion can be re-derived. Every methodology can be examined.

Stochastic Form, Deterministic Function

Large language models are stochastic in form and deterministic in function.

Ask an LLM to write code that calculates a weighted average, and it might structure the code differently each time. Variable names may vary. Implementation details may shift. The form is stochastic.

But the function is deterministic. A weighted average is a weighted average, regardless of whether the variable is called result or weighted_sum.

In the strawberry test, an LLM often answers “two” when asked how many r’s are in strawberry. Asked to generate counting code, it produces implementations using a list comprehension, a for loop, or count(), all of which return 3. The implementation varies while the result remains the same.

EKA uses generated code to avoid relying on the LLM’s direct answer. The expert reviews whether the code implements the intended function, and executing that code produces reproducible results.

Closing the Governance Gap

AI’s accessibility creates a governance gap in professional practice. Anyone can access information directly, which pressures the value of pure information delivery. But this same accessibility increases the value of two things people cannot get from AI directly: accountability and verification.

Organizations need reliable answers they can defend, someone accountable for them, and methodology they can explain to regulators, auditors, boards, and stakeholders.

EKA makes AI’s contribution inspectable: it produces code, the expert validates that code, and execution produces the answer. The recorded methodology identifies what the expert verified.

Responsibility follows each participant’s contribution. The expert specifies the analysis and exercises judgment; AI translates that methodology into code.

Front-Door Invariants

Implementing EKA requires establishing what I call front-door invariants. These are conditions that must hold for any deliverable that leaves your organization:

1. Every AI-generated deliverable has code provenance. You can trace any output back to the code that produced it.

2. Methodology is inspectable. Stakeholders, regulators, or future analysts can examine how results were derived.

3. Results are reproducible. Running the same code on the same data produces the same output.

4. Expert judgment is preserved in the methodology, not delegated to AI. The expert decides what to analyze and how. The AI translates that decision into execution.

These invariants distinguish AI-augmented professional work from AI-generated content. They preserve the elements of expertise that justify professional accountability.

Practical Implementation

Adopting EKA doesn’t require rebuilding your organization. Start with work that already has a computational component: financial modeling, data analysis, engineering calculations, research methodology, diagnostic protocols, legal document analysis, risk assessment. These are natural fits for the pattern.

Train your team to ask AI to translate a specified method into an executable artifact: “produce an executable artifact that computes the answer given this methodology.” Code is the most common form, but any artifact with inspectable methodology and reproducible output can qualify.

Method-bearing artifacts expose the methodology so people can verify and defend it.

Experts must confirm that the artifact implements their intent. They need not author code or be software engineers. AI explanations can be unfaithful, so adversarial review must be accompanied by a check independent of the generating model’s description. Depending on the context, organizations can use human review, automated testing, secondary models, or domain-specific validation. Answers to Critics explains why independence is required.

Build your artifact repository. Every executable artifact that produces a deliverable should be version-controlled, documented, and retrievable. This is your audit trail and your methodology library. It’s also how you build the empirical track record that capability governance requires for high-stakes work.

The Verification Boundary

EKA uses unreliable AI to produce reliable artifacts by establishing a verification boundary.

AI translates the human’s specified method into code. The human supplies judgment, methodology, and accountability, and verifies the implementation. The code defines the verification boundary: both parties can inspect it, test it, and execute it deterministically.

The arrangement lets professionals use AI while meeting governance requirements. Human judgment and AI implementation together can produce more capable, transparent, and defensible work than either could alone.

Organizations that adopt this pattern will define the next era of knowledge work. It works now, with current tools, for any practice willing to organize around verification rather than direct AI answers.