Fluential Labs · Draft 0.1 · April 2026 Classification: pseudo.proposal + pseudo.paper
This document is written in the format it describes. The structure is the specification. Reading it is using it.
pseudo.CODE is a human-readable intermediate representation, file format system, and IDE architecture designed to serve as a universal translation layer between natural language intent and executable code across all target languages. It addresses four convergent failures in the current state of software development: (1) the documentation crisis that causes AI coding agents to modify code they do not understand, producing failure rates between 41–87% in multi-agent systems [Cemri et al., arXiv:2503.13657, 2025]; (2) the inherited fragmentation of programming syntax systems that encode identical logical primitives in incompatible surface forms for historical rather than computational reasons; (3) the absence of a development environment that treats code comprehension as a spatial, relational, and cumulative act rather than a linear file-reading exercise; and (4) the systemic exclusion of blind and low-vision developers from programming through notations that are semantically opaque under text-to-speech rendering — an exclusion that has never been architecturally necessary, only unconsidered.
pseudo.CODE proposes: a dot-slash context-narrowing notation that maps cleanly onto all known language primitives; a hashtag-based mutability designation system that makes binding state present at every point of use rather than only at declaration; a structured file-extension system encoding the type of thinking a document contains rather than its data format; a document format structured as a research paper in which the natural language specification and the formal implementation are halves of the same file; an IDE with hover-based X-ray visualization surfacing relational context inline without breaking reading state; a Rust-backed WebAssembly compilation target enabling browser-native deployment with no installation barrier; and a screen-reader completeness mandate establishing that every expression in pseudo.CODE produces semantically coherent speech under text-to-speech rendering with no information loss relative to visual reading.
The system is designed to integrate with agentic pipelines such that no coding agent can touch any implementation without first having processed its full specification chain — making incomprehension structurally visible rather than silently destructive.
Programming languages are not incompatible because their underlying operations differ. They are incompatible because each language generation inherited its surface syntax from the compiler constraints of its parent, encoding identical logical primitives — assign, compare, iterate, branch, call, return, define structure, define behavior — in different costumes while the thing underneath remained constant.
This inheritance chain was necessary. Early compilers required unambiguous delimiters. The curly brace existed not because it was elegant but because the compiler needed a character unlikely to appear in variable names. That constraint dissolved as parsers became sophisticated enough to handle contextual disambiguation. The syntax remained.
The consequence is that three developers working in C, Python, and Rust are solving the same problems with the same eight primitive categories [cross-reference: language-primitives table, Fluential Labs 2026] while producing artifacts that cannot speak to each other without explicit translation layers, foreign function interfaces, and the substantial overhead of maintaining expertise in the boundary protocol between them.
A secondary consequence is the identifier-as-abstraction problem. Variable names carry no information about their category, their operation, or their mutability state. x could be anything. Whether x is mutable or immutable is declared once, at the top of a function or file, and thereafter absent from every subsequent use. The developer reading x = x + 1 three hundred lines from the declaration must remember, look up, or infer whether this operation is structurally permitted. AI agents fail at this constantly. Blind developers using screen readers cannot recover this information at all — the declaration is not present in the audio stream at the point of mutation.
Donald Knuth recognized the documentation crisis in 1984 and proposed literate programming [Knuth, The Computer Journal, Vol. 27 No. 2, 1984]: programs should be written as literature, with code embedded in explanation rather than explanation appended to code. Knuth's WEB system failed not because the insight was wrong but because the toolchain created a third file format requiring maintenance alongside both source and documentation, and because the tangle/weave workflow demanded three distinct competencies simultaneously [Ramsey, "Literate Programming Simplified," IEEE Software Vol. 11 No. 5, 1994]. Eve, the most ambitious modern revival, built 34 environment prototypes and 9 compilers before shutting down in 2018 — having correctly identified that "existing languages have a fundamental dependence on source ordering antagonistic to the idea" [futureofcoding.org/essays/eve].
pseudo.CODE resolves Knuth's insight by inverting his method. Rather than embedding code in documentation and extracting it, pseudo.CODE makes the documentation the first half of the executable file. The tangle step disappears. The file is always one thing.
Four conditions have converged to make this possible and necessary simultaneously.
First, AI coding agents are deployed at scale and failing at rates that make the documentation crisis economically legible. Independent evaluation of leading agents found 15% real-world task completion [Answer.AI evaluation of Devin, December 2024]. Package hallucination rates of 19.6% create exploitable attack surfaces [Spracklen et al., USENIX Security 2025]. The root cause across failure taxonomies is consistently specification and coordination failure — agents touching code they do not understand [Cemri et al., 2025; Roig, arXiv:2512.07497, 2025].
Second, the compilation target stack is finally mature enough to support a human-readable IR above it. MLIR's progressive lowering with round-trippable textual representations [Lattner et al., arXiv:2002.11054, 2020] and WebAssembly's WAT format as a browser-deployable, human-readable IR [Haas et al., PLDI 2017] provide the infrastructure pseudo.CODE compiles through rather than reinventing.
Third, spatial IDE research has quantified what developers intuitively know: file-based navigation is cognitively expensive and the file boundary is a social artifact, not a computational one. Code Bubbles demonstrated 33.2% lower task completion time when relational context replaces file-based navigation [Bragdon et al., ICSE 2010]. No empirical study has established that modular multi-file organization outperforms well-structured single-file organization with collapsible hierarchy for individual comprehension — the assumption was inherited from editor memory constraints of the 1970s, not derived from evidence.
Fourth, the systematic exclusion of blind and low-vision developers from programming is not an architectural necessity. It is a side effect of notation design that was never evaluated against the requirement of auditory comprehension. pseudo.CODE is the first programming notation designed from first principles to be screen-reader complete — not as an accommodation layer added after the fact, but as a property of the core notation that follows directly from the same design principle that makes it AI-readable. A notation that is semantically explicit for agents is semantically explicit for screen readers. Both audiences share the identical requirement: that every expression carry its full meaning in the sequence of tokens that compose it, without relying on visual layout, spatial proximity, or contextual memory to fill semantic gaps.
This section constitutes the formal half of the document. Natural language descriptions above map to structural definitions below. All handles reference their Introduction description via inline notation.
I.1 Core Syntax — Three Constructs
pseudo.CODE uses exactly three syntactic forms:
context.chain/operation [contextual operation]
(expression) [context-free operation]
literal [raw value, no operation]
These three forms are sufficient to represent every primitive in the eight-category language map [cross-reference: language-primitives.md, Fluential Labs 2026] with two acknowledged escape conditions: binary operators resolved via the parenthetical form, and macro/metaprogramming constructs resolved via compile-time annotation syntax.
I.2 Dot Notation — Context Narrowing
The dot in pseudo.CODE does not mean method call. It does not mean field access. It means restrict. Each dot reduces the semantic search space to the most specific possible owner before the slash operation fires.
domain.scope.target/operation
domain— top-level category (maps to the eight primitive categories)scope— second-level narrowing (module, class, struct, namespace equivalent)target— third-level narrowing (instance, current state, specific resource)operation— the primitive action executed within the accumulated context
Example: messages.user.current/lookup
= perform lookup, constrained to: messages → user → current message
= not a method call on an object; a scoped operation within a narrowing context chain
Screen reader speaks: "messages, user, current — lookup" Information conveyed: complete. Grammatical. No noise tokens.
This maps cleanly onto Uniform Function Call Syntax as implemented in Rust and the polyglot interoperability protocol's semantic message-passing model [Grimmer et al., ACM TOPLAS Vol. 40 No. 2, 2018], but is neither. The dot is a scope operator. The slash is an execution boundary.
I.3 Slash Notation — Execution Boundary
The slash marks the transition from context declaration to operation. Everything left of the slash is navigational. Everything right of the slash is behavioral. This enforces the categorical separation between DATA+ORGANIZATION (left) and BEHAVIOR (right) at the syntactic level.
data.organization/behavior
The slash is not a path separator (cf. Unix filesystem). It is not a namespace separator (cf. Rust ::). It is an explicit categorical boundary made visible in every expression.
I.4 Parenthetical Form — Context-Free Operations
Binary operations and expressions with no natural owner use closed parenthetical form:
(a + b)
(x > threshold)
(value_a, value_b) [tuple construction]
Parentheses mean: this is a complete expression with no external context. They do not mean function call. The separation of grouping from invocation eliminates the primary source of syntactic ambiguity inherited from C-family languages.
I.5 Chaining — Output as Context
The output of one operation becomes the context of the next via dot continuation:
messages.user.current/lookup.result/filter
Each slash-separated operation receives the output of the previous operation as its implicit left context. The chain reads left to right in execution order, matching natural language subject-verb-object flow.
I.6 Mutability Designation — The Hashtag System
pseudo.CODE encodes mutability state directly in handle names using the # character as a designation marker. The system uses a closed/open symmetry:
#handle# → closed binding (immutable, fixed, sealed)
#handle → open binding (mutable, modifiable, live)
The logic is spatial and auditory simultaneously: #handle# is closed on both sides — the handle cannot escape its value. #handle is open on the right — the handle has room to change. A screen reader speaks #handle# as "closed handle" and #handle as "mutable handle." Both sighted and blind developers receive the same information at the same point in the token stream.
Declaration:
#threshold# = 42 // closed — immutable
#count = 0 // open — mutable
#name# = "Jordan" // closed string binding
#accumulator = (0, 0, 0) // open tuple — contents may change
Use — mutability present at every occurrence:
#count/increment // mutable handle, increment operation
#threshold#/compare // closed handle, compare operation
Mutation operations on mutable handles:
#count/set 1 // set mutable handle to value
#count/increment // increment
#count/decrement // decrement
#accumulator/append item // append to mutable collection
Attempting mutation on a closed handle is a parse-time structural error:
#threshold#/set 99 // ERROR: closed binding — mutation structurally forbidden
This error requires no runtime. It requires no type checker. It is visible in the token sequence. An agent, a compiler, or a screen reader user can identify it without additional context.
I.7 Symbol Pronunciation Guide
| Token | Spoken as | Semantic meaning |
|---|---|---|
. |
natural pause / "dot" | restrict to |
/ |
clause pause | execute within |
#handle |
"mutable handle" | open binding |
#handle# |
"closed handle" | immutable binding |
(expression) |
"expression" | context-free operation |
output chain → |
"then" | output becomes next context |
I.8 Cross-Language Equivalents
| pseudo.CODE | Rust | Python | C | Screen Reader (pseudo.CODE) |
|---|---|---|---|---|
#threshold# = 42 |
let threshold = 42; |
THRESHOLD = 42 |
const int threshold = 42; |
"closed threshold equals 42" |
#count = 0 |
let mut count = 0; |
count = 0 |
int count = 0; |
"mutable count equals zero" |
#count/increment |
count += 1; |
count += 1 |
count++ |
"mutable count, increment" |
#threshold#/compare #count |
count < threshold |
count < THRESHOLD |
count < threshold |
"closed threshold, compare mutable count" |
messages.user.current/lookup |
messages.user.current.lookup() |
messages['user']['current'].lookup() |
msg->usr->cur.lkp() |
"messages, user, current — lookup" |
I.9 Complete Function Example
pseudo.CODE:
counter.session/define
#count = 0
#limit# = 100
#label# = "progress"
loop.active/while (#count < #limit#)
#count/increment
output.line/write (#label#, #count)
output.final/write (#count)
Screen reader speaks:
"counter session, define. mutable count equals zero. closed limit equals one hundred. closed label equals progress. loop active, while mutable count less than closed limit. mutable count, increment. output line, write closed label mutable count. output final, write mutable count."
Rust equivalent:
fn counter_session() {
let mut count = 0;
let limit = 100;
let label = "progress";
while count < limit {
count += 1;
println!("{} {}", label, count);
}
println!("{}", count);
}Python equivalent:
def counter_session():
count = 0
LIMIT = 100
LABEL = "progress"
while count < LIMIT:
count += 1
print(LABEL, count)
print(count)The pseudo.CODE version is the only one in which mutability state is present at every point of use, and the only one in which a screen reader produces grammatically coherent, semantically complete speech at every line.
For disambiguation: pseudo.CODE file extensions encode the type of thinking a document contains, not its data format. This is a novel concept without direct precedent [cross-reference: research-foundations.md §8, Fluential Labs 2026], drawing on semantic file systems [Gifford et al., SOSP 1991], REST resource typing [Fielding, PhD dissertation UC Irvine, 2000], and Plan 9 namespace semantics [Pike et al., Computing Systems Vol. 8, 1995].
II.1 File Extension Taxonomy
| Extension | Contains | Agent Reads Before |
|---|---|---|
pseudo.proposal |
Intent before commitment. Problem statement, design rationale, alternatives considered. | Everything else |
pseudo.research |
Compressed context. Human-outlined questions, agent-filled findings, cumulative-additive. | pseudo.paper |
pseudo.map |
Dependency graph. What references what, in what order, under what conditions. | pseudo.paper |
pseudo.mask |
Scope definitions. Conceptual region boundaries without physical file separation. | pseudo.paper |
pseudo.paper |
The program. Both halves: natural language specification + formal implementation. | Implementation |
pseudo.tests |
Behavioral specifications expressed as verifiable claims. | Deployment |
pseudo.lock |
State snapshot. What is settled, what is still moving. | Modification |
pseudo.trash |
Diff of discarded modules, rejected approaches, deprecated handles. Full provenance. | Reference only |
II.2 Agent Ingestion Order
No agent touches pseudo.paper without having processed the full context chain:
pseudo.proposal/read
→ pseudo.research/read
→ pseudo.map/read
→ pseudo.mask/apply
→ pseudo.paper/read
→ pseudo.paper/modify [only now permitted]
This makes incomprehension structurally visible. An agent either has processed the full specification chain or it has not. There is no intermediate state in which it thinks it understood. This directly addresses the specification failure root cause identified across agentic failure taxonomies [Cemri et al., 2025; Roig, 2025].
II.3 The pseudo.research File Structure
Human-authored sections:
## Current State Snapshot
[human fills: what exists, what works, what doesn't]
## Suggested Research Queries
[human fills: specific questions for agent investigation]
## Open Problems
[human fills: unresolved design decisions]
Agent-filled sections (cumulative, never overwrite, append only):
## Findings: [query title]
[agent fills under each query, timestamped]
[previous agent findings remain visible above new findings]
Discarded research moves to pseudo.trash with diff annotation. Nothing is lost. Everything is retrievable.
For disambiguation: pseudo.CODE adopts the academic research paper structure as its document format. This is not a documentation convention — it is an architectural requirement. The README is not attached to the program; it is the first half of the program.
III.1 Paper Structure
Every pseudo.paper follows this mandatory structure:
# [Project Name]
## ABSTRACT [one paragraph, plain language, readable by anyone]
## INTRODUCTION [why, problem space, design decisions, full prose]
## METHODS [categorical breakdown, context chains, handle hierarchy]
[bridge between human-readable and formal]
## [IMPLEMENTATION] [actual code — every handle preceded by its Methods entry]
## DISCUSSION [what was rejected, known limitations, design rationale]
The ABSTRACT and INTRODUCTION constitute the natural language half. The METHODS section is the bridge. The IMPLEMENTATION section is the formal half. The DISCUSSION is what most codebases never have and every codebase needs.
III.2 Inline Reference System
pseudo.CODE adopts Wikipedia's inline reference architecture:
- Every handle references its METHODS entry:
[cross-reference: §II.2] - Every architectural decision references its DISCUSSION justification:
[rationale: §V.3] - Every dependency references its pseudo.map entry:
[depends: messages.user] - Hatnotes at every section entry point: disambiguation, cross-reference, precondition
III.3 Collapsible Hierarchy as the Module System
pseudo.CODE does not use modules. Modules exist to manage cognitive load by hiding what is not currently relevant — a problem solved in contemporary editors by collapsible hierarchy. The module boundary is a manual collapse.
A single pseudo.paper with collapsible hierarchy is more navigable than a directory of modules for a solo developer or an agent building context from scratch: one file, complete context, no import graph to reconstruct.
Conceptual regions within a single file are defined by pseudo.mask rather than by file separation. A mask defines which handles belong to which conceptual region without moving anything.
This section has equal standing with every other section in this document. It is not an accommodation. It is a first-class design constraint.
IV.1 The Requirement
pseudo.CODE is required to be fully navigable by screen readers with no information loss relative to visual reading. Every proposed extension to the notation must pass the following test before inclusion:
Does a screen reader produce semantically complete, grammatically coherent speech from this expression, with no information that a sighted developer would have that a blind developer would not?
If no: the extension is rejected or redesigned until it passes.
IV.2 What Screen Readability Requires
For a programming notation to be screen-reader complete, four conditions must hold:
-
No semantic content in visual layout. Indentation and spatial proximity may not be the sole carrier of any information. Every structural relationship must also be expressible in token sequence.
-
No symbol-as-shorthand. Symbols used as compressed representations (
->,::,&&,||) degrade to spoken noise. Every operator in pseudo.CODE is a word, a dot (spoken as a natural pause meaning "restrict"), a slash (spoken as a clause boundary meaning "execute"), or a hashtag (spoken as "mutable" or "closed" depending on form). -
Mutability state travels with the handle. The
#designation means a screen reader user hears the mutability state of every handle at every point of use — not only at declaration. This was the primary motivation for the hashtag system: it solved the mutability problem and the accessibility problem with the same token. -
Expression order matches speech order.
domain.scope/operationspoken as "domain, scope — operation" follows subject-verb order. The notation reads as language, not as symbol sequence.
IV.3 The Contrast
Consider the same expression in three notations, evaluated for screen reader output:
| Notation | Expression | Screen reader speaks | Information conveyed |
|---|---|---|---|
| C | msg->usr->cur.lkp() |
"msg arrow usr arrow cur dot lkp open-paren close-paren" | None. Token noise. |
| Rust | messages.user.current.lookup() |
"messages dot user dot current dot lookup open-paren close-paren" | Partial. Words meaningful, parentheses are noise. |
| pseudo.CODE | messages.user.current/lookup |
"messages, user, current — lookup" | Complete. Grammatical. Navigable. |
A blind developer on pseudo.CODE loses nothing relative to a sighted developer reading the same source. That sentence has never been true of any other general-purpose programming notation. It should have been true from the beginning.
IV.4 Screen Reader Pronunciation Reference
| Token | Spoken as | Why |
|---|---|---|
. |
natural clause pause | "restrict to" — pause is sufficient; the word follows |
/ |
stronger clause pause | execution boundary — the operation begins after the pause |
#handle |
"mutable handle" | open binding — spoken as adjective + noun |
#handle# |
"closed handle" | immutable — the repeated hash is heard as a completed frame |
(a + b) |
"a plus b" | standard arithmetic — already accessible |
→ in chains |
"then" | output-becomes-context — causal sequence word |
V.1 X-Ray Mode — Passive Relational Context
X-Ray mode activates on hover. No click required. No mode switch.
On mouse-over of any handle, expression, or notation element:
surface: thought-bubble overlay [non-blocking, spatially anchored]
content:
- priors: what calls or defines this element
- resultants: what this element calls or produces
- call count: how many times this handle is invoked system-wide
- hierarchy position: what conceptual region (mask) this belongs to
- inline reference: link to METHODS entry for this handle
- mutability state: open or closed [derived from # designation]
- dependency weight: is this load-bearing or peripheral?
The thought bubble is a first-class interactive object:
- hover the bubble: expand without navigation
- click the bubble: navigate to referenced location
- pin the bubble: hold in view while reading adjacent code
- ellipsis clouds: regions between current focus and reference rendered as dissolved visual noise, not hidden — spatial awareness maintained
This is distinct from existing reference panels (Sourcetrail, Code Iris, LSP hover) which break spatial context by opening separate panels. X-Ray keeps reference anchored to referent in space.
V.2 Rendering Layer — Fully Decoupled
The thought bubble is a display contract, not a UI component. The semantic layer produces:
relation.type [priors | resultants | call-count | position | weight | mutability]
relation.source [handle identifier]
relation.target [handle identifier]
relation.weight [float: 0.0–1.0]
Valid renderers include speech bubbles (default), circuit diagram branches, Wikipedia-style footnote superscripts, musical notation (for timing-sensitive operations), or arbitrary custom renderers via the rendering API. The fart joke renderer and the enterprise monochrome renderer consume identical relation objects.
V.3 Logic Chain Visualization
On explicit request, any handle expands into full chain view:
[N hops back] → ... → [selected handle] → ... → [N hops forward]
Everything outside the selected chain is rendered as ellipsis clouds — present, spatially located, dissolved from focus.
V.4 Compilation and Export
pseudo.paper/parse
→ pseudo.CODE IR/validate [against eight-category primitive map]
→ Rust/generate [Rust as proof layer: type system validates structural soundness]
→ WASM/compile [via wasm-pack or cargo + wasm-bindgen]
→ target.language/render [output format selected from dropdown]
| Output | Status |
|---|---|
| Rust | Primary — also the validation backend |
| C | Compile target via LLVM IR |
| Python | Direct transpilation |
| TypeScript/JavaScript | Browser-native via WASM |
| LLVM IR | Intermediate — exposes compiler layer |
| WebAssembly WAT | Human-readable IR layer |
V.5 Browser Deployment
The IDE is browser-native via TypeScript + WASM. No installation. Distribution is a URL. The semantic layer runs in WASM for performance. The result is a development environment that runs at near-native speed in any browser with zero install friction.
VI.1 The Consent Layer
pseudo.CODE is a consent layer for code modification.
An agent that modifies code it has not fully read is operating without the informed basis that consent requires. The file-extension ingestion order (§II.2) is not a workflow recommendation. It is a structural requirement enforced by the IDE's agent interface.
agent.session/initialize
→ agent.session.context/load [ingests full pseudo.* chain in order]
→ agent.session.context/verify [confirms comprehension of specification]
→ agent.session/operate [only now: read, modify, generate]
An agent that attempts pseudo.paper/modify without having completed the ingestion chain receives a structural error. The architecture makes the error unavoidable.
VI.2 Context Compression — pseudo.research as Living Log
The pseudo.research file solves the context window reset problem. Every agent session that produces findings appends to the research file. No finding is overwritten. When a new session begins — new context window, no prior state — it reads pseudo.research and inherits the full research history without reconstructing it from scratch.
This directly addresses what "Codified Context: Infrastructure for AI Agents in a Complex Codebase" [arXiv:2602.20478, 2026] identifies as the primary scalability problem in agentic development: loss of institutional knowledge across context boundaries.
VI.3 Mutability Enforcement for Agents
The hashtag designation system reduces a class of agent-introduced bugs to zero. An agent reading #threshold#/set 99 does not need to look up the declaration to know this is an error. The contradiction is in the token sequence itself. This converts a reasoning problem — "was this intended to be mutable?" — into a parsing problem — "does this token sequence contain a structural contradiction?" Parsing is solved. Reasoning at distance is not.
pseudo.CODE. CODE in capitals is intentional. The word reads simultaneously as noun (this is pseudo.CODE) and imperative verb (write pseudo.CODE). Both readings are true at once. The "pseudo" carries thirty years of "not real code" baggage that every programmer alive will bring to it before reading a single line. That baggage is exactly what this system dismantles. The name is either the right kind of provocation or it is a marketing problem to solve later.
pseudo.CODE is not a programming language in the traditional sense. It is an intermediate representation designed to be human-readable at every stage — closer to MLIR in function than to Python or Rust in character. The distinction matters because it changes the adoption question entirely.
You do not ask a developer to abandon their language for pseudo.CODE. You ask them to express their intent once, in a format that their tools understand, and select their output language the way they select a file format from a Save As menu. The language becomes a rendering choice. The developer's investment is in the pseudo.paper — the specification — not in the syntax of any particular target.
# was chosen over alternatives (!, ~, @, *) for three reasons. First, it is already associated with "special designation" across developer contexts — hashtags mark topics, preprocessor directives in C, comments in many scripting languages. The association with "this handle is marked" is intuitive. Second, it is spoken clearly and unambiguously by screen readers. Third, the closed/open visual symmetry #x# vs #x is immediately legible as "wrapped" vs "open-ended" — the spatial metaphor matches the semantic content without instruction.
! carries negation. * carries pointer semantics and multiplication. @ carries decorator semantics. # carries none of these conflicts in pseudo.CODE context.
The screen-reader completeness of pseudo.CODE was not designed in as a separate feature. It emerged as a direct consequence of designing for agent readability. Both audiences share the same requirement: semantic completeness in the linear token stream. Recognizing this equivalence and formalizing it as a mandate is the primary contribution of this version relative to earlier drafts.
The developer who posted to an accessibility forum about losing their vision did not lack access to programming because programming is inherently visual. They lacked access because no one had yet built a notation that wasn't. That is a design failure, not a physical one. pseudo.CODE is the correction.
Modules were rejected not because modular design is conceptually wrong but because module boundaries solve an editor problem that collapsible hierarchy solves without the overhead of import graphs. Parnas established information-hiding as a principle; he did not establish the file boundary as the correct implementation. The mask system implements information-hiding without fragmentation.
Separate documentation files were rejected because documentation that lives in a different file from the code it describes has no structural guarantee of remaining in sync. The research paper format makes desynchronization structurally impossible.
Version control as the primary history system was rejected in favor of pseudo.trash because version control records what changed, not what was rejected and why. A diff tells you a function was deleted. It does not tell you why, what replaced it, or what the tradeoff was. pseudo.trash carries that information as a first-class artifact.
A new compiler was not built for the initial implementation. Rust serves as the validation backend because its type system already enforces the ownership and scope semantics that the dot-slash notation expresses structurally. If pseudo.CODE can express something Rust accepts, it is structurally sound.
The first pseudo.paper written will be the one describing pseudo.CODE itself. An agent will translate it to Rust. That Rust will build the translator. The translator will render the next pseudo.paper. The system demonstrates its own value proposition in its first act of existence. This is not irony. It is the most efficient possible proof of concept.
The mask system needs a formal grammar. The relation types surfaced by X-Ray mode need a complete taxonomy. The rendering API contract needs specification as a stable interface before third-party renderers can be written against it. The agent ingestion protocol needs a machine-readable format so it can be enforced programmatically. These are known gaps. They live in pseudo.research as open queries.
This document is pseudo.CODE 0.1. It is simultaneously the specification of the system and the first instance of the format it specifies. Subsequent versions will be written by agents operating under the ingestion protocol described in §VI.1, after having read this document in full.
Fluential Labs · fluentiallabs.com · April 2026 Classification: pseudo.proposal + pseudo.paper · License: Open