Architecture
How OCC is structured, why it works, and how to retrofit it.
System Diagram
┌─────────────────────────────────────────────────────────────────┐
│                        OCC SYSTEM                               │
│                                                                 │
│   ANY INPUT SURFACE          TOP_AGENT / ROUTER                 │
│   ┌───────────┐              ┌─────────────────────────┐        │
│   │  UI input │              │  ONE ENTRY              │        │
│   │  API call │  ──char──►   │  validate input         │        │
│   │  Voice    │              │  lookup occ_commands    │        │
│   │  Hardware │              │  ONE RETURN             │        │
│   └───────────┘              └──────────┬──────────────┘        │
│                                         │                       │
│                              ┌──────────▼──────────────┐        │
│                              │  occ_commands (registry)│        │
│                              │  code_char  CHAR(1) UNIQUE       │
│                              │  command_name           │        │
│                              │  target_type            │        │
│                              │  target_value    LOCKED │        │
│                              │  is_active       WHEN   │        │
│                              │  requires_login  STABLE │        │
│                              └──────────┬──────────────┘        │
│                                         │                       │
│              ┌──────────────────────────┴────────────────┐      │
│              │          SEGMENTED DATA STRAINS            │      │
│              │                                            │      │
│    ┌─────────▼───────┐    ┌────────────────┐             │      │
│    │  occ_logs        │    │  occ_commands  │             │      │
│    │  (audit trail)   │    │  (registry)    │             │      │
│    │  every execution │    │  source of     │             │      │
│    │  time + IP + ms  │    │  truth         │             │      │
│    └──────────────────┘    └────────────────┘             │      │
│                                                            │      │
│    Strains are separated — logs never modify commands.    │      │
│    Each table has one job.                                 │      │
└────────────────────────────────────────────────────────────┘      │
Core Principles
Every principle has a reason. None are optional.
01

One Entry / One Return

Every OCC execution enters through a single endpoint and returns a single structured response. No branching entry points. No partial returns. The router either succeeds completely or fails completely.

02

Segmented Data Strains

The command registry (occ_commands) and the execution log (occ_logs) are separate tables with separate jobs. Registry data is never modified by execution. Logs never alter commands. Cross-contamination is structurally impossible.

03

Retrofit Repair

OCC does not require rebuilding your existing system. It wraps at the interface layer. You assign OCC codes to existing commands, paths, or functions. The underlying system is untouched. Retrofit first, rebuild never.

04

Lock When Stable

Once a command is proven in production, it locks. Code 'H' always means Help. Code 'L' always means Login. Reassigning live codes is a system failure, not a feature. Stability is the product.

05

Monitoring / Self-Heal

Every execution logs elapsed_ms, result_status, and IP. Anomalies surface in the log before users notice them. The system can detect pattern deviations and trigger repair without human intervention.

06

36-Slot Hard Limit

The registry holds exactly 36 possible codes. This is not a bug to fix — it's a forcing function for priority. If you need more than 36 top-level commands, the commands are the problem, not the limit.

Execution Flow
INPUT: single char  "H"
         │
         ▼
┌─────────────────────────────────┐
│  VALIDATE                       │
│  strlen == 1 && ctype_alnum     │
│  → uppercase normalize          │
└──────────────┬──────────────────┘
               │ PASS         FAIL ──► {status:"error", elapsed_ms}
               ▼
┌─────────────────────────────────┐
│  REGISTRY LOOKUP                │
│  SELECT * FROM occ_commands     │
│  WHERE code_char = 'H' LIMIT 1  │
└──────────────┬──────────────────┘
               │ FOUND        NOT FOUND ──► log + {status:"not_found"}
               ▼
┌─────────────────────────────────┐
│  ACTIVE CHECK                   │
│  is_active == 1 ?               │
└──────────────┬──────────────────┘
               │ YES          NO ──► log + {status:"not_found", "Command is disabled"}
               ▼
┌─────────────────────────────────┐
│  LOG EXECUTION                  │
│  INSERT INTO occ_logs           │
│  (code_char, command_name,      │
│   result_status, elapsed_ms,    │
│   ip_address)                   │
└──────────────┬──────────────────┘
               │
               ▼
OUTPUT: {
  status: "ok",
  code: "H",
  command: "Help",
  description: "YourIQ Help Center",
  target_type: "url",
  target_value: "/help",
  elapsed_ms: 1
}
The Retrofit Pattern
Drop OCC into any existing system in 3 steps.
1

Map existing commands

Audit your top 36 most-used commands, paths, or actions. Assign each a single character. This is the design work — do it once.

2

Insert the registry table

Run occ_schema.sql against your database. Two tables, one INSERT per command. The existing system is not modified.

3

Wire the execute endpoint

Deploy execute.php (or its equivalent) at any accessible URL. Point your interface at it. The retrofit is complete.

Live System Status
Engine youriq.ai/api/occ/execute.php
Registry ghwerkerhy · occ_commands
Log table ghwerkerhy · occ_logs
CORS Access-Control-Allow-Origin: *
Engine ping checking…
Last H execution
One Character Code is live on YourIQ.AI
and demonstrated publicly on OneCharacterCode.com.
The engine runs. The registry is populated. Every code executes in under 2ms server-side. The proof is not a demo — it is the production system.
Live Board → Benchmark Data →