What is English-as-Code?
English-as-Code is an approach where plain-English business rules are the executable program, not comments, not prompts, but the actual logic that runs. Anyone can read it, and a deterministic engine runs it exactly as written.
English-as-Code, defined
English-as-Code (also written English as Code) is an approach to automation in which plain-English business rules are the program. In traditional software, business logic is written in a programming language and English appears only as comments that describe, but never execute, the code. With English-as-Code, that relationship is inverted: the English is the source of truth, and it is what actually runs. A business user can write “If an invoice exceeds $10,000, route it to the CFO for approval,” and that sentence becomes an executable, governed step.
This is different from prompting a chatbot. A prompt asks a probabilistic model to generate a response that may vary from run to run. English-as-Code instead compiles your plain-English rules into structured logic that a deterministic engine executes the same way every time. The language model is used only to understand what you mean; it never decides the outcome.
How English-as-Code works
English-as-Code is made possible by a neurosymbolic AI architecture with two cooperating layers:
- Understanding. A neural language model reads your plain-English instructions, and any related documents like invoices, purchase orders, or claims, and translates your intent into precise, structured business logic.
- Execution. A deterministic symbolic engine runs that logic exactly as written, step by step. It cannot improvise or fabricate values, so the same input always yields the same result.
When the system encounters something it has not seen, it does not guess. It pauses, asks a person in plain English, and permanently encodes the answer, so the automation gets more capable over time instead of breaking.
Why English-as-Code matters
English-as-Code collapses the gap between the people who understand a process and the people who automate it. Because the automation is written in the language of the business, three things become true at once:
- Business users can build and maintain automations without learning to code or drawing flowcharts.
- The automation is self-documenting. The logic an auditor reads is the same logic that executes, there is no separate, out-of-date documentation to reconcile.
- It is fully auditable and hallucination-free. Every input, decision, and exception is recorded in a Business Journal, and deterministic execution guarantees there are no fabricated outputs.
How Kognitos uses English-as-Code
English-as-Code is the core interaction model of the Kognitos platform. Business teams describe a process in plain English through a conversational Builder Agent, Kognitos turns it into a governed workflow, and the patented symbolic executor runs it deterministically. This is how enterprises automate document-heavy work across finance and accounting, healthcare, IT operations, and more, in plain English, with zero hallucinations and full audit compliance. To see how the language layer and execution layer fit together, read about neurosymbolic AI and the Kognitos platform architecture.
Read the SOP.
Then read exactly what it did.
This is a real SOP from the Kognitos library, run by the AP Specialist AI employee. Quill compiles it once into code, and every step of the code maps back to its line of English. Hover a journal entry to see the step it came from, or a step to see what it did.
Overview
Screens an incoming supplier invoice against the AP ledger and recent invoice history to catch duplicates before they reach payment. It fingerprints the invoice on its identifying fields, runs exact and fuzzy duplicate detection against invoices already captured and paid in the ERP, diagnoses why a flagged candidate is or isn't a true duplicate, recommends a disposition, writes the hold or block back to the ERP, and records an evidence trail of the decision.
Inputs
| Input | Type | Default |
|---|---|---|
| invoice | file | None |
| company code | text | None |
| lookback window | decimal | 365 days |
| amount tolerance | decimal | 1% |
| fuzzy match threshold | decimal | 85 |
| auto-block confirmed duplicates | text | no |
| exception routing | text | AP exceptions queue |
Steps
- 1Open a duplicate-screening case for the invoice.
Create a tracked case for the invoice scoped to the company code, with its state set to
SCREENING. - 2Build the invoice fingerprint and pull the comparison set.
Resolve the supplier to its ERP vendor code, normalize the invoice number, and retrieve every invoice for that vendor posted or paid within the lookback window.
- 3Detect exact and fuzzy duplicate candidates.
Flag any invoice with the same vendor and normalized number. Score the rest on number, amount within the amount tolerance and date, and flag any at or above the fuzzy match threshold.
- 4Diagnose each flagged candidate.
Compare field by field and check its payment status. Tell a true duplicate apart from recurring charges, partial billings and credit memos.
- 5Recommend a disposition.
A true duplicate of a posted or paid invoice: block for payment, citing the original document number.
- 6Apply the disposition to the ERP and the case.
If auto-block confirmed duplicates is yes, post the payment block; otherwise stage it for an approver. Route anything needing review to the exception routing queue.
Outputs
- A screening verdict with the match type and the original document number it duplicates.
- A diagnosis and recommended disposition, with the reason.
- A payment block posted to the invoice in the ERP, or a staged block for approval.
- A screening report and a notification to the AP team.
- step 1Opened case DUP-7781company 1000 · state SCREENING
- step 2Fingerprint built, 214 invoices to comparevendor 100482 · ACME20931 · $48,212.50 · Sep 22
- step 31 exact match found5105600112 · same vendor + number · EXACT
- step 4Diagnosed TRUE_DUPLICATEamount, PO and lines identical · original paid Sep 28
- step 5Recommended: block for paymentcites original document 5105600112
- step 6Auto-block is off: staged for approvalapproved by [J. Rivera] · 10:42
- step 6Payment block posted, case confirmederp.post_payment_block · email → AP team
English-as-Code, answered
How is English-as-Code different from prompting an LLM?
A prompt asks a probabilistic model to generate an answer, which can vary and hallucinate. English-as-Code compiles your plain-English rules into structured logic that a deterministic engine executes the same way every time. The model understands intent; it never decides the outcome.
Do I need to know how to code?
No. English-as-Code is built so business users can create and read automations without programming. You describe the process in plain English through a conversational Builder Agent, and Kognitos turns it into a production-ready workflow.
Is English-as-Code auditable?
Yes. The logic is written in plain English and executed deterministically, so auditors and compliance teams can read it without developer translation. Every input, decision, and exception is recorded in an auditable Business Journal.
How does Kognitos implement English-as-Code?
Kognitos pairs English-as-Code with neurosymbolic AI: a neural layer interprets plain English and documents into symbolic logic, and a patented symbolic executor runs it exactly as written, with zero hallucinations and full audit compliance.