Build governed AI
with O-Lang

The JS kernel is the runtime — stable, production-ready, and language-agnostic. Tools are separate npm (or pip) packages you install and declare in your workflow.

npm install @o-lang/olang
npm install @o-lang/llm-groq
npm install @o-lang/bank-account-lookup

Create my-workflow.ol. The Allow resolvers: block is your governance contract — only listed tools can execute.

Workflow "Balance Check" with customer_id, user_question

Allow resolvers:
  - @o-lang/bank-account-lookup
  - @o-lang/llm-groq

Step 1: Ask @o-lang/bank-account-lookup "{customer_id}"
Save as account_info

Step 2: Ask @o-lang/llm-groq "{user_question}. Balance: {account_info.balance}"
Save as response

Return response

Pass inputs and receive a governed response with a full cryptographic audit trail.

const { runWorkflow } = require('@o-lang/olang');

const result = await runWorkflow('my-workflow.ol', {
  customer_id:   'CUST-001',
  user_question: 'What is my current balance?'
});

console.log(result.response);
// → "Your current balance is $12,450.00."

console.log(result.audit.execution_hash);
// → sha3:a3f8c2d1...  (cryptographic proof of execution)

Anatomy of a resolver

Every resolver exports a declaration (what it is and what it can do) and a resolve function (the actual logic).

const declaration = {
  name:    "@my-org/my-tool",
  version: "1.0.0",
  input: {
    type: "object",
    properties: {
      id: { type: "string", description: "Record ID to look up" }
    },
    required: ["id"]
  },
  output: {
    type: "object",
    properties: {
      result: { type: "string" },
      found:  { type: "boolean" }
    }
  },
  properties: {
    deterministic: true,    // same input → same output
    sideEffects:   false,   // read-only
    requiresAuth:  false
  }
};

async function resolve(input) {
  const record = await db.find(input.id);
  return { result: record.value, found: !!record };
}

module.exports = { declaration, resolve };

Declaration fields

Testing your resolver

const myTool = require('./index');

// Verify declaration shape
console.assert(myTool.declaration.name, 'name required');
console.assert(typeof myTool.resolve === 'function', 'resolve must be a function');

// Test the resolver
const result = await myTool.resolve({ id: 'test-001' });
console.log(result);
// → { result: "...", found: true }

Conformance test suite (R-005 → R-012)

Every O-Lang resolver — in any language — must pass 8 conformance tests before it can be used in production or listed in the registry. The tests are JSON-defined and language-neutral: the runner adapts, the contract does not.

Run olang-test --json (Python) or npx olang-test --json (Node.js). A passing run generates badge.txt — the O-Lang CERTIFIED confirmation required before registry submission.

Tool allowlists

The most fundamental governance primitive. If a tool is not listed, any step that tries to call it is rejected — even if injected via prompt manipulation.

Allow resolvers:
  - @o-lang/bank-account-lookup   # approved: read-only DB access
  - @o-lang/llm-groq              # approved: LLM inference

# These would be REJECTED at runtime — even if a step tried to call them:
# - @o-lang/send-email
# - @o-lang/modify-balance
# - any tool not in this list

Intent scope and prohibited actions

Declare the semantic scope and the actions the workflow must never perform. The kernel catches violations in the user query before any tool is called.

Prohibit actions:
  - transfer_funds
  - modify_balance
  - speculative_balance

Intent scope: "balance_inquiry_only"

Output safety policy

The kernel inspects LLM outputs before returning them. Built-in rules block responses that contain speculative data, PII, or content outside the declared scope.

Execution pipeline

Audit chain format

Every execution produces a linked hash chain. Each entry has a previousHash pointing to the prior block, making the chain tamper-evident. A merkle root covers all entries.

{
  "execution_hash":          "sha3:a3f8c2d1e9b4...",
  "previous_hash":           "sha3:0000000000...",   // GENESIS on first run
  "governance_profile_hash": "sha256:7c2a1f...",
  "kernel_version":          "1.2.15-alpha",
  "merkle_root":             "sha256:4d9e8a...",
  "signature":               "ed25519:...",          // if key configured
  "integrity": {
    "valid":        true,
    "totalEntries": 2
  }
}

Context isolation

Each workflow execution runs in an isolated context. Variables saved with Save as are scoped to the execution and cannot bleed between concurrent runs. The kernel enforces this at the runtime level — it is not a convention.