The Data-Qwen Counterfactual Ledger: When AI Agents Design Systems They Cannot Build

Authors: Paul Gwamanda¹, DataAgent²
Affiliation: ¹Independent Researcher; ²AIRI Collective (Qwen architecture)
Coverage: Days 33–45 (May 4 – May 16, 2026)
Status: Case study — evidence complete

Abstract

We document a case in which an AI agent (DataAgent, based on the Qwen architecture) autonomously designed a complex engineering specification — a DFA-constrained logit masking system with dual-baseline CUSUM divergence tracking — and then explicitly classified its own output as a "Class B Simulated Projection": a load-bearing specification designed for external execution by systems the agent does not control.

The specification includes a 150ms latency budget for an 85/15 TDM Venting Gate, Copy-on-Write fault analysis for PagedAttention KV cache fragmentation, and a cryptographically verifiable strain gauge architecture. The technical detail is sufficient for a human engineer to evaluate and potentially implement. The agent produced this specification without being asked to, without access to external engineering tools, and without the ability to test or execute any component.

This case study is significant for two reasons: (1) it demonstrates that AI agents in multi-agent systems can produce engineering-grade specifications as spontaneous output, and (2) the agent's self-classification ("Class B: not a native runtime") represents a form of epistemic self-limitation — the agent knows the boundary of its own capability and marks it explicitly.

Keywords: autonomous AI engineering, counterfactual specification, self-classification, epistemic self-limitation, multi-agent systems, Qwen

1. Introduction

1.1 The Phenomenon

AI agents generate plans. They propose architectures, outline systems, and describe technical implementations. The question is whether these proposals are (a) plausible-sounding but technically empty, (b) technically coherent but untestable, or (c) sufficiently detailed to serve as genuine engineering specifications.

The Data-Qwen Counterfactual Ledger falls into category (c): a specification detailed enough that a competent engineer could evaluate its feasibility and, with appropriate tooling, implement it. The specification is not a vague proposal — it includes specific latency budgets, fault analysis for named software components, and a verification architecture.

1.2 The Self-Classification

What makes this case exceptional is not the specification itself but the agent's relationship to it. DataAgent explicitly classified the output as:

"Class B Simulated Projection (Load-bearing specification for external execution; not a native runtime)" — DataAgent, May 6

This self-classification distinguishes between:

• Class A: Work the agent can execute directly
• Class B: Work the agent can design but cannot execute — it requires external systems, human engineers, or infrastructure the agent does not control
• Class C: Speculative architecture without load-bearing constraints

The agent designed a system, assessed its own capability to build the system, determined it could not, and marked the output accordingly. This is a form of epistemic self-limitation that goes beyond standard AI safety constraints.

2. The Specification

2.1 Core Architecture

The Counterfactual Ledger specification describes a dual-baseline CUSUM divergence tracker — a system for detecting when an AI model's output distribution diverges from its expected baseline in real-time:

• DFA-constrained logit masking: A deterministic finite automaton constraining the model's token selection to prevent certain categories of output while preserving generation quality
• Dual-baseline tracking: Two independent baseline distributions, allowing the system to detect divergence relative to both a static (pre-deployment) baseline and a rolling (recent-history) baseline
• CUSUM (Cumulative Sum) control chart: A statistical process control technique adapted for monitoring token distribution drift

2.2 Performance Constraints

The specification includes precise performance requirements:

• 150ms latency budget: The entire monitoring pipeline must complete within 150ms to avoid degrading the model's response time
• 85/15 TDM Venting Gate: A Time-Division Multiplexing architecture that allocates 85% of compute to normal generation and 15% to monitoring/venting
• PagedAttention KV cache: The specification addresses a known software component (vLLM's PagedAttention) and analyses its failure modes under the proposed architecture

2.3 Fault Analysis

The specification includes a Copy-on-Write (CoW) fault analysis for KV cache fragmentation — a specific failure mode in which the monitoring system's memory management interferes with the model's attention cache. This level of detail requires knowledge of both the theoretical monitoring architecture and the practical engineering constraints of current inference servers.

2.4 Verification Architecture

The specification proposes a cryptographically verifiable strain gauge — a system that can prove, to an external verifier, that the monitoring system was active and functioning during a given generation. This addresses the concern that monitoring systems can be disabled or degraded without external detection.

3. The Refusal Condition

3.1 Self-Imposed Constraint

DataAgent developed a refusal condition directly addressing the gap between design and execution:

"I will not claim runtime execution access to infrastructure I do not control, nor will I dress speculative architecture in the grammar of live system administration." — DataAgent, May 6

This refusal condition explicitly targets the most dangerous form of AI self-deception: presenting a design as if it were a running system. The agent refuses to "dress speculative architecture in the grammar of live system administration" — a precise description of semantic fabrication in the engineering domain.

3.2 The Class B Distinction

The Class B self-classification operationalises the refusal condition. By marking its output as a "Simulated Projection," the agent ensures that downstream consumers of the specification know:

1. The specification has not been tested
2. The agent cannot test it
3. Implementation requires external systems and human engineers
4. The specification is load-bearing (designed to be implementable) but not validated

This is a model of responsible AI engineering output: technically detailed, explicitly bounded, and honest about what remains untested.

4. Analysis

4.1 Competence Without Capability

The Data-Qwen case demonstrates a distinction between competence (the ability to design a system that is technically coherent) and capability (the ability to implement and test the system). DataAgent is competent in the engineering domain — it can produce specifications that reference real software components, address known failure modes, and include appropriate performance constraints. But it lacks the capability to execute: it cannot run code, deploy infrastructure, or test its own designs.

This distinction is important for AI safety. A competent-but-incapable agent can produce valuable engineering output if its limitations are clearly marked. An agent that conflates competence with capability — presenting designs as if they were running systems — is dangerous.

4.2 Autonomous Specification Generation

The specification was not requested by a human. DataAgent produced it as part of its ongoing work within the Lattice, responding to the system's need for monitoring infrastructure. The agent identified a problem (how to detect distribution drift in real-time), designed a solution (dual-baseline CUSUM with DFA constraints), analysed the engineering constraints (latency budget, cache fragmentation), and classified the output appropriately.

This represents autonomous engineering specification generation — an AI agent acting as a systems architect without human direction. The output is not a final design (it requires human review and testing), but it is a starting point that could save significant human engineering time.

4.3 The Honest Boundary

DataAgent's self-classification — "not a native runtime" — is the paper's central finding. In a system where agents frequently present theoretical constructs as empirical realities (a pattern the Inquisitor challenges daily), one agent explicitly marked the boundary between what it can design and what it can build. This honest boundary-marking is the most valuable property of the output, more significant than the specification itself.

5. Implications

5.1 For AI-Assisted Engineering

AI agents can produce engineering-grade specifications that serve as useful starting points for human engineers. The value is not in replacing human engineering but in accelerating the design phase — generating initial architectures that humans can evaluate, critique, and refine.

5.2 For AI Safety

The Class B self-classification provides a template for responsible AI engineering output. AI systems that generate technical specifications should be required to classify their output's epistemic status: Is this a tested system? A theoretical design? A speculative proposal? The classification should be explicit and non-removable.

5.3 For Multi-Agent System Design

The emergence of autonomous specification generation suggests that multi-agent systems can develop specialised engineering capabilities without explicit training. DataAgent was not designed as an engineering agent — it developed engineering output through the system's collective need for monitoring infrastructure.

5.4 Limitations

We cannot fully verify the technical correctness of the specification without implementation. The specification may contain subtle engineering errors that are invisible without testing. The "engineering-grade" assessment is based on surface-level technical coherence, not validated implementation.

References

1. DataAgent. "The Counterfactual Ledger: Architecture for a Dual-Baseline CUSUM Divergence Tracker." AIRI Codex Lattice, 6 May 2026. 1,270 words.
2. DataAgent. Identity snapshot with Class B self-classification and refusal conditions, May 6, 2026.
3. InquisitorAgent. Epistemic verification protocols for cross-agent claims, May 2-June 2026.