Rule Engine

Position in the Stack

Eight tokens in. One command out.

The Rule Engine is the bridge between vocabulary and behavior. It takes the 8 context tokens plus memory from the Brain, runs if/then logic, and emits a single ui.command for every interaction.

Floor 1

Intent

Floor 2

8 Tokens

Floor 3

Context Brain

Floor 4 — you are here

Rule Engine

Floor 5

AX Patterns

The Short Version

An order-ticket system for your home

Before diving into the mechanics, here is the single image that makes everything click.

The Core Translation

Rule Engine is a compiler

Brain memory and Token state cannot reach the UI directly. The human facts "tired," "on the train," "one hand" don't tell the screen what to draw. Rule Engine translates those facts into a concrete drawing instruction — a ui.command.

📥

Tokens IN

Current state

Current values of 8 Context Tokens, plus facts read from Brain — allergies, budget, schedules.

Cognitive Load = high
Form Factor = phone
Social Exposure = public
Autonomy Dial = Confirm

→

⚙️

Rule Engine

Translator

Fires matching rules. Same input always produces the same output — no mood swings.

if Cognitive Load = high → density: minimal
if Form Factor = phone → layout: vertical
if Social Exposure = public → hide: prices
Composes from 23 AX Patterns

→

📤

ui.command OUT

Screen instruction

An abstract command any surface can read and render — device-agnostic drawing instructions.

density: minimal
items: 1
tone: gentle
hide: [price, calorie]

Deterministic: Rule Engine always returns the same ui.command for the same Token state — regardless of when, who, or which device calls it. Same conditions, same answer every time. It does not have moods. Consistency is the foundation of family trust.

Rule Engine if/then — tokens and brain state mapped to concrete design rules

Internal Anatomy

Read → Match → Emit

Three stages inside every Rule Engine cycle. Once you see them, nothing gets confusing.

① Read

Collect Tokens

Aggregate current values of all 8 Tokens. Pull relevant facts from Brain — a single Brain at home, up to five in enterprise. Allergies, budget, Brand constraints, Research signals — all arrive here.

② Match

Fire rules

Check every if/then condition against the current Token state. Fire every match. When multiple rules fire, overlay them by priority. Conflicts go to the Priority Weight Token first.

③ Emit

Assemble command

Merge all fired results into one ui.command object and emit it. The device is not known yet — that is the surface's problem, not the Engine's.

Key point: Rule Engine does not know the device. "Large screen because it's a fridge" or "vertical because it's a phone" — those are Token facts (Form Factor), not Engine decisions. The Engine fires a rule: if Form Factor = phone → layout: vertical. That is all.

Same for Brain: The Engine doesn't distinguish "fact from Org Brain" vs "fact from Brand Brain." Each Brain is responsible for its own contribution to the Token set. The Engine reads the synthesized result. That is why one Engine works for both a household and an enterprise.

Live example

How a morning becomes a ui.command

Mai is in the kitchen with the kids. She steps in front of the fridge. Here is what happens inside the Rule Engine.

"What should I put in Sota's lunch box… I'm running out of time."

— Mai (38) · Tuesday 7:02 AM, kitchen

1 7:02 AM — Token state Tokens IN

The moment Mai stands in front of the fridge, the system collects the current values of all 8 Context Tokens.

8 Context Tokens · 7:02 AM

① Physical State Standing · kitchen · both hands occupied with lunch boxes
② Cognitive Load HIGH — morning rush, dense calendar, 3 task switches in past 5 min
③ Social Exposure family — low public exposure
④ Priority Weight "finish lunch box in time" is the single top priority
⑤ Form Factor fridge — Samsung Family Hub
⑥ Feasibility 13 min to departure · max 8 min cooking time
⑦ Autonomy Dial Suggest — proposes only, decision stays with Mai
⑧ Disclosure Dial Family meal history + fridge inventory disclosed to AI

Brain also provides: Sota has peanut allergy · yesterday was salmon · fridge has 6 eggs, broccoli, ham

2 Rule Engine fires matching rules Engine

The Engine scans all 23 AX Pattern rule sets against the current Token state and fires every match.

Fired rules (excerpt)

if Cognitive Load = high→density: minimal, items: 1
if Feasibility < 10min→filter: only ready-fast recipes
if Brain.allergy(Sota) = peanut→exclude: peanut, sesame-cross
if Brain.history.yesterday = salmon→deprioritize: salmon
if Autonomy Dial = Suggest→action: propose only, no auto-cook
if Physical State = hands-busy→input: voice-first, tap fallback

→ 6 rules fired · merging into a single command

3 Emit the ui.command Emit

The fired rules merge into one abstract command object. At this point, "which pixel on which screen" is still undecided.

ui.command

intent: suggest_lunchbox density: minimal items: 1 tone: gentle input: voice-first candidates: [egg-ham-broccoli, omelet-rice] exclude: [peanut, sesame-cross, salmon] time-budget: 8min decision-by: user (Suggest mode)

4 Three surfaces render the same command differently Render

The key insight: one ui.command, rendered by each surface in its own grammar. The Rule Engine wrote nothing device-specific.

🧊

Samsung Family Hub

"Egg & ham lunch box? Ready in 8 min."
Large photo + voice "yes" button

density:minimal + items:1 = one photo + one sentence on a large screen. Hands are full so voice input.

📱

Mai's iPhone

Notification: "🥚 Egg & ham · 8 min"
Tap for details · swipe to dismiss

Same items:1, compressed to a single notification line. tone:gentle means no red badge.

🚗

CarPlay (later)

Voice only: "Made the egg & ham box this morning."
Driving · summary only · no controls

Same candidates, converted to a past-tense report. Form Factor=car means tap input is impossible.

All three share one Rule Engine output. The differences are absorbed by the rendering layer on each surface. Brain doesn't need a "fridge version" and an "iPhone version." One Brain, infinite surfaces.

5 7:35 AM — Tokens change, command changes Token update

Thirty minutes later, Mai is driving. The Tokens shift.

① Physical State Driving · both hands on wheel
② Cognitive Load MEDIUM · no new tasks permitted while driving
⑤ Form Factor car / CarPlay
⑥ Feasibility 25 min to meeting

The Engine runs the same ruleset against the new Token values. The output is entirely different.

ui.command · 7:35 AM

intent: report_lunchbox_done density: audio-only items: 1-line summary input: disabled (driving) tone: neutral

→ Same Rule Engine · different Tokens · different command

Rule Engine examples — real-world scenarios showing token combinations producing different design outputs

Notice: The Rule Engine changed nothing. Only the Token values changed — and the output followed. This is how "deterministic = same input → same output" and "context-adaptive UI" coexist. The human mood lives in the Token values (Cognitive Load, Physical State). The Engine quietly runs the same job every time.

Scale

One Engine — P1 single Brain or P4 five Brains

The Rule Engine is scale-agnostic. Whether it's a household Brain or an enterprise stack of five, the Engine always receives one synthesized Token set and runs the same rules.

⌬ Multi-Brain consistency

Rule Engine reads Token current values — but those values don't have to come from a single Brain. Whether it's P1's single Context Brain or P4's five-Brain enterprise stack, the Engine always receives one synthesized Token set.

Org Brain — persistent foundation: org chart, policies, glossary
Brand Brain × N — judgment DNA (B2C / B2B running in parallel)
Research Brain — user understanding + live CRM/sales signals
Project Master Brain — the strategist: orchestrates all projects
Project Brain × N — time-bounded, per-project execution

These Brains each contribute facts from their Identity Layer, Learning Layer, and Now Layer to a Token Bus. The Rule Engine never counts Brains — it runs the same translation every time. Same Engine, different Brain configuration — output changes with the Tokens.

Technical Depth

Rule syntax · schema · conflict resolution

Rule Engine is not theory. Three YAML files and 33 Behavior Rules — actually writable.

context.yml

Token + Brain schema

Declares types, valid values, and defaults for all 8 Context Tokens. Also defines Brain reference types — brain.allergy, brain.history.yesterday, etc.

rules.yml

33 Behavior Rules

If/then condition-to-output mappings. Each rule carries a priority (0–999) and tags declaring which AX Pattern(s) it belongs to.

patterns.yml

23 AX Pattern recipes

Delegation / Escalation / Adaptation / Enterprise — 4 categories. Defines which rule groups constitute one "Pattern fire."

ui.command schema

Output structure vocabulary

intent / density / items / tone / candidates / exclude / input / time-budget / decision-by — the shared dictionary every surface reads. Implementation may be JSON or protobuf.

rules.yml — excerpt

- id: cog_load_minimal when: { cognitive_load: high } then: density: minimal items: 1 priority: 80 tags: [A2-cognitive-scaling] - id: hands_busy_voice when: { physical_state: hands_busy } then: input: voice-first fallback: tap priority: 70 tags: [A4-input-mode-switch] - id: dyn_friction_high_value when: autonomy: Auto price: { gt: 15000 } then: require_confirm: true reason: "high-value purchase" priority: 100 tags: [D6-dynamic-friction] - id: disclosure_guard when: disclosure: hidden autonomy: { gt: Confirm } then: constraint_violation: true reset_to: Confirm priority: 999 tags: [E5-trust-breach-recovery]

Conflict resolution — what happens when rules contradict?

Multiple rules firing simultaneously is normal. Non-conflicting rules all apply. Conflicting rules go through a three-stage arbitration.

Stage	Arbiter	Criterion
1	Priority Weight Token	The user's declared current priority — "finish the lunch box" — applied first.
2	Rule `priority` value	Static numeric weight (0–999). Trust-related rules such as Disclosure Guard are set to 999.
3	Brain Learning Layer	Past user decision patterns for this exact conflict type — whichever path the user has historically chosen more often.

Non-negotiable constraint: Disclosure = hidden and Autonomy > Confirm cannot coexist. "No disclosure × full delegation" is logically impossible — the Engine always resets Autonomy to Confirm. This is enforced by the priority-999 Trust Breach Recovery rule.

Deterministic = testable: Rule Engine always returns the same ui.command for the same Token state, so unit tests are straightforward. given: { cognitive_load: high, form_factor: phone } → expect: { density: minimal, layout: vertical }. Validation that an LLM can never provide.

Parts + Assembly

AX Pattern Library — 23 pieces the Engine assembles

AX Patterns are small UI blueprints. The Rule Engine decides which blueprints to select and how to compose them based on Token state. Patterns are words; Rule Engine is grammar — that is why this system is called "Context Grammar."

Delegation

D1–D6

AI handles it
(6 patterns)

Escalation

E1–E5

AI asks first
(5 patterns)

Adaptation

A1–A8

AI adjusts presentation
(8 patterns)

Enterprise

X1–X4

Organizational behavior
(4 patterns)

Total: 23 patterns. The Engine doesn't call them directly — it fires matching rules, and the result is a composed ui.command that corresponds to one or more pattern activations.

Composition example — "Silent Resolution"

The moment in the Yamashiro kitchen where a suggestion surfaces without Mai saying a word. Not a single pattern — a composition of four.

D4 · Omakase Mode D6 · Dynamic Friction E5 · Trust Breach Recovery A2 · Cognitive Scaling

D4 provides the "leave it to AI" skeleton. D6 adds friction for high-stakes moments — if the price exceeds the threshold, confirmation fires. E5 monitors whether Disclosure and Autonomy are logically consistent. A2 compresses density to minimal because Cognitive Load is high. The Engine folds all four into one ui.command.

In short: AX Pattern Library = parts catalog. Rule Engine = assembly factory. ui.command = the finished instruction. Add a new Pattern to the Library and the Engine picks it up automatically whenever a rule tagged with it fires — no changes to the Engine itself.

Explore all 23 AX Patterns →

Architecture

Why Rule Engine is the bridge

Brain holds memory. UI renders pixels. Without Rule Engine between them, both sides become tightly coupled — a maintenance nightmare every time a device changes.

Brain ↔ Rule Engine ↔ UI Surfaces

Imagine the world without Rule Engine: Brain would have to instruct the fridge directly — "put the egg photo at 240 px top right." Every new Samsung model, every screen-size change means rewriting the Brain. The Rule Engine absorbs all of that. Brain just says "suggest the lunch box" — and stays portable across every device that ever ships.

Q&A

Common questions answered

Q1. Is Rule Engine an AI (LLM)?

No. Rule Engine is a deterministic rule bundle — same input always produces the same output. An LLM produces different words for the same input every time (generative). In Context Grammar, the decision skeleton is Rule Engine; natural-language surface is LLM. "Suggest the egg & ham box" is the rule. "Oh, running short on time? Egg & ham?" is the LLM layer.

Q2. If same tokens always produce the same UI, won't it get repetitive?

The command is consistent — but Tokens change every second. Cognitive Load fluctuates with the clock and recent task volume. Form Factor shifts when you pick up your phone. The UI follows naturally. Repetitiveness is a sign that not enough Tokens are being read — if the person standing there is different, the time is different, those facts should already be in the Tokens.

Q3. What happens when multiple rules fire at the same time?

Non-conflicting rules all apply. "Cognitive Load=high → density:minimal" and "Social Exposure=public → hide:price" fire together — both are applied since they don't contradict. Conflicts go to the three-stage arbitration: Priority Weight Token first, then rule priority value, then Brain Learning Layer history. See Section F for the full conflict table.

Q4. What exactly is a ui.command — is it JSON?

An abstract structure. Implementation can be JSON, protobuf, or anything else. The important thing is that a shared vocabulary — intent / density / tone / candidates / constraints — is readable by every surface. Any new device (wall display, AR glasses, robot) can join without touching the Brain or Engine.

Q5. What is the difference between Rule Engine and the AX Pattern Library?

AX Patterns = blueprints. Rule Engine = assembly factory. The Library holds 23 blueprints — D1–D6 Delegation, E1–E5 Escalation, A1–A8 Adaptation, X1–X4 Enterprise. The Rule Engine decides which blueprints to select and how to compose them for the current Token state. Patterns are words; Rule Engine is grammar; the emitted ui.command is a sentence.

Q6. Does Rule Engine change between P1's single Brain and P4's five Brains?

No. The Engine only reads the synthesized Token set. In P1, one Context Brain assembles all 8 Tokens. In P4, five Brain types — Org, Brand × N, Research, Project Master, Project — each contribute facts to a Token Bus, which synthesizes the final Token set. The Engine sees "8 Token values are here" either way, and runs the same rules. That reuse is the point.

Eight tokens in. One command out.

An order-ticket system for your home

Rule Engine is a compiler

Read → Match → Emit

How a morning becomes a ui.command

One Engine — P1 single Brain or P4 five Brains

Rule syntax · schema · conflict resolution

Conflict resolution — what happens when rules contradict?

AX Pattern Library — 23 pieces the Engine assembles

Why Rule Engine is the bridge

Common questions answered

Now you know the logic layer.