TL;DR
English-as-Code makes approved English business rules the program that governs an automation.
Key Takeaways: Natural-language authoring still requires clear inputs, configured connections, testing and a controlled publication step. Compare the procedure people approve, the actions it executes and the evidence available after a run. Deterministic execution of approved logic does not guarantee the correctness of source data or model-derived inputs.
English-as-Code is Kognitos's approach to automation in which business procedures expressed in English govern executable logic. Teams describe the work, review the resulting automation document, test it with inputs and publish a version. The aim is to let business owners inspect the rules that drive work while technical teams manage the necessary integrations and controls.
For example, an accounts payable owner can specify when an invoice should be held for review. The evaluation must also establish which invoice data is available, how the purchase order is retrieved, who can approve an exception and which ERP actions are permitted.
How English-as-Code Works: From Draft to Published Automation
How do you automate a business process using natural language? Start with a specific procedure, resolve ambiguous instructions, connect the required systems, test representative inputs and publish the reviewed version. Kognitos documents this lifecycle in its Drafts guide.
- Describe the task in a draft. State the desired result and constraints. Kognitos can ask clarifying questions about document location, format or whether a threshold includes tax.
- Review the automation document. Check the generated steps and supply the required inputs. Build and verify smaller steps before extending the procedure.
- Configure the trigger and connection. In Inputs & Triggers, select the relevant integration, connection and event for an email or webhook trigger, then save the trigger.
- Run and test the draft. Use representative cases, including missing data and exceptions. Confirm both the expected result and the permitted actions in connected systems.
- Publish the working version. A published automation is a locked version of the draft. To change it, open it in Drafts, edit and test the procedure, then publish a new major version.
The SOP and journal example below illustrates how English instructions relate to execution. For your own evaluation, use connected inputs and inspect the outcome of a controlled run.
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 vs Low-Code vs No-Code
Natural-language automation and low-code automation can overlap. A natural-language interface describes how someone authors a workflow; low-code describes how much conventional programming the platform requires. Compare what is created, what must be configured and how changes are tested and released.
Microsoft Power Automate's Copilot can create and edit cloud flows from natural-language instructions. Its documentation describes suggested triggers and actions, connection setup, edits in the designer, and saving and testing a flow. It is inaccurate to describe current Power Automate as limited to simple linear templates or unable to support natural-language authoring.
Kognitos emphasizes an automation document expressed in English and inspectable execution of approved rules. Its documented draft lifecycle also includes integrations, connections, tests and published versions. English authoring does not remove those responsibilities.
| Buyer question | Kognitos Drafts | Power Automate Copilot |
|---|---|---|
| How does authoring start? | Describe the task, answer clarifications and review the automation document. | Describe the cloud flow and review suggested triggers and actions. |
| What needs configuration? | Inputs, integrations, connections and trigger events. | Connections and the parameters of the flow's actions. |
| How is it checked? | Run and test the draft before publishing. | Save and test the flow; refine it through Copilot or the designer. |
| How are changes made? | Open the automation in Drafts and publish a new major version after editing and testing. | Edit the flow through Copilot or the designer, then save and test. |
Sources: Kognitos Drafts and Microsoft: Create a cloud flow using Copilot, checked October 23, 2026. This comparison covers the documented authoring workflows, rather than a complete platform feature or pricing assessment.
Why English-as-Code Matters: Reviewing Business Intent
A readable procedure gives the business owner something concrete to review. Take the instruction: “Hold an invoice if its total differs from the purchase order by more than 2%.” The team still needs to define the comparison base, treatment of tax and currency, required records and authorized exception reviewers.
The useful test is whether the owner can inspect and correct those rules, then see the effect in a controlled run. Measure the time and technical help needed for the change instead of assuming that English authoring eliminates implementation work.
English-as-Code in Production: Evaluate One Invoice Workflow
The following is an illustrative evaluation procedure, not a customer result or a ready-to-deploy integration. Adapt it to your systems and approval policy.
Read the invoice and identify the vendor and purchase order.
Compare the invoice with the approved purchase order.
Hold missing or mismatched records for review.
Record the reviewer's decision and the rule used.
Perform only the approved ERP action.
Test a matching invoice, a mismatch and missing required data. Inspect the source records, procedure version, human decision and final ERP outcome. Then change one tolerance, test again and verify which published version handled each run.
Explore invoice matching and exception resolution and the exception-handling walkthrough for the next evaluation steps.
How do you test an English rule change?
Run the same inputs before and after the edit, then compare the procedure versions and actual results. This fictional exercise changes an invoice-variance threshold from 1% to 2%. It tests one rule, not a complete invoice workflow.
- Agree the policy. Use USD totals excluding tax and freight. Hold an invoice when its absolute difference from the purchase order exceeds the threshold; hold missing totals for review.
- Record the baseline. Test the six supplied cases at 1%. Keep the source values, procedure version and actual decision.
- Change and retest. Have the business owner review the 2% rule. Repeat all six cases, including exact boundaries and missing data. Record technical help and time required.
- Review before release. Investigate unexpected results and approve the tested change before publication. This exercise authorizes no ERP posting or payment.
Download the six test cases (CSV) and the policy and evidence worksheet (Markdown). Expected decisions are illustrative; actual results start blank and every case is Not tested.
For Kognitos's documented edit, test and publish lifecycle, see the Drafts guide.
The Business Impact: Shared Ownership of Automation
Business owners define the rules and expected outcomes. Technical and control teams verify connections, access, permitted actions and release requirements. English-as-Code provides a shared procedure for that review; it does not establish that every workflow can be delivered without technical involvement.
For a pilot, record manual touches, exception resolution time, correct completion and the time needed to reconstruct a decision. Compare those measures with the current process before projecting savings or expanding to other workflows.
Deterministic Execution: What to Verify
Kognitos's neurosymbolic approach separates AI interpretation from symbolic execution of approved logic. The symbolic executor runs approved rules without LLM inference. Model-based planning, interpretation and exception handling should be evaluated separately from that execution layer.
A deterministic calculation can still use an incorrect extracted amount or outdated source record. Inspect model-derived fields and external data as well as the rule. Do not treat deterministic execution as a blanket guarantee against incorrect business outcomes.
For audit review, ask to see the inputs, procedure version, executed steps, approvals and resulting action for a specific run. Agree retention and historical reconstruction requirements for the deployment. See the platform overview for the broader architecture.
Getting Started with English-as-Code
Choose one workflow with a business owner, accessible source data and a clear expected result. Follow the draft, test and publish lifecycle above. Include a normal case, an exception and a controlled rule change in the evaluation.
Resolving one exception and approving a rule for future cases are separate decisions. Review, approve and test reusable instructions before applying them more broadly.
Book a demo to evaluate an invoice workflow with the people responsible for its rules, systems and approvals.
