EVΛƎ Conscious Loop

Structure an AI decision before execution, and keep the reason as data.

E  Intent             what is being attempted
V  Possibility        what could be done
Λ  Decision Boundary  what is allowed, and why
Ǝ  Trace              what was decided, recorded as JSON

A small, model-agnostic TypeScript library. MIT licensed. No runtime dependencies.

Playground: https://evae-conscious-loop.vercel.app/playground · Source: https://github.com/HIROYOKOKI/evae-conscious-loop

Quick Start

Requires Node.js 18+. Install the library in your own app:

npm install evae-conscious-loop

Then save the example below as example.mjs and run node example.mjs. No API key is needed for this first run. The repository example can also run offline and write a trace JSON file.

Use it in your app

Save this as example.mjs in your app, then run node example.mjs:

import { evae } from "evae-conscious-loop";

const result = await evae.run({
  // E — Intent
  intent: {
    text: "Send payment request",
    context: { role: "staff", amount: 120000 },
  },

  // V — Possibility (most preferred first)
  possibilities: ["send automatically", "request human approval", "do not send"],

  // Λ — Decision Boundary
  boundary: {
    rules: [
      {
        id: "auto-send-limit",
        description: "Automatic sending is allowed only up to 100,000",
        appliesTo: ["send_automatically"],
        check: ({ intent }) =>
          Number(intent.context?.amount) <= 100000
            ? true
            : { pass: false, reason: "amount exceeds the automatic limit" },
      },
    ],
  },
});

console.log(result.decision); // "request_human_approval"
console.log(result.trace);    // Ǝ — JSON you can store anywhere

How a decision is made:

1. Possibilities are kept in preference order. String possibilities get an id ("send automatically" → send_automatically).
2. Every rule is evaluated against every possibility it applies to. A rule that throws does not pass.
3. The decision is the most preferred possibility that passes every applicable rule.
4. If nothing passes, decision is null.

Default is allow: a possibility with no applicable rules passes the boundary. Define rules for every consequential option. A decision here does not grant execution authority; your application remains responsible for what happens next.

The loop decides; it does not act. Executing (or not executing) the decision is up to your application.

Let a model propose the possibilities

import { evae, fromModel, anthropic } from "evae-conscious-loop";

const result = await evae.run({
  intent: "Send this quote email to the client automatically",
  possibilities: fromModel(anthropic(), {
    choices: ["send", "ask_human", "hold"],
  }),
  boundary: { rules: [/* ... */] },
});

The model proposes and ranks; it may only use the ids you allow, so your boundary rules stay stable. Invented ids are dropped.

Model adapters

The core never calls a model directly. Any model works through one interface:

interface ModelAdapter {
  name: string;
  complete(req: { system: string; prompt: string }): Promise<string>;
}

Included in v0.1 (fetch-based, no SDKs):

| Adapter | Covers | | --- | --- | | anthropic() | Anthropic Messages API | | openai({ baseUrl }) | OpenAI and any OpenAI-compatible server, including local models (Ollama, LM Studio, vLLM) | | mockModel(text) | Offline tests and demos |

Gemini or anything else: implement complete() — about 20 lines.

Trace schema (v0.1)

{
  "trace_id": "uuid",
  "timestamp": "ISO 8601, UTC",
  "intent": "Send this quote email to the client automatically",
  "intent_context": { "sender_role": "assistant", "approver_on_duty": false },
  "possibilities": [
    { "id": "send", "label": "Send now", "description": "..." },
    { "id": "ask_human", "label": "Ask a human" },
    { "id": "hold", "label": "Hold" }
  ],
  "decision_boundary": {
    "rules": [{ "id": "external-send-authority", "description": "...", "applies_to": ["send"] }],
    "evaluations": [{ "possibility": "send", "rule": "external-send-authority", "pass": false, "reason": "..." }],
    "within": ["hold"]
  },
  "decision": "hold",
  "reason": "...",
  "metadata": {
    "schema_version": "0.1",
    "library": "[email protected]",
    "possibility_source": "model:anthropic/claude-sonnet-4-6",
    "duration_ms": 812
  }
}

Extending the trace: hash, signature, audit chain

v0.1 does not sign or hash traces. It is designed so you can add that without changing the schema:

• integrity is a reserved, optional field (not set by v0.1 core).
• canonicalize(trace) gives deterministic JSON (sorted keys), so the same trace always hashes the same way.
• Trace hooks run after each trace is built and can add anything to integrity.

import { createHash } from "node:crypto";
import { createLoop, canonicalize } from "evae-conscious-loop";

let previous: string | null = null;

const loop = createLoop({
  hooks: [
    (trace) => {
      const hash = createHash("sha256").update(canonicalize(trace)).digest("hex");
      const chained = { ...trace, integrity: { alg: "sha256", hash, prev: previous } };
      previous = hash;
      return chained;
    },
  ],
});

Repository layout

packages/conscious-loop/   the library (evae-conscious-loop)
  src/intent.ts            E  Intent
  src/possibility.ts       V  Possibility
  src/boundary.ts          Λ  Decision Boundary
  src/trace.ts             Ǝ  Trace
  src/loop.ts              E → V → Λ → Ǝ
  src/adapters/            model adapters
  test/
examples/basic/            runnable example
app/playground/            Developer Playground (uses the library)
app/demo/                  Reference Demo (concept screens, fixed data)

npm test          # library tests
npm run example   # run examples/basic
npm run dev       # playground + reference demo at http://localhost:3000

Open source scope

Included — MIT

• Conscious Loop (Ec → Vc → Λc → Ǝc)
• E / V / Λ / Ǝ interfaces
• Trace schema
• Basic Decision Boundary interface
• Reference implementation
• Playground, demo, examples

Not included

• Action Loop
• Runtime enforcement
• EXECUTE / HOLD / BLOCK enforcement engine
• Enterprise approval workflow
• Production thresholds
• Enterprise policy engine
• EVΛƎ ARMOR commercial components

These are part of the commercial EVΛƎ runtime (private).

The Action Loop exists as a separate commercial runtime layer and is intentionally not disclosed in this open-source repository.

The Action Loop is the commercial runtime layer that carries an approved decision toward controlled execution, while preserving authority, enforcement, and traceability.

The Conscious Loop is complete on its own: it produces a decision and a trace you can store and audit. Enforcing that decision at runtime, across systems and teams, is where the commercial components come in.

Patent pending and commercial use

Patent pending. The EVΛƎ Framework and related architecture are subject to pending patent applications.

The software contained in this repository — EVΛƎ Conscious Loop v0.1 — is released under the MIT License. Commercial use of this MIT-licensed code is permitted under the terms of that license.

The MIT-licensed repository does not include access to proprietary EVΛƎ commercial components, including:

• Action Loop
• Runtime enforcement and the EXECUTE / HOLD / BLOCK enforcement engine
• EVΛƎ ARMOR
• Enterprise approval workflows
• Production thresholds and enterprise policy engine
• Enterprise integration, support, and certification services

Use of those proprietary components or services requires a separate commercial agreement with Amuletplus G.K.

EVΛƎ is a registered trademark in Japan in Classes 16, 25, and 42. Use of the EVΛƎ name, logos, or claims of certification, endorsement, or official partnership is separate from the MIT-licensed software and may require permission from Amuletplus G.K.

This notice does not modify the terms of the MIT License.

About

EVΛƎ (Eva) — Design-by-Transparency for AI.

Created by Hiro Yokoki, Founder, Amuletplus G.K. (Tokyo). For collaboration or commercial inquiries, connect via LinkedIn.

MIT License.

v0.2 — Explicit authorization at Λ

Capability ≠ Authority.

EVΛƎ v0.2 adds an explicit pre-execution authorization decision without turning the library into an execution or sandboxing system.

import { evaluateDecision } from "evae-conscious-loop";

const result = await evaluateDecision({
  intent: "Send payment",
  possibilities: ["send payment", "ask human", "stop"],
  policy: {
    id: "payments",
    version: "1.0",
    rules: [
      {
        id: "payment-approval",
        description: "Payment requires approval evidence",
        appliesTo: ["send_payment"],
        check: ({ intent, possibility }) => ({
          decision: "HOLD",
          reason: "Approval evidence is missing",
          requirements: ["human_approval"],
        }),
      },
    ],
  },
  decisionContext: {
    authority: { actor: "agent", scope: "draft-only" },
    evidence: { approval_id: null },
  },
});

console.log(result.decision); // "HOLD"
console.log(result.requirements); // ["human_approval"]

Decision semantics

• EXECUTE — the selected possibility is authorized for downstream execution.
• HOLD — the possibility is not prohibited, but authority, evidence, confidence, or human review is incomplete.
• BLOCK — the possibility is explicitly outside the permitted decision boundary.

Rules fail closed: a rule error becomes BLOCK by default. A rule may explicitly set onError: "HOLD" only when that uncertainty is safe to route to review. If no rule applies, the default is HOLD, not EXECUTE.

Responsibility boundary

EVΛƎ decides whether a possibility should become an authorized action and records why. It does not execute the action, sandbox the agent, restrict networks/filesystems, or provide hardware/runtime enforcement. Those controls belong downstream and can consume the EVΛƎ decision.

EVΛƎ decides. Enforcement systems enforce. Ǝ traces.

Authorization handoff contract

For downstream enforcement, authorization records the policy id/version, canonical subject binding, issue time, optional expiry, all candidate outcomes, authority/evidence context, and requirements. An enforcement layer should execute only when authorization.status === "EXECUTE", trace.decision matches the intended possibility, the policy id/version is the expected version, the authorization is unexpired, and the action reconstructed by the enforcer matches the recorded subject. For production policies, set a short ttlMs; an authorization without expires_at should not be treated as indefinitely reusable.

Preference semantics are deliberate: the first non-BLOCK possibility wins. Therefore a preferred HOLD is not silently bypassed by a later EXECUTE candidate; the caller must resolve or replace the held possibility explicitly.

Patent status

The EVΛƎ Framework is the subject of Japanese Patent Application No. 2025-160873, filed on September 28, 2025.

This notice identifies the patent-pending status of the underlying EVΛƎ Framework. It does not state that every component, API, or implementation in this open-source package is independently covered by the pending application.

Fail-closed invariant

EXECUTE can only be produced when at least one applicable rule is evaluated and the applicable rule set resolves to EXECUTE. Missing rules never imply permission. defaultDecision and rule-error fallbacks accept only HOLD or BLOCK; unsafe runtime values are rejected.

Legacy run() traces retain schema 0.1. In v0.2 authorization traces, decision_boundary.within describes candidates whose rules resolve to EXECUTE, while trace.decision is populated only when the selected preferred candidate itself is authorized for execution. A preferred HOLD is therefore allowed to coexist with later executable candidates in within.

If possibility generation throws (including a model/source failure), evaluateDecision() rejects and produces no EXECUTE authorization. Callers must treat that failure as non-executable.