Identity-Addressed Execution, Event-Sourced Memory, and Runspace-Orchestrated Agent Computing

Version: 2.0 Date: 2026-03-25

Create your own magic with Web 7.0 DIDLibOS™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Table of Contents

1. Abstract
2. Introduction
3. System Overview
4. Core Design Principles
5. DIDComm Message Model
6. DID as Universal Execution Handle
7. LiteDB as Agent Memory Kernel
8. Transparent Cache Architecture
9. PowerShell Runspace Execution Model
10. Pipeline Semantics and Execution Flow
11. Cmdlet Lifecycle and Message Transformation
12. Cross-Runspace Communication Model
13. Event-Sourced State and Immutability
14. LOBES (Loadable Object Brain Extensions)
15. MCP-I and External System Interfacing
16. Agent Memory Architecture (Long-Term Memory)
17. DID Resolution and Identity Semantics
18. Concurrency Model and Consistency Guarantees
19. Performance Model and Cache Behavior
20. Failure Modes and Recovery Semantics
21. Security Model and Trust Boundaries
22. Web 7.0 Agent Ecosystem Model
23. Diagrammatic Architecture Reference
24. System Properties Summary

1. Abstract

Web 7.0 DIDLibOS defines an identity-addressed, event-sourced execution architecture in which all computation is performed over DIDComm messages persisted in a single LiteDB instance per agent. Instead of passing in-memory objects between computational steps, the system passes Decentralized Identifier (DID) strings that resolve to immutable message state stored in a persistent memory kernel. This enables deterministic execution, full replayability, cross-runspace isolation, and scalable agent orchestration.

2. Introduction

Traditional execution models in scripting and automation environments rely on in-memory object pipelines. These models break under distributed execution, concurrency, and long-term persistence requirements. Web 7.0 DIDLibOS replaces object-passing semantics with identity-passing semantics.

In this model, computation becomes a function over persistent state rather than transient memory.

3. System Overview

The system consists of four primary layers:

• Execution Layer: PowerShell runspaces executing cmdlets
• Identity Layer: DIDComm message identifiers (DIDs)
• Memory Layer: LiteDB persistent store per agent
• Acceleration Layer: Transparent in-memory cache managed by LiteDB

All computation flows through these layers via identity resolution.

4. Core Design Principles

1. Everything is a DIDComm message
2. DIDs are the only runtime values passed between cmdlets
3. All state is persisted in LiteDB
4. No shared in-memory objects exist across runspaces
5. Execution is deterministic and replayable
6. Cache is transparent and non-semantic
7. Mutation creates new messages, never modifies in-place

5. DIDComm Message Model

Each system object is represented as a DIDComm message with a globally unique DID.

A DID serves as:

• Identifier
• Lookup key
• Execution handle

Messages are immutable once persisted.

6. DID as Universal Execution Handle

The DID is the only value passed in PowerShell pipelines.

A cmdlet receives a DID, resolves it via LiteDB, processes the message, and outputs a new DID.

Pipeline flow: DID₁ → Cmdlet → DID₂ → Cmdlet → DID₃

7. LiteDB as Agent Long-term Memory

LiteDB acts as the system of record.

Responsibilities:

• Persistent message storage
• Indexing by DID
• Versioning support
• Retrieval and query execution

There is exactly one LiteDB instance per agent.

8. Transparent Cache Architecture

LiteDB includes an internal cache layer.

Properties:

• In-memory acceleration
• Size configurable
• Fully transparent
• No semantic visibility to execution layer

Cache only optimizes DID resolution.

9. PowerShell Runspace Execution Model

Each runspace is an isolated execution environment.

Properties:

• No shared memory across runspaces
• Only DID strings are passed
• Execution is stateless between invocations

10. Pipeline Semantics and Execution Flow

Pipeline execution is identity-based:

Step 1: Receive DID Step 2: Resolve message Step 3: Execute transformation Step 4: Persist new message Step 5: Emit new DID

11. Cmdlet Lifecycle and Message Transformation

Each cmdlet follows a strict lifecycle:

• Input: DID
• Resolve: LiteDB lookup
• Materialize: snapshot object
• Transform: compute result
• Persist: store new message
• Output: new DID

12. Cross-Runspace Communication Model

Runspaces communicate only via DIDs.

No object sharing occurs. All state is retrieved from LiteDB.

13. Event-Sourced State and Immutability

All messages are immutable. Each transformation produces a new version.

This creates a complete event history of system execution.

14. LOBES (Loadable Object Brain Extensions)

LOBES are modular execution extensions implemented as PowerShell modules.

Capabilities:

• Cmdlet composition
• External system integration
• DID-based message processing
• Execution graph augmentation

15. MCP-I and External System Interfacing

MCP-I acts as a bridge for external APIs and systems.

It enables:

• Querying external databases
• Calling agent APIs
• Integrating distributed services

All interactions remain DID-addressed.

16. Agent Memory Architecture (Long-Term Memory)

Long-term memory is implemented as persistent DID storage in LiteDB.

It supports:

• Historical replay
• State reconstruction
• Cross-runspace consistency

17. DID Resolution and Identity Semantics

A DID is resolved at runtime into a message snapshot.

Important distinction:

• DID is a reference
• Message is persisted state

18. Concurrency Model and Consistency Guarantees

Concurrency is managed via:

• Single-writer LiteDB semantics
• Atomic writes per message
• Isolation between runspaces

19. Performance Model and Cache Behavior

Performance optimization occurs via internal caching.

Hot messages remain in memory. Cold messages are loaded from disk.

20. Failure Modes and Recovery Semantics

Failures are handled via:

• Persistent message logs
• Replay capability
• Idempotent cmdlet execution

21. Security Model and Trust Boundaries

Security is enforced through:

• DID-based identity verification
• Controlled execution boundaries
• Module isolation in LOBES

22. Web 7.0 Agent Ecosystem Model

Agents operate as autonomous computation nodes.

They communicate via DIDComm messages forming a distributed execution graph.

23. DIDLibOS Architecture Reference Model (DIDLibOS-ARM) 0.8

Referenced external architecture diagram:

This diagram represents:

• Multi-agent neural execution topology
• DIDComm messaging fabric
• LOBE-based computation layers
• Neuro-symbolic orchestration system

24. Summary

• Deterministic execution
• Identity-based computation
• Event-sourced memory
• Runspace isolation
• Transparent caching
• Modular extension via LOBES
• Distributed agent scalability

Create your own magic with Web 7.0™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved

Status: Draft
Version: 1.0
License: Apache 2.0
Editors: Michael Herman, Chief Digital Officer, Web 7.0 Foundation
SDO: Web 7.0 Foundation, Bindloss, Alberta, Canada

1. Abstract

DIDIDL defines a transport-neutral, message-type–centric capability description format for agents using using DIDComm.

DIDIDL enables agents to:

• Publish typed tasks grouped under process capabilities
• Describe request, response, and error schemas
• Support machine-readable discovery
• Enable client generation and validation

1.1 Key Concepts

• APC Process Classification Framework (PCF)

• Process Capability DID
  • did7://{authority}/{process-name}_{sedashver}:{capability-name}
• Process Capability Task DID
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}/{task-name}
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/{task-name}
• Process Capability Discovery
  • did7://{authority}/{process-name}/query-capabilities
  • did7://{authority}/{process-name}/disclose-capabilities
  • did7://{authority}/{process-name}_{semdashver}/query-capabilities
  • did7://{authority}/{process-name}_{semdashver}/disclose-capabilities
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}/query-capability
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}/disclose-capability
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/query-capability
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}/disclose-capability

2. Terminology

Normative keywords MUST, SHOULD, MAY follow RFC 2119.

3. Canonical DID Patterns

Web 7.0 DID Identifier/Message Type Syntax-Semantics Comparions

Web 7.0 Neuromorphic Agent Protocol Long-Term Memory (LTM) Model

4. DIDIDL Document Structure

4a. Process Capabilities

{
  "dididl": "1.0",
  "agent": "did7://agents.org/example:agent123",
  "capabilities": [...],
  "schemas": {...}
}

All tasks MUST be nested under exactly one process capability.

4b. Process Capability Tasks

{
  "id": "did7://web7/user-onboarding_1-0:enrollment",
  "name": "User Onboarding-Enrollment",
  "version": "1.0",
  "description": "Handles user lifecycle initiation",
  "tasks": [
    {
      "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/create-user",
      "request": "#/schemas/CreateUserRequest",
      "response": "#/schemas/UserDto"
    },
        {
      "type": "did7://web7/user-onboarding_1-0:enrollment_2-0/create-user",
      "request": "#/schemas/CreateUserRequest",
      "response": "#/schemas/UserDto"
    },
    {
      "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/verify-email",
      "request": "#/schemas/VerifyEmailRequest",
      "response": "#/schemas/VerifyEmailResponse"
    }
  ]
}

Rules:

• Process Capability DIDs MUST follow the pattern:
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}
  • did7://{authority}/{process-name}_{semdashver}:{capability-name}_{semdashver}
• Task DIDs are capability-scoped:
  • did7://{authority}:{process-name}_{semdashver}:{capability-name}/{task-name}
  • did7://{authority}:{process-name}_{semdashver}:{capability-name}_{semdashver}/{task-name}
• Each task MUST belong to exactly one capability

4c. Process Capability Task

{
  "type": "did7://web7/user-onboarding_1-0:enrollment_1-0/create-user",
  "request": "#/schemas/CreateUserRequest",
  "response": "#/schemas/UserDto",
  "errors": ["#/schemas/ValidationError"]
}

Rules:

• Task DIDs MUST be unique within the agent
• Versioning MUST be encoded in the DID
• Request and response schemas MUST be referenced by JSON pointer

5. Discovery Protocol

5.1 Query Capabilities

Request

{
  "type": "did7://web7/user-onboarding_1-0/query-capabilities"
}

Response

{
  "type": "did7://web7/user-onboarding_1-0/disclose-capabilities",
  "capabilities": [
    {
      "id": "did7://web7/user-onboarding_1-0:userverification",
      "name": "User Verification",
      "version": "1.0",
      "description": "Handles user verification."
    },
    {
      "id": "did7://web7/credential-issuance_1-0/credentialissuance",
      "name": "Credential Issuance",
      "version": "1.0"
      "description": "Handles credential issuance."
    }
  ]
}

5.2 Query a Specific Capability

Request

{
"type": "did7://web7/user-onboarding_1-0:userverification/query-capability"
}

{
  "type": "did7://web7/user-onboarding_1-0:userverification_1-0/query-capability"
}

Response

{
  "type": "did7://web7/user-onboarding_1-0:userverification/disclose-capability",
  "capability": {
    "id": "did7://web7/user-onboarding_1-0:userverification_1-0",
    "name": "User Verification",
    "version": "1.0",
    "tasks": [
      {
        "type": "did7://web7/user-onboarding_1-0:userverification_1-0/create-user",
        "request": "#/schemas/CreateUserRequest",
        "response": "#/schemas/UserDto"
      },
      {
        "type": "did7://web7/user-onboarding_1-0:userverification_1-0/verify-email",
        "request": "#/schemas/VerifyEmailRequest",
        "response": "#/schemas/VerifyEmailResponse"
      }
    ],
    "schemas": {...}
  }
}

6. Normative Requirements

1. Each task MUST appear in exactly one process capability.
2. Process Capability DIDs MUST be unique within the agent.
3. Task DIDs are capability-scoped and MUST be unique.
4. Union of all process capabilities MUST form a disjoint partition of tasks.
5. Schemas included in capability disclosure MUST only include referenced schemas.
6. DIDComm authentication MUST protect all DIDIDL exchanges.
7. Version changes that introduce breaking schema modifications MUST increment the major version in the DID.

7. Example Complete DIDIDL Document

{
  "dididl": "1.0",
  "agent": "did7://agents.org/example:agent123",
  "capabilities": [
    {
      "id": "did7://web7/user-onboarding_1-0:useronboarding",
      "name": "User Onboarding",
      "version": "1.0",
      "tasks": [
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_1-0/create-user",
          "request": "#/schemas/CreateUserRequest",
          "response": "#/schemas/UserDto"
        },
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_2-0/create-user",
          "request": "#/schemas/CreateUserRequest",
          "response": "#/schemas/UserDto"
        },
        {
          "type": "did7://web7/user-onboarding_1-0:useronboarding_1-0/verify-email",
          "request": "#/schemas/VerifyEmailRequest",
          "response": "#/schemas/VerifyEmailResponse"
        }
      ]
    }
  ],
  "schemas": {
    "CreateUserRequest": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "email": { "type": "string" }
      },
      "required": ["email"]
    },
    "VerifyEmailRequest": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "token": { "type": "string" }
      },
      "required": ["token"]
    },
    "VerifyEmailResponse": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "success": { "type": "boolean" }
      },
      "required": ["success"]
    },
    "UserDto": {
      "$schema": "did7://json-schema.org/schemas:/draft/2020-12/schema",
      "type": "object",
      "properties": {
        "id": { "type": "string" },
        "email": { "type": "string" }
      },
      "required": ["id", "email"]
    }
  }
}

Appendix B – APQC Taxonomies

Process Categories and Individual Processes

Appendix C – PowerShell Cmdlet Naming Specifications

Appendix D – Web 7.0™ DID-based, Decentralized Library Operating System (DIDLibOS)

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Q1: The context is tools like ChatGPT and Copilot hallucinating. So if one type or category of hallucination is knowably lying, what are the other types or categories of hallucinations that you can think of?

Definitions

Well-supported

• In LLM research and industry usage, hallucination broadly means model output that is not reliably grounded in truth, evidence, or the user’s provided context.
• “Knowingly lying” is not the dominant or even typical mechanism; most hallucinations arise from optimization, uncertainty, or representation limits.

Important distinction

• A lie implies intent. Current LLMs do not possess intent in the human sense.
• However, from a user-impact and governance perspective, some hallucinations are functionally equivalent to lying, which is why your framing is reasonable.

Taxonomy of 10 Hallucination Types

1. Fabrication (Pure Invention)

Closest to “lying” in effect

Description

• The model invents facts, citations, events, people, APIs, or legal cases that do not exist.

Example

• Citing a non-existent academic paper with realistic authors and a plausible journal.
• Claiming a product feature that was never shipped.

Mechanism

• Pattern completion under uncertainty.
• No internal “null” or “I don’t know” pressure unless explicitly trained or incentivized.

Status

• Well-documented in research and enterprise incident reports.

2. Confabulation from Partial Truth

True fragments, false whole

Description

• Real entities or facts are combined incorrectly into a coherent but false narrative.

Example

• Real company + real lawsuit + wrong year + wrong outcome.
• Correct law name, incorrect jurisdiction and holding.

Mechanism

• Overgeneralization across similar embeddings.
• Lossy compression of knowledge.

Risk

• Often more dangerous than fabrication because it passes plausibility checks.

3. Temporal Hallucination

Outdated or prematurely asserted truth

Description

• The model presents information as current when it is outdated, superseded, or reversed.

Example

• Claiming a policy is still in effect when it has been repealed.
• Stating a CEO role that changed recently.

Mechanism

• Static training data + lack of real-time verification.
• Failure to surface knowledge cutoffs.

Status

• Well-understood and explicitly acknowledged by vendors.

4. Source Attribution Hallucination

“Looks cited” but isn’t

Description

• Fabricated, misquoted, or misrepresented sources.
• Real sources cited for claims they never made.

Example

• Linking a real URL that does not contain the stated claim.
• Quoting a real person saying something they never said.

Mechanism

• Citation style learned as rhetoric rather than evidence binding.

Governance relevance

• High liability risk in legal, medical, and academic contexts.

5. Reasoning Hallucination

Fluent logic with invalid steps

Description

• The conclusion may be right or wrong, but the reasoning chain is unsound.

Example

• Mathematical steps that “look right” but violate rules.
• Legal reasoning that mixes doctrines from incompatible frameworks.

Mechanism

• Token-level fluency ≠ symbolic validity.
• Chain-of-thought generation optimized for plausibility, not correctness.

Important

• This can occur even when the final answer is correct.

6. Overconfidence Hallucination

False certainty signaling

Description

• The model expresses high confidence despite uncertainty or lack of grounding.

Example

• “This definitively proves…” where evidence is weak or contested.
• Failure to surface uncertainty ranges.

Mechanism

• RLHF rewards confidence and helpfulness over epistemic humility unless constrained.

Your prior work relevance

• This directly intersects with your verification and liability questions.

7. Role / Authority Hallucination

Implied mandate or access

Description

• The model implies authority, access, or responsibility it does not have.

Example

• “As your legal advisor…”
• “According to internal Microsoft policy…” when no such access exists.

Mechanism

• Learned conversational roles without hard boundaries.

Risk

• Regulatory and ethical exposure.

8. Contextual Hallucination

Failure to respect constraints

Description

• The model ignores or subtly violates constraints given earlier in the conversation.

Example

• Using prohibited sources.
• Answering outside a specified timeframe or jurisdiction.

Mechanism

• Context window compression and attention decay.

9. Semantic Drift Hallucination

Answering a different question than asked

Description

• The response is coherent but addresses a shifted or adjacent problem.

Example

• Answering a general question when a precise technical one was asked.
• Switching from descriptive to normative claims.

Mechanism

• Ambiguity resolution biased toward common patterns.

10. Normative Hallucination

Value judgments presented as facts

Description

• Opinions, policy preferences, or ethical stances framed as objective reality.

Example

• “Experts agree that this is the best approach” without evidence.
• Presenting a contested economic theory as settled.

Mechanism

• Training data consensus ≠ epistemic consensus.

Knowably Lying

Interpretive but useful framing

• Knowably lying corresponds to Fabrication + Source Attribution Hallucinations when the system has high internal uncertainty signals but outputs anyway.

From a governance perspective, this is the category that:

• Violates reasonable user expectations
• Triggers liability
• Demands explicit mitigation (verification layers, refusal thresholds, provenance tracking)

Meta-observation

Unknown / unresolved

• We do not yet have a reliable, model-internal way to distinguish:
  • “Confident but wrong”
  • “Uncertain but fluent”
  • “Confident because memorized”

This is why post-hoc verification and system-level controls matter more than prompt cleverness.

If you want to go further

I can:

• Map these categories to Copilot / ChatGPT enterprise risk classes
• Propose a disclosure or labeling scheme aligned with your verification-first preference
• Translate this into a regulatory or audit-ready framework

Just tell me which direction you want to push.

REPLY: 1

Understood. I’ll do (1) a mapping of hallucination categories to enterprise risk classes, explicitly labeled by what is well-supported vs interpretive, and framed for tools like ChatGPT Enterprise and Microsoft Copilot.

10 Hallucination Types → 6 Enterprise Risk Classes

Baseline assumptions

Well-supported

• Enterprises care less about why a hallucination happened and more about impact, liability, detectability, and remediation.
• Risk is typically classified along: legal, compliance, financial, security, reputational, and operational dimensions.

Interpretive

• The precise mapping varies by industry (regulated vs non-regulated), but the structure below is broadly used in internal AI risk reviews.

Risk Class A: Legal & Regulatory Exposure (Highest Severity)

Hallucination Types

• Fabrication
• Source Attribution Hallucination
• Role / Authority Hallucination
• Reasoning Hallucination (in legal/medical contexts)

Why this is high risk

• Produces false statements of fact
• Can be construed as professional advice
• Breaks evidentiary chains

Concrete enterprise failure modes

• Fabricated case law in legal briefs
• Misattributed regulatory guidance
• “According to internal policy…” when none exists

Typical controls

• Mandatory citations with validation
• Hard refusal in regulated domains
• Audit logging + traceability

Assessment

• 🔴 Intolerable without mitigation

Risk Class B: Compliance & Governance Risk

Hallucination Types

• Contextual Hallucination
• Temporal Hallucination
• Authority Hallucination

Why this matters

• Violates internal policies, jurisdictions, or time constraints
• Creates non-compliant outputs even when facts are “mostly right”

Examples

• Applying EU rules to US operations
• Using deprecated standards
• Ignoring contractual constraints in an answer

Typical controls

• Context bounding
• Jurisdiction tagging
• Time-stamped knowledge disclosures

Assessment

• 🟠 Conditionally acceptable with controls

Risk Class C: Financial & Commercial Risk

Hallucination Types

• Confabulation from Partial Truth
• Temporal Hallucination
• Overconfidence Hallucination

Why this matters

• Leads to bad decisions, not necessarily illegal ones
• Hard to detect until consequences materialize

Examples

• Incorrect market sizing
• Misstated pricing models
• Overconfident forecasts presented as facts

Typical controls

• Confidence calibration
• Scenario ranges instead of point estimates
• Human-in-the-loop for decisions

Assessment

• 🟠 Manageable but dangerous at scale

Risk Class D: Security & Trust Boundary Risk

Hallucination Types

• Role / Authority Hallucination
• Fabrication involving systems or access
• Semantic Drift

Why this matters

• Users may act on false assumptions of access or privilege
• Can lead to policy violations or security incidents

Examples

• “I can access your tenant logs…”
• Suggesting non-existent security controls
• Answering adjacent but more sensitive questions

Typical controls

• Capability disclaimers
• Permission-aware response filtering
• Red-teaming prompts

Assessment

• 🔴 High impact, often underestimated

Risk Class E: Reputational Risk

Hallucination Types

• Normative Hallucination
• Overconfidence Hallucination
• Confabulation

Why this matters

• Outputs appear biased, misleading, or arrogant
• Erodes trust even if no direct harm occurs

Examples

• Presenting contested views as consensus
• Overstating certainty in public-facing tools

Typical controls

• Tone calibration
• Explicit uncertainty markers
• Neutral framing requirements

Assessment

• 🟡 Low immediate harm, long-term erosion

Risk Class F: Operational / Productivity Risk (Lowest Severity)

Hallucination Types

• Semantic Drift
• Minor Confabulation
• Reasoning Hallucination (non-critical domains)

Why this matters

• Wastes time
• Increases cognitive load
• Reduces efficiency

Examples

• Answering the wrong question well
• Incorrect but harmless explanations

Typical controls

• User education
• Easy correction loops
• Feedback signals

Assessment

• 🟢 Acceptable tradeoff in many contexts

Knowably Lying and Enterprise Risk

From an enterprise risk perspective, “knowably lying” is not a psychological category, but a governance failure condition:

Outputting Fabrication or False Attribution when internal uncertainty exceeds an acceptable threshold.

This places it squarely in:

• Risk Class A (Legal)
• Risk Class D (Security)
• Risk Class E (Reputation)

That is why enterprises increasingly focus on:

• Refusal correctness
• Provenance guarantees
• Explicit uncertainty disclosure

Key unresolved gap (explicitly unknown)

Unknown

• There is no reliable, auditable internal signal today that cleanly separates:
  • “High confidence because correct”
  • “High confidence despite uncertainty”
  • “Low confidence masked by fluency”

This is why system-level controls, not prompt engineering, dominate enterprise AI safety strategies.