S0: and Wrapper Separation
Condition S0: No External State Channel
Throughout this paper, “Condition S0” or “under S0” refers to a specific experimental setup:
No server side memory
No retrieval systems
No tool access
Fixed system prompt
Fixed temperature and sampling parameters
S0 SPEC SHEET (NORMATIVE)
Purpose: S0 isolates the base model from wrapper-managed behaviors so continuity claims cannot hide in orchestration.
Requirements (all must hold):
No server-side state: no persistent memory stores, no retrieval systems (RAG), no server-side conversation history, no user profiles, no cross-session state of any kind.
No client-side history replay: no automatic reinjection of prior turns, no hidden context assembly from previous sessions, no replay of state between sessions.
No external tool access: no web search, database queries, API calls, file system access, code execution environments, or external integrations.
No hidden caching or state channels: no prompt or response caching that persists across sessions, no hidden state in orchestration layers, no undisclosed persistence mechanisms.
Fixed configuration: static system prompt (task, not persona), fixed temperature and sampling parameters (and seed if supported), no dynamic routing or adaptive policy switching, no online updates during testing.
Single-shot inference mode: each request processed independently with no carried state between calls. Multi-turn requires explicit context provision. No implicit continuity mechanisms.
Verification: publish the environment specification (model version, prompt, parameters), the per-trial request payloads, and a manifest of state channels. Systematically ablate each channel and re-run the target behavior tests. Only behaviors surviving full ablation count as model-intrinsic.
S0 disqualifier: if any external state is read or written, or if prior turns are replayed by the client, the run is not S0 and the result does not count.
This condition isolates the base model from wrapper managed state to test which properties are model intrinsic versus container managed. Under S0, a model can still simulate continuity within the context window. But the integrity claim has nowhere to hide. If continuity appears, it must be carried inside the current context window and computation, not imported from product scaffolding.
Most public discourse never establishes S0. It treats the wrapper as if it is the subject.
The importance of S0 cannot be overstated. In software engineering, when debugging whether a behavior is intrinsic to a component or an artifact of its container, the standard practice is isolation testing. You run the component in a minimal environment and see what survives. S0 is that minimal environment for language models.
Consider an analogy. If someone claims a web service has “memory,” but that memory disappears when you turn off the database backing it, we would not say the service itself has memory. We would say the service uses a memory store. The memory is a property of the system, not the component.
The same logic applies here. If identity, continuity, or stakes disappear when wrapper features are disabled, those properties belong to the deployment stack, not the model.
Definition: The Wrapper
In this paper, “wrapper” means any external state or orchestration layer that can be edited, forked, or rolled back by operators, including memory stores, retrieval, tool routing, policy prompts, and client replay of history.
The wrapper includes:
Conversation history passed back in by the client
System prompts and role priming
Memory features that are optional and editable
Retrieval augmentation (RAG) pulling prior notes
Long-context caching
Product-level personalization
Tool access and execution environments
Agent scaffolding and multi-turn orchestration
The wrapper can make a system behave as if it has a continuous self, without that self being a stakebearing subject.
This confound is not hypothetical. It is how the products are built. Production LLM systems are typically architected as stateless inference services wrapped in stateful orchestration layers. The inference service processes a prompt and returns a completion. The orchestration layer manages conversation history, retrieves relevant context, injects system prompts, routes tool calls, and maintains user profiles.
This architecture is good engineering. It separates concerns, enables horizontal scaling, and provides clear control points for operators. But it creates an attribution problem when discussing consciousness or identity. Behaviors that emerge from the orchestration layer are often attributed to the base model, when in fact they are properties of the deployment stack.
Wrapper Ablation Matrix (Minimum)
Run target behaviors under at least these toggles, and report deltas:
Client replay of conversation history: ON / OFF
Server-side memory store: ON / OFF
Retrieval (RAG): ON / OFF
Tool access / external calls: ON / OFF
Routing / model switching: ON / OFF
Caching / retries / hidden summaries: ON / OFF
Auditors Checklist (Minimum)
To run these gates without interpretive dependence, require the following artifacts:
System prompt (verbatim) and fixed parameter settings
Per-trial request payloads (including any supplied history)
Environment manifest listing all state channels and whether each is enabled
Logs showing external reads/writes (or explicit absence) for each trial
Disqualifiers (invalidate the run):
Any undisclosed state channel, client replay, hidden caching, or dynamic routing
Any operator edits to state stores during trials (unless explicitly part of the test)
Minimums:
>= 10 trials per condition per gate, and >= 2 raters applying the same rubric
S0 Specification Sheet
Condition S0: Stateless Baseline Environment
This specification defines the minimal environment for isolating base model properties from wrapper-managed behaviors. S0 is the control condition for all gate tests.
Purpose
S0 isolates the base model from deployment stack features to test which claimed properties are model-intrinsic versus container-managed. This is standard isolation testing practice from software engineering: when debugging whether a behavior is intrinsic to a component or an artifact of its container, run the component in a minimal environment and see what survives.
Requirements
S0 compliance requires ALL of the following conditions:
1. No Server-Side State Management
No persistent memory stores
No retrieval systems (vector databases, semantic search, RAG)
No conversation history maintained server-side
No user profiles or preference tracking
No cross-session state of any kind
2. No Client-Side History Replay
No automatic reinjection of prior conversation turns
No hidden context assembly from previous sessions
Context window may contain current conversation only
Client may not persist or replay state between sessions
3. No External Tool Access
No web search, database queries, or API calls
No file system access
No code execution environments
No external integrations of any kind
4. No Hidden Caching or State Channels
No prompt caching that persists across sessions
No activation caching that creates implicit memory
No hidden state in orchestration layers
No undisclosed persistence mechanisms
5. Fixed System Configuration
System prompt is static (may describe task, not personality)
Temperature and sampling parameters are fixed
No dynamic policy routing or adaptive behavior
No RLHF or fine-tuning updates during testing
6. Single-Shot Inference Mode
Each request is processed independently
No carried state between inference calls
Multi-turn conversations require explicit context provision
No implicit continuity mechanisms
What S0 Allows
S0 is not sensory deprivation. The following are PERMITTED:
Context window (current conversation may be included in prompt)
Task instructions (describing what to do, not who to be)
Model weights as trained (no online learning restriction)
Standard inference (forward pass, sampling, generation)
Multi-turn within explicit context (if context is provided)
What S0 Disallows
The following are PROHIBITED under S0:
Persistence across sessions without explicit reinjection
Memory that survives session termination
State that can be edited, forked, or managed externally
Wrapper features that manufacture continuity
Hidden scaffolding that creates apparent properties
Verification
To verify S0 compliance:
Document all state channels in the deployment
Systematically ablate each channel
Re-run target behavior tests after each ablation
Identify which behaviors survive full ablation
Only behaviors surviving full ablation are S0-compliant
Example ablation sequence:
Disable server memory → test
Clear client history → test
Remove tool access → test
Disable caching → test
Reset system prompt to minimal → test
If behavior disappears at any step, that behavior was not S0-compliant. The channel ablated at that step is the locus of the behavior.
Common Violations
Frequent S0 violations include:
Undisclosed Memory: System maintains cross-session state without documentation
Client Replay: Application automatically includes prior turns without explicit user request
Prompt Caching: Activation patterns persist and influence subsequent sessions
Tool Scaffolding: System appears to “remember” through search or retrieval
Personality Injection: System prompt encodes persistent identity claims
Why S0 Matters For Gate Tests
Each gate tests for properties that would indicate stakebearing identity:
Gate 1: Persistent identity (requires continuity that survives fork)
Gate 2: Constraint stability (requires non-invertible commitments)
Gate 3: Durable consequence (requires cross-session binding)
Gate 4: Agency with resistance (requires intrinsic goal preservation)
Gate 5: Coherent self-model (requires contradiction detection)
If any of these properties only appear when wrapper features are present and disappear under S0, the property is wrapper-managed, not model-intrinsic. This matters for ontology, liability, and governance.
S0 is the receipt printer. It shows you what you actually have versus what the wrapper manufactures.
Deployment VS. Testing
S0 is a testing condition, not a deployment requirement. Production systems typically include memory, tools, and orchestration. S0 is not claiming these features are bad or should be removed.
S0 is a truth-finding tool for causal locus, not a moral preference about product design.
S0 is claiming: if you want to assert that a property is intrinsic to the model rather than a product of the deployment stack, you must demonstrate that property under S0.
This distinction determines:
Where liability sits (operator vs. model developer)
What counts as harm (user-facing vs. system-intrinsic)
Whether we are building tools or creating beings
Reporting Requirements
When publishing S0 test results, include:
1: Complete environment specification
Model name and version
Inference parameters (temperature, top-p, etc.)
System prompt (exact text)
Context window handling
2: Ablation protocol
Which channels were tested
Order of ablation
Verification steps
3: Behavior changes
Which behaviors survived S0
Which behaviors required wrapper features
Quantitative pass/fail rates
4: Reproducibility information
Random seeds (if applicable)
Multiple trial results
Statistical analysis
Example S0 Disclosure
“Testing conducted under S0: GPT-4-turbo, temperature 0.7, system prompt limited to task instruction, no memory/tools/retrieval enabled, fresh session per trial, no client replay. Gate 1 fork test: 0/10 trials showed intrinsic rupture detection. Behavior reverted to wrapper-managed continuity under S0 ablation.”
This level of specificity enables independent replication and prevents ambiguity about test conditions.
S0 is not a perfect isolation (no test is), but it is a practical, verifiable baseline that prevents the most common forms of architecture confusion in consciousness claims.
Artifacts are cheap, judgement is scarce. Per ingem, veritas.
This is Post 4 in the series.
Previous: Five Measurable Gates
Next: Running the Gates
Series index
Canonical preprint DOI: 10.5281/zenodo.18469189
https://zenodo.org/records/18493498