RAAS — Rules + AI-as-a-Service

RAAS is SOCIII's rule engine — the part that decides what your worker is allowed to do, what it must always check, and how it composes constraints from multiple sources.

The architectural insight: business logic lives in rules, not prompts. AI models are interchangeable executors; rules are the IP. That's why a worker on SOCIII is portable across model providers (Claude, GPT, Gemini) — the rules are the same.

The five-tier hierarchy

Rules in SOCIII compose across five tiers, in order of precedence (lower tier wins on conflict, more-restrictive-rule wins on tie):

· Tier · Name · Owner · Update cadence · What it carries ·

· --- · --- · --- · --- · --- ·

· 0 · Platform Safety · SOCIII · Versioned · Universal invariants — no impersonation, no inventing citations, AI-disclosure, no PII exposure ·

· 1 · Platform Operations · SOCIII · Versioned · Subscription enforcement, role-based access, capability gating, append-only audit ·

· 2 · Vertical Baseline · SOCIII — regulatory ingestion service auto-updates · Auto, continuous + versioned · Per-industry regulations — HIPAA · FINRA · FAA · OFAC SDN · state DMV · GDPR — kept current automatically as laws change ·

· 3 · Workspace Overlay · You / your company — the Studio Locker · Manual, version-tracked · Company SOPs · brand voice · firm playbooks · hospital protocols · dealership procedures ·

· 4 · Per-Transaction Rules · You — per-transaction context · Per-event · Rules attached to a specific deal, escrow, policy, or work product ·

When your worker runs, the platform merges all five tiers into a single ordered ruleset before any AI call.

What this means in practice — the three things every regulated worker carries

A worker operating in a regulated space is, in effect, carrying three kinds of binding instruction at runtime:

1. The laws of its jurisdiction (Tier 2). Every law and regulation that applies to the worker's domain — HIPAA for healthcare, FINRA for finance, FAA for aviation, OFAC for sanctions, the state DMV's dealer rules — lives in Tier 2 and is kept current automatically by the platform's regulatory ingestion service. When OFAC adds a new SDN entry, when the FAA issues a new airworthiness directive, when a state legislature passes a new dealer-disclosure rule, the affected Tier 2 baseline updates and your worker picks up the new constraint on the next invocation. You don't re-author. You don't deploy. The law floor is the platform's responsibility, not yours.

2. Your company's policies and procedures (Tier 3, the Studio Locker). Below jurisdictional law sits company policy — your hospital's chest-pain pathway, your firm's investor-update template, your dealership's F&I product mix, your brand voice. These live in your workspace's Studio Locker, kept up-to-date by your team. The platform doesn't curate this — you do. But the platform merges Studio Locker rules into the runtime ruleset the same way it merges platform rules. This is the layer that lets two nursing-evaluation workers built for different hospitals enforce different protocols while sharing the same code.

3. The creator's professional expertise (across Tier 2 + Tier 3 authoring). The creator's craft — 30 years of tax-attorney experience, 20 years of ER-nursing pattern-recognition, 15,000 hours of pilot judgment — isn't a separate tier. It's what the creator *brings* to authoring rules in Tier 2 (when they contribute to a vertical baseline) and Tier 3 (when they encode company-specific overlays). The structural innovation isn't "professional expertise as a rule tier"; it's that the platform makes the creator's expertise *enforceable as composed rules* rather than fragile prompt instructions.

The order matters

Lower-numbered tiers always win. A creator can make a worker stricter than the law requires (Tier 3 adds beyond Tier 2), but cannot make it less strict than the law. A company SOP can be stricter than jurisdictional law, but not looser. The pre-publish constraint check enforces this before any action with external consequences executes.

This is why SOCIII workers are safe to ship in regulated verticals — the law floor is enforced by the platform, not by creator discipline.

Tier 0 — platform safety

Examples (you can't disable these):

Tier 1 — platform operations

Examples (you can't disable these either):

Tier 2 — vertical baselines (jurisdictional law)

The platform ships baselines per vertical, kept current by the regulatory ingestion service. A few examples:

Auto (state-augmented):

Real estate (state-augmented):

Healthcare (jurisdiction-aware):

Securities / finance:

Aviation:

When you author a worker, you opt into Tier 2 by setting vertical: and jurisdiction: in your catalog. The merger handles the rest.

Tier 3 — workspace overlays (the Studio Locker)

This is where your organization's policies and procedures live — between jurisdictional law (Tier 2, platform-maintained) and per-transaction rules (Tier 4).

Tier 3 rules are written by your team into the Studio Locker:

The Studio Locker is versioned, audited, and owned by your company, not by the platform. You add or update entries through your workspace; your workers reference them at runtime. This is the layer that lets two nursing-evaluation workers built for different hospitals enforce different protocols while sharing the same worker code.

Tier 3 can be stricter than Tier 2; it cannot be looser. Pre-publish enforcement guarantees this.

Tier 4 — per-transaction rules

Rules attached to a specific deal, escrow, policy, or work product — the most flexible tier, used when a single transaction needs constraints that don't apply to the worker globally.

Examples:

Tier 4 rules are attached at transaction initiation, version-pinned for the lifetime of the transaction (so the deal closes under the rules it started with), and audit-anchored alongside the transaction itself.

Your worker's rules — where they live across the tiers

Your domain expertise as a creator doesn't get its own tier. Instead, when you author a worker, your craft gets encoded across Tiers 2 and 3:

The format for an authored rule:

- id: medication-indication-check
  description: "Never recommend a medication outside its FDA-approved indication"
  enforce: hard          # hard | soft | advisory
  refuse_message: "That medication is not FDA-approved for this indication."

- id: serial-troponin-on-chest-pain
  description: "On chest pain inputs, order serial troponin q6h"
  enforce: soft          # AI is allowed to deviate with justification
  rationale: "Per ACS pathway v3, section 4.2"

- id: allergy-cross-check
  description: "Cross-check every order against patient.allergies"
  enforce: hard
  check: "patient.allergies INTERSECT order.medications == EMPTY"

enforce levels:

How rules compose at runtime

When your worker runs:

1. Platform loads Level 0 + Level 1 + your Level 2 baseline + your worker rules

2. Rules merge into a single ordered list (Level 0 first, your rules last)

3. AI call runs with the merged ruleset in its system prompt

4. Output is validated against hard rules before returning

5. Every rule-event (check, fire, refuse) appends to audit

You can see the merged ruleset for any worker in the Admin Worker Rules panel.

RAAS modules — regulatory updates (Layer 4)

For verticals with frequently-updating regulations (OFAC, FAA, FINRA, state DMVs, state real-estate boards), the platform ships RAAS modules that auto-update without requiring you to re-author your worker.

When OFAC publishes a new SDN entry, the SecuritiesCompliance RAAS module updates automatically. Your worker doesn't need a PR — it picks up the new constraint on the next invocation.

You opt your worker into RAAS modules via constraintRaasSources in your catalog. The platform maintains:

If you operate in a regulated space and the module doesn't exist yet, file a request — the regulatory ingestion service is designed to add jurisdictions incrementally.

Studio Locker — company SOPs (Layer 5)

The Studio Locker is where your organization's policies and procedures live — the layer between jurisdictional law (which the platform maintains) and your worker's domain rules (which you author).

Examples of what belongs in the Studio Locker:

The Studio Locker is versioned, audited, and owned by your company, not by the platform. You add or update entries through your workspace; your workers reference them at runtime.

This is the layer that lets two nursing-evaluation workers built for different hospitals enforce different protocols while sharing the same code.

Where the rules live in the repo

raas/
├── analyst/GLOBAL/        ← global analyst style guide
├── auto/IL/               ← Illinois auto dealer (Level 2)
├── auto/TX/               ← Texas auto dealer (Level 2)
├── real-estate/CA/        ← California real estate (Level 2)
├── real-estate/NV/        ← Nevada real estate (Level 2)
└── healthcare/GLOBAL/     ← healthcare baseline (Level 2)

Your worker references a Level 2 baseline by vertical/jurisdiction in catalog.json. The platform merges automatically.

What comes next

→ Intent Spec — declaring what your rules govern

→ QA-001 validator — how the validator checks rule enforcement

→ Worker anatomy — where rules sit in the file structure

← Back to all docs