The Three Planar App Types

An architecture for sovereign computing where intelligence is local, state is atomic, and aperture is intentional.

On This Page

The Hidden Assumption
The Three Primitives
How It Works: The Three Organs
Why This Matters: The Design Consequence
The Axioms
A Concrete Example
The Design Implication
What This Enables
The Cost
For Teams Reading This

The Hidden Assumption

There's a hidden assumption baked into almost every app you use: that the backend thinks on your behalf.

It infers what you want. It predicts your next move. It optimizes your experience by watching what you do, interpreting your behavior, and adjusting the world in real time. The system decides your aperture—what you see, when you see it, how deep the view goes.

Roxy rejects this entirely.

In Roxy, the substrate does not think. It notarizes. It never interprets. It never infers. Intelligence stays on the device. State stays atomic. And aperture—what you see and when—remains entirely your choice.

This creates a problem: how do you build a real app that needs both writing and reading, both expression and witnessing, without collapsing this separation?

The answer is the three planar types.

The Three Primitives

Every app that ever existed can be reduced to one of three irreducible operations. Roxy formalizes them.

Type A: Expression Without Reading
A Type A app lets you write without ever reading back what you wrote. Your journaling app. Your voice recorder. Your form submission tool. You express into the void. The substrate receives it atomically, gives you a receipt, and you move on. No feedback loop. No contamination of your intent by the system's interpretation.

Why would you want this? Because the moment you read back what you wrote—the moment the system shows you your own expression filtered through its lens—it begins to shape how you think. The AI-powered autocomplete. The algorithmic ranking of your own notes. The "here's what we detected you said." All of this is corruption. Type A keeps expression pure.

Type B: Witnessing Without Writing
A Type B app lets you read without ever writing. Your archive browser. Your audit log reader. Your timeline viewer. You ask a question—"show me all notes from January"—and you see exactly what you asked for. Nothing more. Nothing less. No hidden analytics. No probabilistic state. No system-driven reinterpretation.

The aperture—the scope, depth, and temporal window of what you witness—is entirely yours to define. The system never widens or narrows your view. You see what you asked to see.

Type C: Coordinating Expression and Witnessing
A Type C app does both, but in strict sequence. You write a message. Then you see the conversation history. You publish a note. Then you see related documents. Expression first. Witnessing second. The phases are separate, deterministic, and transparent.

This is the hardest case. A real app needs coordination. But coordination without contamination requires a membrane—a way to keep the two planes pure while actually doing something useful in the middle.

How It Works: The Three Organs

The substrate has three organs, one for each planar type.

Origin (Write-Only)

Origin is write-only. Apps express into it. It receives, it timestamps, it receipts. It never reads from itself. It never shows you what you wrote. You get a cryptographic receipt. That's it. You move on with your life.

ChronoLedger (Read-Only)

ChronoLedger is read-only. It holds the immutable history. You define an aperture on your device—"show me everything from January to March, schema: notes, depth: full"—and ChronoLedger gives you exactly that. Same aperture, same result, every time. No caching tricks. No algorithmic reordering. Determinism as a feature.

Cosmogateway (Orchestrator)

Cosmogateway orchestrates the two without merging them. Type C apps run locally. You express (which goes to Origin). Then you witness (which queries ChronoLedger). The witnessing phase can see the expression you just made, because the expression reached ChronoLedger before the witnessing started. But expression and witnessing remain separate planes. The system never reads back your expression to influence what you write next.

Why This Matters: The Design Consequence

This architecture forces a radical simplification in how you design apps.

In traditional design, you're always managing invisible complexity: caching, revalidation, conflict resolution, eventual consistency, server-side inference. You're writing defensive code against the backend's opacity. You're asking "did the system get what I meant?" and building UI to handle the answer.

In Roxy, the design becomes transparent and minimal.

Type A Design

You have an input area. A submit button. A "saved locally" confirmation. That's the entire interaction. No loading states from the server. No "syncing." No re-read to confirm. Users submit and move forward. The UX is simple because the architecture is honest.

Type B Design

You have an aperture builder and a results pane. Users define exactly what they want to see. They see it. No algorithmic reranking. No "recommended for you." The interface is straightforward because the semantics are precise.

Type C Design

Two panels. Left panel: what you're writing. Right panel: what you're reading. Between them: a sequence. When you publish (left), the right panel updates to show the new state. There's a visible timeline—"Sent at 2:35pm → Conversation loaded now"—so users understand the latency and ordering. No magic. Just coordination.

The Axioms

Underpinning all of this are seven axioms. They're not guidelines. They're the substrate's laws of motion.

I. Intelligence is Local
All decision-making happens on the device. The substrate never thinks.
II. State is Atomic and Immutable
The substrate stores only true units. No derived data. No probabilistic state. No inference.
III. Aperture is Intentional
Users—not the system—decide what they see.
IV. Expression Must Remain Uncontaminated (Type A)
Type A apps write without reading. No feedback loops that distort intent.
V. Witnessing Must Remain Non-Mutative (Type B)
Type B apps read without writing. They don't change the truth they're reading.
VI. Coordination Must Never Collapse Expression and Witnessing (Type C)
Type C apps orchestrate, but the planes stay separate. No merging. No inference between phases.
VII. Velocity Emerges From Decoupling
The system is fast not because we optimized a monolith, but because we separated expression, witnessing, and coordination into independent planes.

A Concrete Example

Imagine a collaborative note app built on Roxy.

You open the app. You draft a paragraph. This is happening on your device only. No network involved. No server waiting. You see your draft in a warm-colored input area (expression zone). You can discard it, save it locally, or submit it.

You hit publish. Your paragraph becomes an atomic unit. It goes to Origin. You get a receipt immediately. "Saved locally at 2:35pm." You see this confirmation in the same warm area. Your draft is now closed.

Now the app automatically queries the recent notes with an aperture: "all notes from today, schema: note, depth: full, ordered by time." This goes to ChronoLedger. Results come back in a cool-colored panel (witnessing zone) on the right side of the screen. You see all the recent notes, including yours, in chronological order.

You see everything that happened. Your expression succeeded. The witnessing phase is complete. You see a transparent orchestration summary at the bottom: "Expression (1.2s ago) → Witnessing (now)." If you click it, you see the full details: the receipt ID of your write, the aperture that was used, the exact results retrieved, the latency of each phase.

No mystery. No hidden inference. No algorithmic reordering of what you see. Just your expression, plus the world's response to it, presented sequentially and deterministically.

The Design Implication

This architecture dissolves the traditional friction between design, tech, UX, and UI teams.

Design doesn't have to fight tech about what's "feasible." The axioms are the design. Design's job is to make the axioms visible to users. A warm color for expression. A cool color for witnessing. A clear divider between them. A transparent sequencing indicator for coordination. That's not decoration. That's architecture made tangible.
UX doesn't have to manage invisible backend complexity. The interaction model is isomorphic to the substrate model. User expresses → substrate notarizes. User witnesses → substrate retrieves. User coordinates → substrate orchestrates. No hidden state. No defensive patterns. UX becomes straightforward.
Tech implements the three organs and enforces the seven axioms. The codebase becomes smaller because the system is simpler. No caching layer to second-guess. No inference engine to maintain. No central authority over user state. Just pure, dumb, deterministic operations.
UI has one job: make the planes visible. Separate zones for expression and witnessing. Clear affordances for aperture definition. Transparent orchestration status. Icons and colors and spacing that reinforce the axioms. Not prettiness. Clarity.

What This Enables

Apps built on Roxy are:

Sovereign. Users own their data. The system never interprets on their behalf. Never decides what they should see. Never optimizes them into a predetermined shape.

Fast. Decoupled planes mean no cross-cutting concerns. No re-validating reads against writes. No eventual consistency to manage. Expression and witnessing are independent; they move at device speed.

Predictable. The same aperture always returns the same result. The same expression always produces the same receipt. Users can reason about the system. They can build mental models that hold up. No surprising algorithm changes.

Simple. The system does only three things, perfectly. It doesn't try to be smart. It doesn't try to optimize your experience. It witnesses, notarizes, and gets out of the way.

And crucially: the design, the UX, and the UI all become simpler as a consequence. You're not fighting an invisible backend. You're implementing an architecture so clean that it becomes obvious how to present it to users.

The Cost

There is one: the system cannot do what traditional systems do. It cannot infer. Cannot predict. Cannot optimize based on behavior. Cannot learn your preferences and reshape your world around them.

For some use cases, this is fine. For note-taking, journaling, archiving, auditing—these are pure wins. Users get sovereignty without losing capability.

For other use cases—recommendation systems, algorithmic feeds, adaptive UIs—Roxy is not the answer. Those systems require inference. They require the backend to think on your behalf. Roxy forbids it.

But this is not a bug. It's a choice. A choice that says: some problems are worth solving without inference. Some experiences are worth having without optimization. Some apps can be better by being simpler, more transparent, and more honest.

For Teams Reading This

To designers: Your job is to make the axioms visible. Warm for expression. Cool for witnessing. A clear membrane between them. Transparency everywhere the system makes a choice. That's not decoration—that's architecture.

To engineers: Your job is to enforce the axioms at runtime. No server-side inference. No hidden state. No feedback loops. Implement the three organs as pure, dumb, deterministic operations. The codebase becomes smaller because the problem becomes simpler.

To UX folks: Your job is to simplify the model for users. Make it clear what phase they're in. Show them the sequencing in Type C. Let them see the aperture they defined. Don't hide complexity—make it transparent.

To UI builders: Your job is to reinforce the model. Separate visual spaces for expression and witnessing. Clear indicators of state. Icons that mean something. Spacing that breathes. Make the architecture visible without explaining it.

If all of you work from the same axioms, your systems will align. Design, UX, UI, and tech won't contradict each other. They'll all be implementing the same clean architecture, just at different levels of abstraction.

That's the real power here. Not the tech. The coherence.

Conclusion

The three planar app types are not a limitation. They're a liberation.

They liberate design from having to fight an invisible backend. They liberate users from algorithmic optimization. They liberate engineers from managing inference and caching and eventual consistency. They liberate the entire system into something honest and clear.

You can build remarkable apps within these constraints. Apps that are faster, more predictable, and easier to understand than what we have now. Apps where users see exactly what they asked to see, not what an algorithm decided they should see.

That's what Roxy offers. Not everything. Just the essential things. Done cleanly. Done honestly. Done with sovereignty as the default.

And in doing so, it changes how every team in the company thinks about the problem.

Because when the architecture is this clean, everyone can see it. And when everyone can see it, everyone can build on it.