LOOM — The Proof Layer of Execution

The Problem

Modern systems can:

• ✅ Authenticate users (WebAuthn, OAuth)
• ✅ Authorize actions (RBAC, ACL)
• ✅ Execute logic (APIs, services)
• ✅ Store logs (databases, log systems)

But they cannot answer one simple question:

“Can you prove this action actually happened — correctly, lawfully, and at the right moment?”

The Solution

Loom creates a verifiable execution object:

🧵 Thread (Writ)

Each Thread contains:

• who → identity (SoftID or any ID provider)
• what → intent
• when → validated moment (TPS / TickAuth)
• law → rules enforced
• how → execution path (AXIS / IDEL)
• result → output
• proof → signatures, capsules
• record → OpenLogs reference

👉 Not a log
👉 Not a request
👉 A proof of reality

How Loom Works

Intent declared
→ Identity signs (SoftID or any ID)
→ Time validated (TickAuth)
→ Law enforced (LIM)
→ Execution performed (AXIS)
→ Thread generated (Loom)
→ Stored (OpenLogs)

Every step is bound. Nothing is implicit.

⚖️ Comparison — Loom vs Existing Systems

Loom vs WebAuthn

Key Insight: WebAuthn proves who you are. Loom proves what actually happened.

Loom vs OAuth

Key Insight: OAuth grants permission. Loom verifies execution.

Loom vs APIs

Key Insight: APIs execute blindly. Loom executes lawfully and provably.

Loom vs Logs

Key Insight: Logs say “something happened”. Loom proves exactly what happened, why, and under which law.

The Mental Model

Before Loom:

Authenticate → Authorize → Execute → Log

After Loom:

Intent → Validate → Enforce Law → Execute → Prove → Record

The Thread (Writ)

A Thread is the core unit of Loom:

{
  "threadId": "thr_01...",
  "intent": "payment.transfer",
  "actor": "anchor_A",
  "tps": "TPS.y27.M09.W03.D07.H13",
  "laws": ["transfer.limit.v1"],
  "execution": "completed",
  "resultHash": "0xabc...",
  "proof": {
    "signature": "...",
    "capsuleId": "cps_..."
  }
}

👉 This is: verifiable, portable, auditable, and legally meaningful.

Needle & Thread Model

Loom introduces a new interaction model:

🪡 Needle

• carries intent
• initiates action

🧵 Thread

• binds result
• proves execution

No Needle → no Thread
No Thread → no reality

Built for High-Stakes Systems

Loom is designed for:

• financial approvals
• governance systems
• identity-critical operations
• AI-assisted execution
• cross-system workflows

AI-Safe Execution

AI cannot execute directly. With Loom:

• AI → proposes intent
• LIM → validates law
• Loom → produces proof

👉 No hallucinated actions
👉 No silent execution

Works Across Systems

Loom integrates with:

• SoftID (or any ID provider) → identity
• TickAuth → time validation
• LIM → law enforcement
• AXIS / IDEL → execution
• OpenLogs → storage
• Whisper / Field Protocol → transport

Why Engineers Choose Loom

• Deterministic execution proof
• Strong auditability
• Replay-resistant design
• Law-aware system behavior
• Cross-platform trust model
• Built for AI-native systems

What Loom Really Is

Loom is not an auth system, a logging system, or an API layer.

Loom is:

A proof engine for execution

The Shift

Before:

“The system says it happened.”

After:

“Here is the proof that it happened.”

LIM × Loom — The Relationship

LIM decides if something is allowed to happen.
Loom proves that it actually happened.

The Flow

Intent
→ LIM (validate & enforce law)
→ Execution (AXIS)
→ Loom (bind into Thread)
→ OpenLogs (store)

LIM — Before Execution

• Evaluates intent
• Enforces law
• Blocks or allows
• Decides outcome

→ "Should this happen?"

Loom — After Execution

• Binds all context
• Generates hash
• Signs proof
• Produces Thread (Writ)

→ "Prove that this happened."

Responsibility Split

The Bridge: Execution Result

LIM produces:

{
  validatedIntent,
  lawDecisions,
  executionResult,
  temporalContext
}

Loom consumes:

{
  intent,
  actor,
  time,
  lawDecisions,
  execution,
  result
}

Loom does not decide anything — it only binds and proves.

Critical Rule

Loom must NEVER validate or decide.
LIM must NEVER generate proof.
Mixing them breaks the system.

What Happens Without One?

LIM without Loom: system can execute but cannot prove anything.
→ "Trust me, it happened."

Loom without LIM: system can produce proofs but of possibly invalid actions.
→ "Here is proof of something that should never have happened."

Together: lawful execution + verifiable proof.

Data Evolution

Stage 1 — Intent:

{ "intent": "transfer", "amount": 100 }

Stage 2 — LIM Output:

{
  "allowed": true,
  "lawDecisions": [...],
  "execution": { "status": "completed" }
}

Stage 3 — Loom Output:

{
  "threadId": "thr_...",
  "intent": "...",
  "law": "...",
  "execution": "...",
  "proof": {
    "hash": "...",
    "signature": "..."
  }
}

Another Way to See It

LIM = Compiler — takes intent, validates rules, produces execution plan.

Loom = Notary + Hash Engine — seals the result, makes it immutable and portable.

The Big Shift

Traditional systems:

Auth → Execute → Log

With LIM + Loom:

Intent → LIM (Law) → Execute → Loom (Proof)

LIM defines reality. Loom proves reality.

LIM decides. Loom proves.

Get Started

npm i @nextera.one/loom-core

• Define an intent
• Validate it through LIM
• Execute via AXIS
• Generate Thread with Loom

Loom is where execution becomes reality.

License

Copyright © 2026 Nextera.One. Licensed under the Creative Commons Attribution 4.0 International License.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.