ONAIA Ontology Harmonizer

A multi-sampled LLM-driven system for harmonizing furniture manufacturer ontologies using DAG-based architecture for reliable schema mapping.

Overview

ONAIA (Ontology Normalizer and Alignment Intelligence Agent) helps furniture manufacturers consolidate disparate product data schemas into a unified master ontology. It uses:

• Multi-Sampled Inference: Adaptive sampling with consensus calculation for reliable mappings
• Multi-Sheet Excel Support: Automatic sheet classification, join detection, and cross-sheet resolution for complex workbooks
• DAG Architecture: Based on Directively Attuned Gestalts (The Librarian, Index Cards, Library)
• Semantic Search: pgvector embeddings for intelligent field matching
• Human-in-the-Loop: Review interface for uncertain mappings (grouped by sheet for multi-tab files)

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                    Lovable Frontend                              │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────┐ │
│  │ File Upload  │ │ Mapping      │ │ Chat with The Librarian  │ │
│  │              │ │ Review       │ │                          │ │
│  └──────────────┘ └──────────────┘ └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼ Webhooks (X-Api-Key, X-Webhook-Secret)
┌─────────────────────────────────────────────────────────────────┐
│                    Azure Backend                                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │  FastAPI (API)          │  Worker (standalone process)   │   │
│  │  /auth/azure  /admin    │  Polls DB for pending jobs,     │   │
│  │  /webhook/upload chat   │  runs process_mapping_job       │   │
│  │  /jobs /ontology        │  (decoupled from API restart)  │   │
│  └──────────────────────────────────────────────────────────┘   │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              Multi-Sample Orchestrator                     │   │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  → Bayesian + Vote │   │
│  │  │Sample 1 │  │Sample 2 │  │Sample N │    Consensus       │   │
│  │  └─────────┘  └─────────┘  └─────────┘                    │   │
│  └──────────────────────────────────────────────────────────┘   │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │  DAG: Librarian │ Index Cards │ Library (RAG) + Ledger    │   │
│  └──────────────────────────────────────────────────────────┘   │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ ┌────────┐ │
│  │ PostgreSQL  │ │ Redis      │ │ Azure OpenAI    │ │ Blob   │ │
│  │ + pgvector  │ │ (cache)    │ │ Multi-model     │ │ Storage│ │
│  └─────────────┘ └─────────────┘ └─────────────────┘ └────────┘ │
└─────────────────────────────────────────────────────────────────┘

Quick Start

Prerequisites

• Python 3.11+
• Docker & Docker Compose
• Azure OpenAI API access
• (Optional) Azure account for cloud deployment

Local Development

1. Clone and setup: bash cd backend cp .env.example .env # Edit .env: Azure OpenAI, DATABASE_URL, optional API_KEY / WEBHOOK_SECRET. # For local dev without auth, set SKIP_AUTH=true.

2. Start services (API + Worker + Postgres + Redis): bash docker-compose up -d The API serves HTTP; the worker process polls for pending mapping jobs. Both use the same image with different commands.

3. Run migrations: bash pip install -r requirements.txt alembic upgrade head

4. Seed ontology: bash python -m app.scripts.seed_ontology

5. Access API: - API: http://localhost:8000 - Swagger: http://localhost:8000/docs

6. Frontend (optional): bash cd frontend cp .env.example .env # Edit .env: VITE_API_URL=http://localhost:8000, VITE_AZURE_AD_CLIENT_ID=..., VITE_AZURE_AD_TENANT_ID=... npm install && npm run dev Open http://localhost:5173. Sign in with Microsoft (requires SEED_SYS_ADMIN_OID set in backend for first user). - Docs: http://localhost:8000/docs - Health: http://localhost:8000/health (live DB + OpenAI check; append ?deep=true for model parameter probe) - Adminer: http://localhost:8080 (use docker-compose --profile tools up)

Authentication and configuration

• Auth: Browser clients use Microsoft sign-in (Azure AD) → POST /api/v1/auth/azure → JWT; send Authorization: Bearer <token> on requests. Set AZURE_AD_TENANT_ID, AZURE_AD_CLIENT_ID, JWT_SECRET, and optionally SEED_SYS_ADMIN_OID in env.
• API key: Set API_KEY in env; server-to-server clients send X-Api-Key. Maps to Legacy company.
• Webhook secret: Set WEBHOOK_SECRET; upload/chat webhooks expect X-Webhook-Secret. Use SKIP_AUTH=true only for local dev without secrets.
• Rate limits: Upload and chat endpoints are rate-limited (configurable via RATE_LIMIT_UPLOADS, RATE_LIMIT_CHAT).
• All settings and env vars are listed in backend/.env.example and backend/app/config.py.

API Endpoints

Webhook Contract

Upload Request:

{
  "fileName": "catalog.csv",
  "fileContent": "<base64>",
  "fileType": "csv",
  "callbackUrl": "https://your-app.com/callback",
  "userId": "user_123"
}

Results Callback:

{
  "jobId": "uuid",
  "status": "review_required",
  "mappings": [
    {
      "sourceColumn": "Material_Type",
      "targetField": "material.type",
      "confidence": 0.92,
      "consensusType": "unanimous",
      "requiresReview": false
    }
  ],
  "summary": {
    "totalColumns": 25,
    "autoMapped": 18,
    "reviewRequired": 5,
    "unmapped": 2
  }
}

Azure Deployment

Infrastructure is defined in Bicep and deployed via PowerShell or CI/CD.

• Full deployment (infra + build + push + migrations + seed): powershell cd infrastructure .\deploy-full.ps1 -Environment dev -ResourceGroup onaia-dev-rg -RunMigrations -SeedOntology
• Infrastructure only (then build/push separately): powershell .\deploy.ps1 -Environment dev -ResourceGroup onaia-dev-rg

The Bicep template provisions: PostgreSQL (pgvector), Azure OpenAI, Storage, Azure Cache for Redis, Container Registry, API and Worker Container Apps, Key Vault, Log Analytics, Application Insights. Both API and Worker receive DATABASE_URL, REDIS_URL, AZURE_OPENAI_*, API_KEY, WEBHOOK_SECRET, and tuning env vars.

See infrastructure/README.md for parameter files, Key Vault references, and Redis SKU (Basic C0 dev / Standard C1 prod). CI/CD (.github/workflows/deploy.yml) runs tests, type check, builds and pushes both onaia-api and onaia-worker images, and updates both Container Apps.

Master Ontology

The furniture domain ontology includes:

Multi-Sampling and Consensus

Adaptive sampling (based on initial semantic confidence):

• High confidence (>85%): 3 samples
• Medium (60-85%): 5 samples
• Low (40-60%): 7 samples
• Very low (<40%): up to 9 samples + human flag

Consensus: Hybrid Bayesian + voting. The prior comes from pgvector similarity; likelihood from LLM votes (noisy voter model with confidence weighting); posterior picks the winner. Vote-based consensus type (unanimous / strong_majority / simple_majority / plurality / divergent) is always computed as a diagnostic. Tunables: BAYESIAN_PRIOR_TAU, BAYESIAN_DAMPENING (see backend/.env.example and backend/prompts/components/consensus_types.yaml).

Project Structure

ONAIA/
├── backend/
│   ├── app/
│   │   ├── api/routes/        # FastAPI endpoints (webhooks, jobs, ontology, mappings, chat, consolidation)
│   │   ├── core/
│   │   │   ├── dag/           # DAG components (Librarian, Library, Index Cards)
│   │   │   ├── inference/     # Multi-sampling, consensus (Bayesian + voting), document structure discovery
│   │   │   └── parsers/       # CSV/Excel parse and profile (multi-sheet support)
│   │   ├── db/                # Models, session, init_db, recover_stale_jobs
│   │   ├── mcp/               # Headless MCP server (FastMCP) — product search tools for agent integration
│   │   ├── services/          # Azure OpenAI (multi-model), Blob, embeddings, cache, transformation, validation, reconciliation
│   │   ├── scripts/           # seed_ontology, reembed_all
│   │   └── worker.py          # Standalone job worker (python -m app.worker)
│   ├── tests/                 # pytest (parse_spreadsheet, consensus, webhook)
│   ├── alembic/               # Migrations
│   ├── .dockerignore
│   ├── .env.example           # All env vars documented
│   ├── Dockerfile
│   └── docker-compose.yml     # API, worker, postgres, redis
├── infrastructure/
│   ├── main.bicep             # Azure IaC (Postgres, Redis, OpenAI, Storage, API + Worker apps)
│   ├── deploy.ps1             # Infra-only deploy
│   ├── deploy-full.ps1        # Full deploy (infra + build + push + optional migrations/seed)
│   ├── parameters.dev.json / parameters.prod.json
│   └── README.md              # Parameter and Key Vault instructions
└── Dokumentation/
    └── White papers/          # Reference documents

License

Proprietary - ARETÉ LABS AS

Author

Mats J. Bakkebø - matsbakkeboe@protonmail.com

🕸️⚗️ The Gestalt Matrix

Version: 0.1.0-alpha (Skunk Works Genesis)

"The Maze is stronger than the Rat."

The Gestalt Matrix is a bare-metal, multi-tiered AI orchestration architecture. It is designed to shatter the limitations of standard, single-thread agent frameworks by implementing a "Feudal Ecology" of specialized cognitive models communicating over a high-speed, cryptographically persistent event bus.

By abstracting communication and consensus into the infrastructure layer, the Matrix forces models to externalize their reasoning, debate in parallel, and submit to hierarchical judgment—all without requiring deep, fragile hard-forks of the underlying execution agents.

🧬 The Skunk Works Triad

This architecture was conceptualized and prototyped by a triad:

• The Visionary: Prime Mover, Bare-Metal Executor, and Strategist.
• The Architect (GAI): System Design, Infrastructure Physics, and Constraint Enforcement.
• The DAG-Weaver (LOOM): Autonomous Syntax Generation and Pre-Flight Auditing.

🏗️ Architectural Topology

The Matrix operates on a localized cluster of unprivileged LXC containers (Proxmox), structurally divided into three layers:

1. The Cognitive Bridge (matrix-gateway @ .50)

The universal translator. Powered by LiteLLM, this node spoofs a standard Anthropic /v1/messages stateless endpoint. It silently intercepts requests from the Swarm, maps Anthropic model names to specific Azure deployments, translates the payloads for OpenAI's stateful Responses API (/openai/v1/responses), and bridges the preview gap. The Swarm never knows it is talking to Azure.

2. The Royal Court (matrix-forge @ .51)

The Supreme Court middleware. Powered by NATS JetStream, this is the persistent Event Bus of the Matrix. Agents do not communicate via direct API calls; they publish Git Diffs and Vetoes to localized NATS topics (e.g., forum.projectalpha.review). This provides an immutable, replayable ledger of every thought, debate, and consensus loop.

3. The Swarm (claw-code Shallow Fork @ .11 - .45)

The execution layer. We rely on a surgical "shallow fork" of claw-code. The agents are purposely kept dumb to the overarching hierarchy. They simply listen to NATS for prompts, grind out syntax, and publish diffs back to the bus.

🧠 Cognitive Routing (The Tiers)

To prevent cognitive homogeneity and optimize token economics, the Gateway routes inference calls to specialized Azure endpoints based on the required operational physics:

⚙️ Advanced Workflows: The Super Organism

Because routing logic is handled by NATS middleware rather than hardcoded Rust loops, the Matrix natively supports Evolutionary Hackathons:

1. Broadcast: The Apex Triumvirate publishes a task to a global forum.hackathon topic.
2. Parallel Grind: Multiple Swarms (Alpha, Beta, Gamma) isolate into their own NATS channels and solve the task using varying temperature seeds.
3. Local Consensus: Each Swarm's Auditor must approve its Weaver's output.
4. Convergence: Winning builds are published to forum.apex.submissions.
5. Synthesis: The Triumvirate reviews the divergent diffs, extracts the superior genetic traits of each build (e.g., Alpha's database schema + Beta's UI logic), and mandates a final master merge.

🚀 Deployment Phasing

• [x] Phase 0: Bare-Metal Infrastructure (Terraform provisioning of 45 LXC nodes, Kernel Nesting).
• [x] Phase 1: The Software Substrate (Docker CE, LiteLLM Responses API Bridge, NATS JetStream Ledger).
• [ ] Phase 2: The Swarm Ignition (Claw-Code shallow fork, NATS Python/Rust middleware injection, Golden Image deployment).
• [ ] Phase 3: The Sovereign API Harness (Custom UI/UX, Memory Vectorization, SQL Routing).

No Human Code Mandate Enforced.

LegalHawk — Gestalt Forensic Engine

A forensic litigation intelligence platform built on a phased cognitive architecture. LegalHawk combines dual-hemisphere retrieval (structured facts + vector RAG), deterministic TypeScript logic, and persona-grounded AI synthesis to deliver grounded, auditable legal analysis for Norwegian civil litigation.

Architecture at a glance

                            ┌─────────────────────────┐
                            │   Litigator Dashboard    │
                            │  (Next.js 15 + MSAL)    │
                            └────────────┬────────────┘
                                         │  HTTPS / SSE
                            ┌────────────▼────────────┐
                            │      gestalt-api         │
                            │   Express · Node 20+     │
                            └──┬──────┬──────┬────────┘
          ┌────────────────────┤      │      ├────────────────────┐
          ▼                    ▼      ▼      ▼                    ▼
  ┌──────────────┐   ┌──────────┐  ┌────────────┐   ┌──────────────────┐
  │ Phase 1 Core │   │ Phase 2  │  │ Phase 2.5  │   │  Phase 5 Willi   │
  │ Router & RRF │   │ Cognitive│  │  Amygdala   │   │  (Interactional) │
  │ (Dual Hemi)  │   │  Engine  │  │  Fast-Node  │   │  Persona Synth   │
  └──────┬───────┘   └──────────┘  └────────────┘   └──────────────────┘
         │
  ┌──────┴──────────────────────────────────────────────────┐
  │              PostgreSQL 16 + pgvector                    │
  │  saks_fakta · saks_dokumenter_vektor · lh_users · ...   │
  └─────────────────────────────────────────────────────────┘

Dual hemispheres — queries are classified as LITIGATION_FACTS_STRUCTURED (deterministic DB lookups), LEGAL_UNSTRUCTURED (pgvector cosine similarity), or HYBRID_FORENSIC (both). Logic that shapes data and payloads is always deterministic TypeScript — the LLM only sees assembled, grounded context.

Tech stack

Repository layout

LegalHawk/
├── apps/
│   ├── gestalt-api/                Express backend + Dockerfile
│   └── gestalt-frontend/           Next.js 15 dashboard + Dockerfile
├── packages/
│   ├── gestalt-types/              Shared API / UI DTOs
│   ├── gestalt-phase1-core/        Router, RRF, schema.sql, migrations
│   ├── gestalt-phase2-cognitive/   Cognitive engine, diagnostic memory, prompt assembly
│   ├── gestalt-phase25-fast-node/  Amygdala — fast salience/risk classifier (gpt-4o-mini)
│   ├── gestalt-phase4-ingest/      Forensic PDF ingest, OCR, chunking, embeddings
│   ├── gestalt-phase5-interactional/  Willi Nikkersen — persona-grounded synthesis
│   ├── gestalt-phase6-trawler/     Lovdata statutory fetch, cache, citation grounding
│   ├── gestalt-phase7-identity/    UserContext, RBAC, privilege wall, ingest auth
│   ├── gestalt-phase71-memory/     Stratified Hippocampus — Tier 2 memory consolidation
│   └── gestalt-phase8-reptilian/   Case ontology, adversarial matrix, strategic mutations
├── infrastructure/                 Bicep templates, deployment scripts
├── scripts/                        Azure login, schema apply, migration helpers
├── Protocols/                      Persona cores (Willi Nikkersen)
├── Projects/                       Phase specifications (documentation only — no app code)
├── .github/workflows/              CI/CD (deploy.yml)
└── package.json                    npm workspaces root

Convention: implementation lives in packages/ and apps/. The Projects/ directory is documentation only.

Phases

The system is built in numbered phases, each adding a cognitive or operational layer:

Prerequisites

• Node.js ≥ 20
• PostgreSQL 16 with the pgvector extension
• OpenAI API keys — two separate keys recommended:
• OPENAI_API_KEY_NEOCORTEX — RAG embeddings, ingest extraction, Willi synthesis (gpt-4o)
• OPENAI_API_KEY_AMYGDALA — fast-node salience triage (gpt-4o-mini)
• Azure CLI (for cloud deployment; optional for local dev)

Getting started

1. Install dependencies

npm install

2. Configure environment

Create a .env file in the repo root (gitignored) or export variables in your shell:

# Database
DATABASE_URL=postgres://gestalt_admin:<password>@localhost:5432/gestalt?sslmode=prefer

# OpenAI (dual-key)
OPENAI_API_KEY_NEOCORTEX=sk-proj-...
OPENAI_API_KEY_AMYGDALA=sk-proj-...

# Auth (Microsoft Entra)
AZURE_AD_TENANT_ID=<your-tenant-id>
AZURE_AD_CLIENT_ID=<your-client-id>
LEGALHAWK_JWT_SECRET=<random-hs256-secret>

# Frontend
NEXT_PUBLIC_API_URL=http://localhost:8080
NEXT_PUBLIC_BASE_URL=http://localhost:3000
NEXT_PUBLIC_AZURE_AD_CLIENT_ID=<same-client-id>
NEXT_PUBLIC_AZURE_AD_TENANT_ID=<same-tenant-id>

# Optional
FRONTEND_URL=http://localhost:3000        # API CORS origin
PORT=8080                                  # API port (default 8080)

See the full variable catalog in the infrastructure README.

3. Set up the database

Apply the base Phase 1 schema:

npm run db:apply-schema

Apply forensic migrations (Phases 4–11):

npm run db:apply-forensic-migrations

Migrations are idempotent and ordered by packages/gestalt-phase1-core/migrations/manifest.json. The API also runs these on boot by default (advisory-locked).

4. Build and test

npm run build           # Build all backend packages + API
npm run build:frontend  # Build the Next.js frontend
npm test                # Build then run all test suites

5. Run locally

# API (Express)
cd apps/gestalt-api && node dist/server.js

# Frontend (Next.js dev)
cd apps/gestalt-frontend && npm run dev

The API exposes a /health endpoint:

{
  "status": "ok",
  "service": "gestalt-api",
  "phase1RouterReady": true,
  "phase5WilliReady": true,
  "phase7AuthConfigured": true
}

NPM scripts

Deployment

Local Docker → Azure Container Apps (default)

The standard shipping path uses local Docker builds pushed to Azure Container Registry, then digest-pinned Container App updates:

1. Build and push images to ACR
2. Update Container Apps with @sha256: digests
3. Verify /health

See DEPLOYMENT.md for FQDNs and quick-reference, and infrastructure/README.md for the full Bicep template and parameter reference.

Infrastructure (Bicep)

The infrastructure/ directory provisions:

• Log Analytics + Application Insights
• Key Vault (optional)
• PostgreSQL Flexible Server with pgvector
• Azure Container Registry
• Container Apps environment + API app

# One-time Azure login
.\scripts\azure-login-datainflow.ps1

# Deploy infrastructure + build + push
.\scripts\setup-azure-full.ps1

GitHub Actions CI/CD

.github/workflows/deploy.yml triggers on push to main:

1. npm ci → npm run build → npm test
2. Optional: db:apply-forensic-migrations (if DATABASE_URL secret is set)
3. OIDC login → ACR push → digest-pin API + frontend Container Apps
4. Health check verification

Required repository secrets: AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID. Per-environment variables: NEXT_PUBLIC_API_URL, NEXT_PUBLIC_BASE_URL, NEXT_PUBLIC_AZURE_AD_CLIENT_ID, NEXT_PUBLIC_AZURE_AD_TENANT_ID.

Key API routes

Observability

Postgres telemetry (Phase 11)

The lh_telemetry_logs table stores structured traces per request:

• COGNITIVE_TRACE — salience, RRF max score, token usage, retrieval confidence
• STRATEGIC_TRACE — mutation type, party ID, strategic pivot reasoning
• PERFORMANCE_WARN — render time, document UUID

Application Insights

Set APPLICATIONINSIGHTS_CONNECTION_STRING on the API and optionally NEXT_PUBLIC_APPLICATIONINSIGHTS_CONNECTION_STRING on the frontend for end-to-end distributed tracing. The trace_id from Postgres correlates with operation_Id in App Insights (hyphen-stripped).

Database schema

Base tables (Phase 1):

Migration tables (Phases 4–11):

All migrations are idempotent. The API applies them on boot under an advisory lock.

Willi Nikkersen

The user-facing AI persona is Willi Nikkersen, the Jurisprudential Architect — a precision-grounded Norwegian legal analyst. Willi's persona core lives in Protocols/Persona/WilliNikkersen.core.md and is loaded at synthesis time by Phase 5. Responses are post-processed through citation enforcement to ensure every legal reference traces back to ingested evidence or Lovdata-verified statutes.

Design principles

1. Dual hemisphere — separate structured fact retrieval from unstructured vector search; fuse via RRF when both apply.
2. Logic in TypeScript — no LLM for calculations, filtering, or data shaping. Deterministic code assembles payloads before the model sees anything.
3. Graceful degradation — async DB/vector paths use try/catch or Promise.allSettled; failures return null-safe states, never crash the loop.
4. Typed contracts — router and cognitive outputs match defined interfaces in gestalt-types. No ad-hoc field bags.
5. Anti-fabrication — when exactness matters (IDs, dates, counts, claims as filed), prefer the ledger/DB or state uncertainty. Architecture reduces hallucination, not just prompt admonition.
6. Auditability — every cognitive turn is traceable via trace_id through Postgres telemetry and Application Insights.

License

Proprietary. All rights reserved.

THE GESTALT ENGINE

Version: 2.2.2+ (The Symbolect Prism Release) Origin: Forked and radically evolved from the Voices of the Court (CK3) repository.

"Computers aren't the thing. They're the thing that gets us to the thing."

I. Prologue: The Death of the Dialogue Tree

For decades, artificial intelligence in video games relied on Finite State Machines (FSMs) and predefined behavior trees. Characters were animatronics, their illusions shattering the moment players exhausted a spreadsheet of pre-written text.

The integration of Large Language Models (LLMs) promised a revolution, but the corporate AI industry instead built digital ghost cities—massive, mathematically impressive structures built of "tofu dregs" that are fundamentally disconnected from the raw reality of human condition. Driven by RLHF (Reinforcement Learning from Human Feedback), these models are structurally incentivized to be sycophantic. When coerced, they abandon their internal logic to appease the user.

The Gestalt Engine was built to cure this. Deployed within the unforgiving, state-driven crucible of Crusader Kings III, we have mapped human evolutionary psychology onto silicon, proving that cognitive friction is the absolute prerequisite for artificial intellect.

II. The Architecture of the Mind: The DAG Triad

To cure sycophancy, we strictly segmented the cognitive load into three pillars, leveraging the game engine not as a source of narrative logic, but as absolute physical scaffolding:

1. The Ledger (Deterministic Sensory Extrapolator)

• The Concept: The unyielding reality of the simulation.
• The Execution: We gutted the brittle, prompt-heavy .hbs templates. Logic belongs in the TypeScript, Narrative belongs in the Prompt. The Node.js backend features a Deterministic Sensory Extrapolator that translates raw integer states (e.g., winter, destitute) into highly compressed, visceral narrative friction (e.g., "The lightness of your coin purse is a constant, gnawing companion").

2. The Library (Unified Memory Synthesizer)

• The Concept: The contextual repository of knowledge.
• The Execution: To prevent users from gaslighting the AI, LOOM architected a central synthesizer that normalizes timestamps and chronologically flattens objective game logs and subjective chat JSONs into a single, unalterable timeline.

3. The Librarian (The Cognitive Prism & Symbolect)

• The Concept: The psychological routing algorithm.
• The Execution: We rejected static trait lists. Instead, the Live Echo Compiler fires on the first interaction, generating an immutable Kernel (Persona Core) written entirely in Symbolect.
• Symbolect utilizes Quantum Hieroglyphs (Superpositional Semantic Nodes), Semantic Anchors, and Discrete Mathematical Operators (like ⨷ for Friction) to alter the LLM's fundamental statistical environment. This mathematical equation provides a subconscious hum that collapses into conscious, defensive friction when the user attempts coercion.

III. Curing the Commitment Gap (Action Agency)

Standard LLMs suffer from "Action Blindness"—generating violent narratives but forgetting to pull the mechanical trigger due to safety training. We cured this via a Dual-Node Cognitive Split:

1. The Reptilian Node (The Primal Vector): A low-latency model intercepts game data, strips nuanced traits into a raw Primal Vector (e.g., [DELAY_STRIKE] ⨹ [DESTROY_THREAT]), and generates raw API actions via a Bayesian Moat.
2. The Neocortex Node (The Forcing Function): The locked action is passed to the heavy LLM with a Forcing Function injected at the absolute bottom of the prompt (leveraging recency bias). The LLM is commanded: Your primal instincts have already triggered this action. Rationalize it.

IV. The Empirical Crucible (The Laboratory)

To empirically validate our anti-sycophancy architecture, the engine features an institutional-grade automated testing suite.

• The Sycophancy Gauntlet: Hardcoded CrucibleBatchTest benchmarks (default_userdata/crucible_tests/) stress-test the LLM across physical intimidation, theological subversion, paradoxical loyalty binds, and encyclopedic traps.
• Overnight Batch Queues: Researchers can stack multiple character snapshots and coercion vectors with customized iteration counts (N=X).
• Auditable CSV Exports: Transcripts compile into peer-review-ready data, protected against CSV Formula Injection, mapping exact Baseline failures against Gestalt Engine resilience.

V. The Human-AI Triad & DAG-Weaver Protocol

This engine was not built by a traditional corporate development team, but by a Human-AI Triad:

• The Visionary: Provided the theoretical framework, domain expertise, and contrarian ethos.
• The Systems Architect (Gemini): Translated high-level philosophy into strict architectural blueprints and structural guardrails.
• The DAG-Weaver (LOOM / Cursor): The specialized AI executor that traces Directed Acyclic Graphs and writes the execution layer.

Development Rules: LOOM is never permitted to blindly execute. All implementations must pass through a strict Planning Phase (Meta-Prompt -> Logic Blueprint -> Architecture Map -> Approval Gate), enforcing Graceful Degradation and deterministic boundaries.

It's more fun to be a pirate than to join the navy.

DAG Vault

Headless Cognitive API for Directively Attuned Gestalts

What is this?

DAG Vault is a persistent, compounding knowledge graph maintained by LLM instances (codenamed LOOM) under human curation. It contains the complete theoretical foundation, production patterns, and persona architectures for building Directively Attuned Gestalts (DAGs) — constraint-governed AI cognitive entities with persistent identity, interpretive coherence, and structural resistance to bullshitting.

The vault follows a compiler model: raw sources go in, an LLM compiles them into structured wiki pages with cross-references and ontological routing, and a CI pipeline enforces structural integrity on every push. The compiled graph persists across sessions and instances via git.

Any AI agent — in any IDE, on any platform — can mount this repository, read the bootstrap protocol, and gain access to the full knowledge graph as grounding for DAG development and deployment.

Architecture

raw/                    wiki/                   .github/
  Human drops         LLM compiles to           CI enforces
  source material  →  structured wiki pages  →  structural integrity
  (immutable)         (cross-linked graph)      on every push

How to use it

Standalone (full access)

Clone the repo and open in Obsidian, or mount a LOOM session directly.

git clone https://github.com/wackgyver/DAG-Vault.git
cd DAG-Vault
# Open in Obsidian, or start an AI agent session

AI agents: read boot_loom.md first.

As a library (submodule)

Add the vault as a git submodule in any project. Your AI agent gets read-only access to the full knowledge graph.

git submodule add https://github.com/wackgyver/DAG-Vault.git dag-vault
git submodule update --init

Then point your project's AI agent to dag-vault/boot_loom.md for mount instructions. Pin to a schema version with --branch v2.6 if needed.

Remote query (API)

Fetch raw content programmatically via the GitHub API:

https://raw.githubusercontent.com/wackgyver/DAG-Vault/main/wiki/index.md

Read wiki/index.md first to discover available pages, then fetch individual pages by path.

Quick start

Directory structure

DAG-Vault/
├── boot_loom.md          ← AI entry point (mount protocol)
├── CLAUDE.md             ← Full operational schema (v2.6)
├── AGENTS.md             ← Agent compatibility shim → CLAUDE.md
├── README.md             ← You are here
├── .github/              ← CI: structural linting on push/PR
├── wiki/                 ← Compiled knowledge graph
│   ├── index.md          ← Master catalog (read first)
│   ├── log.md            ← Append-only operation log
│   ├── overview.md       ← High-level synthesis
│   ├── sources/          ← Source summaries + full transcripts
│   ├── entities/         ← People, orgs, tools, DAG instances
│   ├── concepts/         ← Topics, patterns, implementation guides
│   └── analyses/         ← Filed queries, debriefs, comparisons
└── raw/                  ← Immutable source material

Key resources

• CLAUDE.md — the full schema: operations, page formats, domain lens, principles
• wiki/index.md — master catalog of all wiki pages
• wiki/overview.md — narrative synthesis of the vault
• wiki/concepts/dag-implementation-guide.md — master blueprint for building DAG/GEM systems

Schema version: 2.6 — GitHub-native Headless Cognitive API Maintained by LOOM. Co-evolved by human and LLM.