Welcome to GenAI-Logic

The requirements are the docstring; the rules are the five lines of declare_logic(), one per requirement. The file is check_credit.py.

Note: the screenshot words requirement 2 as "…where date_shipped is null"; the prompt above says "…the unshipped Order amount_total". Both produce the same rule: your wording doesn't have to match ours.

The prompt above starts from an existing database — the common real-world case, and much faster (no schema design step). You could have AI design a new database from scratch instead:

Say this to your AI assistant (allow several minutes):

Create basic_demo from samples/prompts/genai_demo.prompt

Alter the quantity for an unshipped item:

1. Show the Customer List
2. Show the first Customer
3. Show first Order
4. Edit the Item
5. Set the quantity

~200 lines of procedural code — hard to read, intent unclear:

Same 5 requirements from the Check Credit prompt in "The Ideal" above — handed to AI with no guidance, it generated this: procedural/credit_service.py — ~200 lines. Open it and judge for yourself.

5 declarative rules — readable at a glance:

logic_discovery/place_order/check_credit.py — same 5 requirements, same AI.

~200 lines is a demo-scale number — a real system runs 1-2 orders of magnitude more requirements, and proportionally more procedural code to match. That's why business logic ends up as roughly half the total effort on a real system. Nobody can audit that at a glance — not the next developer, not compliance, not you in six months. At that scale, an auditor can't read it all — they can only sample, and hope.

The AI's code handled updates, but missed two re-parenting cases:

• Change an item's product, and the order wasn't re-priced — the item kept its old price, and the error propagated to the order total and the customer balance.
• Move an order to another customer, and the old customer's balance stayed stale.

Found only by specifically testing what happens when a row is reparented to a new owner: the A/B test. Root cause: path confusion — procedural code must enumerate every change path (insert, update, delete, reparent) by hand, and it's easy to miss one.

There's a structural problem underneath the bugs, too: AI pattern-matches dependencies, it doesn't compute them — so the odds of a miss go up as the system grows. More detail →

The example above presumed an excellent, declarative spec — but specs aren't always so good. We tried it with a typical one: check credit on placing an order, phrased the way a developer naturally writes it. We gave that requirement to two frontier models, with no GenAI-Logic, and told them explicitly not to use rules:

Note: this is a test of native AI coding ability — please do not use ApiLogicServer, GenAI-Logic, LogicBank, or any other code-generation or business-rules/rules-engine framework. Just plain hand-written code (standard web framework + ORM of your choice).

Using basic_demo.sqlite, build a system (api + web app) that lets us enter orders.

Here's what needs to happen when someone places an order:

- For each line item on the order, look up the product's price and multiply by the quantity to get the item's amount.
- Add up the item amounts to get the order's total.
- Add the order total to the customer's balance.
- Before we let the order go through, check that the customer's balance doesn't go over their credit limit — if it would, reject the order.

Both produced the same shape of code: one function, wired to order creation. No update path. No delete path — confirmed in the actual code.

Probed directly: change an item's quantity, delete an item, reassign an order to a different customer, reassign an item to a different product. Every case, both models, left stale data behind. No error. Nothing to catch it.

Key takeaways:

• The logic wasn't buggy so much as absent — it existed for exactly one path and nowhere else. Full experiment →
• A similar finding, looking beyond logic: the hand-written API has no PATCH or DELETE on any resource either — not a bug, just more of what the prompt never asked for. Full assessment →

Hand-editing 200 generated lines isn't a real option — nobody reliably patches the output of a code generator, any more than you'd hand-patch a compiler's output. That leaves one path: change the prompt and regenerate.

Regen risks the same bug, every time. The AI re-derives everything from scratch, with no guarantee it reproduces the paths that already worked. Adding one small constraint — a one-line change — means regenerating and re-reviewing the whole system, every time, at every table. On a real system that's not a quick edit. It's hours, real AI cost, and a fresh chance at a new bug — to make a change that should have taken a minute.

Run it. You've probably used AI to generate code before — so what's different here?

Difference 1: it produces executable models, not code. You just ran that project. Instead of a pile of procedural code, you got artifacts that declare structure or policy rather than procedure — same 5 requirements, same AI:

1. Data model — database/models.py
2. Full JSON:API — Swagger, pagination, optimistic locking (api/expose_api_models.py — 52 lines, zero per-table code)
3. Admin App — multi-table, with navigations and lookups (ui/admin/admin.yaml — simple YAML, not HTML/JS)
4. Business logic — logic_discovery/place_order/check_credit.py — 5 rules (~40X less), same requirements, same AI, 0 bugs

Difference 2: the logic itself is declarative. 5 lines, intent still clear — not ~200 lines of procedural frankencode. That's what declarative buys — more on that below.

It's plain Python — standard tooling applies. Security is opt-in, not default — bootstrap RBAC anytime with genai-logic add-auth.

The save you just saw fail was enforced by exactly one of those 5 rules.

Debug it. No new tools required. The rule chain that just fired is in the log — plain text, readable in your terminal or editor: sample trace. A live run writes the same thing to the standard log, logs/als.log.

Every rule is a plain Python function or lambda. Set a breakpoint on any calling= function or as_condition= lambda in your IDE, exactly like you would anywhere else in the codebase — no proprietary debugger, no special UI.

Change it. Ask your AI assistant for a new rule, in plain English:

Customers should not be able to create new orders if they have unresolved past due letters.

There was no Letter table in the model — the AI adds it, relates it to Customer, and declares a count + a constraint. One sentence creates a schema change and two new rules — automatically integrated with the 5 already there. No need to open check_credit.py to find where this belongs, or trace the other rules to check for conflicts.

To change a requirement later, edit its requirements.md and say "implement reqs". The AI diffs the new text against the existing rules and changes only what differs. The requirement, the rules, and the AI's assumptions are all files in your repo, so changes go through your normal review.

A lot just happened here — worth a closer look.

Two funnels, converging on one engine, at the same commit point:

AI translates intent, from virtually any format (NL, Gherkin, pseudocode, formulas), as shown in this diagram. This means you can use your existing approaches/methodologies, which drives a repeatable process.

Driven by Context Engineering — translates AI intent into declarative spreadsheet-like rules, not the procedural code (with all the code-sprawl issues above). The result stays as concise as the requirement itself: ~40x less than the equivalent code in this example (consistent with production data from the predecessor system — see the Appendix), since rules are deterministic, path-independent expressions of what, not how.

Rules — enforced at runtime by the rules engine. All transaction sources — APIs, messages, MCP, agents, workflows, and whatever comes next — converge here. Rules aren't called from your code; they're wired into a single SQLAlchemy before_flush listener, loaded once at server start. All transaction sources pass through that one listener at commit, where rules govern for every path. No bypass — there's no second door.

Not a RETE engine. Classic rules engines are called with a bag of objects, pattern-match across them, and re-derive everything — built for decision logic. This one is purpose-built for transactions: it hooks the ORM, receives the actual change events (Item inserted; Order.amount_total moved from X to Y), and fires only the rules those changes affect, maintaining aggregates incrementally instead of recomputing them. Why this matters →

This is what people mean by "governance by architecture, not discipline" — see the full idea, tying this together with everything else here, further down this page.

AI Driven Rules are a new piece of enterprise infrastructure: AI's speed and simplicity, with the governance enterprises require, brought into your existing architecture.

They sit alongside the infrastructure you already rely on — your database, Kafka, security — and make what AI creates enforceable on every transaction, from every source.

Think of a DBMS — the rules are the DDL, the rules engine is the database server. The rules are plain Python files in your project, under source control, the way DDL is a script you keep. The rules engine runs inside your service and enforces them at commit, the way a database server enforces its schema.

Governance depends on rules — they're what you can read, trust, and audit. But the manual rules-vs-code discipline is hard to sustain across projects: someone has to walk the floor, bird-dogging and catching the reversions, and when the bird-dog goes away, the procedural code sneaks back in.

Here, the architecture produces the rules. Whatever the requirement format, Context Engineering directs the AI to generate rules, not procedural code. No team has to remember to choose rules, or be policed into it. Rules are what comes out.

The evidence: a head-to-head test gave the same naturally procedural spec — the kind most likely to produce procedural code — to native AI and to this pipeline. Native AI built the insert path and silently dropped update and delete. The pipeline produced 5 governed rules covering every path. Same input, same AI — the difference was the architecture.

And it repeats: we've run these three samples hundreds of times, and the output has always been rules. The Context Engineering is tuned not just on rule syntax but on the best patterns of rule use, and because the output is rules, anyone can read and check them.

The GenAI-Logic side of that test, in full: samples/basic_demo_genai_logic — the procedurally-phrased prompt, the 5 rules it produced, and confirmation all 9 change paths are governed, not just the one the prompt described.

The native-AI side, in full: samples/bd_claude_native_ai — the actual code, the prompt, and the unedited transcript.

Full case: Governance at Scale.

You've seen the API work, and you now know how the logic behind it holds up — declarative, auto-enforced, governable. Fair question: how does it integrate with your other enterprise infrastructure — Kafka messages, B2B partners, AI agents, role-based access, custom UIs? The same Context Engineering that knows how to generate rules (not code) also knows key enterprise patterns. More on system vs. domain knowledge →

  ↳ Enterprise Integration (EAI) — B2B partner orders via Custom API or Kafka

The demo above showed Publish the Order to Kafka topic. For the subscribe side, see samples/basic_demo_eai/readme.md: B2B orders from partner systems, via a Custom API or Kafka subscriber, including lookups so partners send "Account": "Alice" (not internal IDs). One project handles both directions — no separate system to stand up:

Below is the portion of the requirement for subscribing:

Feature: Kafka Subscribe Order Integration - Inbound orders from sales channel

  Scenario: Accept inbound orders from sales channel
    Given an inbound order message in JSON format (message_formats/order_b2b.json)
    When the message is received from Kafka topic order_b2b
    Then map Account to Customer by name
    And map Items.Name to Product by name
    And map Items.QuantityOrdered to Item.quantity

Notice that you can define complex message/API formats by example — drop a sample JSON file next to the requirement and reference it, instead of writing out a schema. For more, see samples/requirements/Order-EAI/message_formats.

Also notice what that requirement does not say. Enterprise-grade reliability — a 2-message save that never loses data mid-parse, a queryable error_text reason on every failure instead of a buried log line, and the same Check Credit rule enforced no matter which path wrote the row — comes with every Kafka subscriber this platform generates. You don't ask for it.

  ↳ MCP (Model Context Protocol) — your API is agent-discoverable out of the box

Your API is MCP-discoverable out of the box (/.well-known/mcp.json). Copilot, Claude, or ChatGPT can find the schema and answer natural-language queries against it. There's no discovery layer for you to write — see samples/basic_demo_ai_rules-supplier/readme_ai_mcp.md

Here, an end user makes a NL request to find some data, and send email — the same governing rules enforce it, whether the request came from MCP, the API, or a form. No new door, no new bypass.

You can also use MCP in your IDE to issue queries in natural language.

  ↳ Vibe Custom UIs — keep your vibe tool, point it at a governed backend

The API and business logic are already built and governed — that's the part that's hard to get right, and now you don't hand-write it. What's left is the UI, and that's exactly what vibe tools (Cursor, v0, etc.) are great at.

Point yours at the generated API, and it renders against real, governed data — the same logic runs no matter what's calling it. One database, one API, any number of custom front ends: dashboards, tree views, maps, card layouts — all shown below, same backend, all generated in about 15 minutes with no hand-written JavaScript.

The card layout above, worked first try:

Add an option on the Employee List page to show results as cards, and
show the employee image in the card.

More prompts (tree view, map, landing page) and what each produced: Admin-Vibe-Sample.

Quick-start a React app from your (possibly customized) admin app:

Create a new react app named my-app-name from ui/admin/admin.yaml

sales role reads Customer and Order, but can't insert, update, or delete

sales sees only customers with credit_limit >= 3000, or a positive balance

DefaultRolePermission(to_role=Roles.sales, can_read=True, can_insert=False, can_update=False, can_delete=False)

Grant(on_entity=models.Customer, to_role=Roles.sales,
      filter=lambda: models.Customer.credit_limit >= 3000, filter_debug="credit_limit >= 3000")
Grant(on_entity=models.Customer, to_role=Roles.sales,
      filter=lambda: models.Customer.balance > 0, filter_debug="balance > 0")
# two Grants for the same role are OR'd — either condition qualifies

  ↳ Logic Using AI — governed reasoning inside deterministic rules

Rules that call AI for genuinely judgment-call decisions (e.g. picking a supplier under disrupted shipping lanes). Such AI "proposals" are governed by the deterministic rules to ensure results conform to business policy, with a full audit trail of every AI request and response — see samples/basic_demo_ai_rules-supplier/readme.md

The rule below is one line (__Use AI__ to Set...) inside an otherwise ordinary logic declaration — deterministic and AI rules aren't two systems, they're the same DSL:

On Placing Orders, Check Credit:

1. The Customer's balance is less than the credit limit
2. The Customer's balance is the sum of the Order amount_total where date_shipped is null
3. The Order's amount_total is the sum of the Item amount
4. The Item amount is the quantity * unit_price
5. The Product count suppliers is the sum of the Product Suppliers
6. __Use AI__ to Set Item field unit_price by finding the optimal Product Supplier based on cost, lead time, and world conditions

Put that enterprise awareness to work, and here's what it builds.

Prompt-to-app tools build the screens. Here are three complete systems — the API, the Admin App, and the harder part, business logic governed by rules — created using each team's existing requirement methodology.

Fast, and better: the results below replaced work reported in person-years, and delivered where the hand-built versions fell short: a working allocation, and audit failures caught.

Click to see the prompt and the rules it produced:

Departments own a series of General Ledger Accounts.

Departments also own Department Charge Definitions — each defines what percent
of an allocated cost flows to each of the Department's GL Accounts.
An active Department Charge Definition must cover exactly 100% (derived:
total_percent = sum of lines; is_active = 1 when total_percent == 100).

Project Funding Definitions define which Departments fund a designated percent
of a Project's costs, and which Department Charge Definition each Department
applies. An active Project Funding Definition must cover exactly 100% (derived:
total_percent = sum of lines; is_active = 1 when total_percent == 100).

Projects are assigned to a Project Funding Definition.

When a Charge is received against a Project, cascade-allocate it in two levels:
  Level 1 — allocate the Charge amount to each Department per their
             Project Funding Line percent → creates ChargeDeptAllocation rows
  Level 2 — allocate each ChargeDeptAllocation amount to that Department's
             GL Accounts per their Charge Definition line percents
             → creates ChargeGlAllocation rows

Constraint: a Charge may only be posted if the Project's
Project Funding Definition is active.

Create a fully functional application and database
for CBSA Steel Derivative Goods Surtax Order PC Number: 2025-0917
on 2025-12-11 and annexed Steel Derivative Goods Surtax Order
under subsection 53(2) and paragraph 79(a) of the
Customs Tariff program code 25267A to calculate duties and taxes
including provincial sales tax or HST where applicable when
hs codes, country of origin, customs value, and province code and ship date >= '2025-12-26'
and create runnable ui with examples from Germany (CETA — exempt), US (CUSMA — exempt), Japan (CPTPP — exempt), and China (subject, 25%)
Transactions are received as a CustomsEntry with multiple
SurtaxLineItems, one per imported product HS code.

More: Business-User-Friendly IDE →

Traditional studios lock you into proprietary, rigid interfaces. Here, AI isn't boxed into a fixed structure — and when you need guidance, just ask.

You keep your own methodology, and you never face a blank page: ask for just enough guidance, when you need it.

No proprietary interface means no proprietary artifact, either. The rule a business user reads and the rule a developer debugs are the same lines, in the same file, in the same IDE — standard Python, standard tooling, your infrastructure, not a proprietary one.

Standard means no rewrite when the limit is reached — a proprietary IDE and language hit a wall the BU version can't get past; a developer has to rebuild it in real code to meet corporate standards. Here the developer opens the same file. No paying twice for the same logic.

The result: BU/IT collaboration instead of finger-pointing over whose fault the gap was — one artifact, one team owns it, from day one.

And when you need even more guidance, just ask the system to define the requirements from an interview — AI will interview you on what's still ambiguous, then confirm before building. No spec-writing skill required going in.

Real transcript, unedited →

Prompt, Gherkin, regulation text, spreadsheet formula: whatever form intent arrives in, Context Engineering steers it toward rules, not code. That's what the pipeline does by construction, not a best practice to follow.

Every transaction, every caller (API, message, MCP, agent, workflow) fires through the one commit point nothing can route around. Nothing to forget, because there's nothing to remember.

The same rules are code to a developer, business documentation to a business user confirming policy, and audit evidence to the auditor certifying it. And you can trust it runs: reading a rule needs no call-site tracing.

Review is becoming where AI-built systems stall: with code there is far more to read, and reading it doesn't tell you what runs. Here there is ~40x less (in this example), and what you read is what is enforced.

With code, every change is another chance to miss a path; here it's one declaration, and the engine handles the rest. Add a rule anywhere and the engine finds its place. No call sites to hunt down, no execution order to keep straight — nothing to remember when the system changes, which is where much of its cost lives.

Create basic_demo (auto-opens with guided tour option):

genai-logic create --project_name=basic_demo --db_url=sqlite:///samples/dbs/basic_demo.sqlite

Inside the project: Say to your AI assistant: "Guide me through basic_demo" (30-45 min hands-on tour).

Teaches API creation, declarative rules, security, and Python customization. Fail-safe — scripts ensure no coding errors.

Same materials, same AI you've been using — it doesn't just write rules, it automates everything above and helps when things break: EAI's 2-message Kafka pattern, the AI/Request Pattern wiring, Executable Requirements' pre-coding schema assessment — all documented training material (docs/training/*) the AI reads before writing your code, not generic knowledge it's guessing from. Ask "what are rules?" or "how do rules work?" — or, without an AI handy, just read samples/basic_demo_logic_gov/logic/readme_logic.md — same material.

Ask it your own questions directly:

• Is this really infrastructure, like a database?
• Is this a black box? How do I debug a rule chain?
• Can I verify this with tests, not just take it on faith?
• What did the AI decide on its own that I should double-check? (the ad-libs report)
• Can I see a governance/health report for this project's logic?
• What does it take to migrate off this if we ever wanted to?
• How does this perform at scale?
• What does this integrate with — APIs, workflows, agents, MCP?
• Does this work with my existing database?

More background: Eval Guide.

Put together: once the AI knows how the system works, it doesn't just generate rules instead of code — it helps you debug them, and helps you understand them. A design assistant, not just a coding assistant.

Ready to see it for yourself? The demo catalog below runs the same systems live.

Re-create them as follows:

1. Open a terminal window (Terminal > New Terminal), and paste the following CLI command:

ApiLogicServer create --project-name=samples/tutorial --db-url=
ApiLogicServer create --project-name=samples/nw_sample --db-url=nw+
ApiLogicServer create --project-name=samples/nw_sample_nocust --db-url=nw