How It Works

RARS is a symbiosis of the reasoning capabilities of probabilistic AI (LLMs) and a symbolic programming runtime assembled from your codified operating model. Think of it as a coding AI for the business itself: a resident AI that writes code against your business runtime the way Cursor or Copilot writes code against your application runtime.

This page walks through how the system actually works. Each section links to detailed architectural documentation.

Your Business as a Programmable Runtime

Your organization's knowledge is codified into formal specifications called matrices. A matrix is a complete, versioned operating model for a specific business domain. HR, finance, procurement, project management, whatever your organization does.

Matrices are composable. When you install them into a workspace, they merge into what we call the global matrix, a single unified "code repository" that RARS has access to. RARS doesn't see HR and finance as separate tools. It sees one connected operating model where a project's budget comes from the finance matrix, its team members come from HR, and its deliverables are tracked in project management.

This composition follows a holarchical structure. Each matrix is both a complete, self-contained whole and a part of a larger whole. Your workspace becomes a global operating model assembled from composable parts, and your organizational architecture adapts to the model rather than the other way around.

The NeuroSymbolic Engine

RARS is not a collection of autonomous agents passing messages between each other. It is one resident AI, constructed dynamically from the matrices installed in your workspace. Matrices are activated just-in-time. As the work requires new domains, RARS activates the relevant matrices on demand, loading their logic and integrating them into its reasoning.

Execution is powered by a NeuroSymbolic AI engine with two integrated layers:

• The probabilistic layer (LLM reasoning) understands natural language, makes judgment calls, plans multi-step approaches, and adapts when things change.
• The symbolic layer (your operating system) runs deterministic workflows against your operating model, dispatches actions based on type hierarchies, enforces validation, and tracks provenance.

These layers are interleaved within the same execution loop. RARS reasons, plans, programs, and executes. The results feed back into context, and it reasons again. The AI doesn't call tools or react step-by-step. It writes and executes programs of interdependent stages against your codified business model.

Deterministic orchestration

The fundamental problem with AI workflows is the ReAct loop: reason, act, observe, reason again. Every step is a fresh inference. Multi-step plans drift. The execution is as non-deterministic as the reasoning.

RARS introduces ProActive AI: your AI manipulates your business through a concept-oriented programming runtime where your domain objects have types, behaviors, and inheritance hierarchies, just like classes in OOP. Actions are methods on concepts. The symbolic engine executes workflows deterministically against this typed graph. The plan runs as written, not re-inferred at each step.

Within a single script, deterministic API calls, AI reasoning steps, and human approvals compose into one executable plan with aligned I/O contracts:

CONSTRUCT {
    ?workOrder  wo:status      ?status ;
                wo:priority    ?priority ;
                wo:approvedBy  ?approver .
}
WHERE {
    # Read a workorder from the existing runtime state
    ?workOrder a wo:WorkOrder ;
               wo:workOrderId "WO-2024-0891" .

    # Invoke an agentic AI action to assess risk
    ?assessment wo:AssessRisk (?workOrder) .

    ?assessment wo:priority ?priority .

    # Pause for human approval
    ?approval wo:RequestApproval (
        ?workOrder
        wo:assessment ?assessment
    ) .
    ?approval wo:approvedBy ?approver .

    # Mutate an external system
    ?dispatch wo:DispatchWorkOrder (
        ?workOrder
        wo:approval ?approval
        wo:priority ?priority
    ) .

    # Select the updated status
    ?workOrder wo:status ?status .
}

Every action has an explicit I/O contract validated against your business constraints. A deterministic service call and an agentic reasoning task are held to the same validation. This is Contractual AI. The contract guarantees the output structure regardless of how the result was produced.

Verifiable State

Where AI has had the biggest impact is software engineering. We think this is because software has version control. When you use AI to code, you don't go through the traces and reasoning processes of the AI step by step. You look at the diff.

RARS exposes a diff for your business objects. After a session runs, the changes RARS made to your operating resources (contracts, project management issues, budgets, accounting statements) are surfaced as a structured, reviewable diff with per-statement provenance for every addition and retraction:

  po:PO-2024-0891 a po:Procurement ;
-      po:status po:PendingReview ;
+      po:status po:Approved ;
+      po:approvedBy <urn:users:123> ;
+      po:approvedAt "2025-03-28T14:22:03Z" ;
+      po:value "340000.00"^^xsd:decimal .

No more reviewing full traces, evals, and reasoning chains. Our native observability system still provides those if you need them.

Learn more: Persistent Memory | Provenance

Shared State, Not Message Passing

Every actor in a context (human, AI, or external system) operates on the same knowledge graph through a collaborative runtime. Alignment across domains isn't coordinated through middleware or meetings. It is structural.

Everything is a structured observation: an attestation made by a specific agent, as part of a specific process. When an autonomous actor updates a record, a service syncs external data, or a human approves a change, they're all contributing observations to the same shared state. No actor operates in isolation. No data exists without attribution.

Every change, down to the individual field, carries a complete chain of attribution. Who changed it, why, when, and as part of what process. That's not a forensic investigation. It's a direct lookup:

SELECT ?actor ?process ?origin WHERE {
  ?obs a rars-os:Observation ;
       rars-os:attests << po:PO-2024-0891 po:status po:Approved >> .
       rars-os:accordingTo ?actor ;
       rars-os:recordedIn ?process .

  ?process rars-os:authContext/rars-iam:origin ?origin .
}

Persistent memory

RARS maintains a dual-context architecture that separates the LLM's prompt context from the persistent knowledge graph. The graph serves as long-term memory that the AI can query at any point, giving it gigabytes worth of context without being limited by the token window.

Data sovereignty

Your context data lives in your context. Poliglot's serverless isolation model ensures workloads are isolated at every level: your data doesn't leak to other contexts, workspaces, or tenants.

Trust and Control

AI operating systems break traditional access control assumptions. A single user request can trigger operations across domains, agent identities, and systems of record. RARS addresses this with three architectural decisions.

Identity

Every actor in the system (human users, RARS itself, matrix-provided agents) has a formal identity. Delegation chains track exactly who initiated what and through which path.

Situational access control

Static role-based access control is dangerous for AI. A role grants permissions unconditionally, regardless of whether the business context supports the action. RARS enforces situational access control, where permissions evaluate the live state of the business at the moment of execution.

Say an autonomous actor tries to dispatch a $250,000 electrical work order. At execution time, the system checks whether the risk assessment has been completed, whether a licensed electrical engineer has signed off, whether the project budget covers it, and whether a manager with the appropriate authority has approved it. If any condition isn't met, the operation is denied, regardless of the agent's role.

po:ProcurementManagerPolicy
  a rars-iam:IdentityPolicy ;
  rars-iam:effect rars-iam:Allow ;
  rars-iam:action rars-act:InvokeAction ;
  rars-iam:resource po:ApproveProcurement ;

  # direct invocation only
  rars-iam:condition [
    rars-iam:scope rars-iam:AuthorizationContext ;
    rars-iam:onProperty rars-iam:delegationDepth ;
    rars-iam:hasValue 1
  ] ;

  # ops prerequisites on the subject
  rars-iam:condition [
    rars-iam:scope rars-os:Process ;
    rars-iam:sparql [
      rars-os:ask """
        ASK {
          ?scope rars-os:parent ?inv .
          ?inv rars-act:subject ?order .

          ?order po:riskAssessment/po:status po:Completed .
          ?order po:engineerSignOff/po:status po:Completed .
          ?order po:value ?v .
          FILTER(?v <= 500000)
        }
      """
    ]
  ] .

The runtime evaluates all policy conditions against the live business state:

Contractual AI

Every action has an explicit input/output contract. AI output is validated against the same schema as a direct API response. Combined with deterministic plan execution, this replaces the step-by-step ReAct loop with a model where the AI plans a complete workflow and the symbolic engine executes it with formal guarantees. Learn more in Contractual AI.

Key Concepts

Foundational concepts used throughout the documentation:

• Workspace: an organizational environment where matrices are installed and your team collaborates.
• Context: a persistent working environment where RARS operates. You have information in front of you, you know which systems to use, you remember what happened before, and you pick up where you left off.
• Matrix: a codified operating model for a business domain. Defines the domain's concepts, rules, operations, and systems of record. Versioned, composable, installable.
• Action: a declared operation RARS can execute. Can be a deterministic API call, an orchestrated multi-step workflow, an AI reasoning task, or a human approval. All share the same verifiable I/O contract.
• Observation: every piece of data from your operations state, and every change RARS makes is recorded as an observation with full provenance: who, what, when, and why, and as part of which process. Your entire business becomes auditable through a unified system.