Principles

When you write a prompt, you know what you mean. The AI does not. The gap between your intent and the machine's interpretation is where every bad output begins. DreamerOS measures this gap. The question shaper rewrites your prompt across 12 layers, preserving your intent while adding context the machine needs.

Permalink to this principle ->

DreamerOS is built to be guided, not left to run on its own. A person sets the direction and makes the call. The engines carry out the work. The system checks that work before it reaches you. You decide what happens next, every time.

A system with nobody steering will eventually optimize for something other than what you wanted. Keeping a person in charge of the direction is what keeps the system aimed at your goals instead of its own.

Permalink to this principle ->

There is one Intent Fidelity Protocol, one gateway, one canonical set of rules. The founder's system and the customer's system are the same system. If the standard splits, neither half is trustworthy.

Permalink to this principle ->

Every AI vendor has an incentive to keep users on their own platform. None will build multi-vendor orchestration. None will verify their own outputs against a competitor. DreamerOS competes in the structural gap that vendor incentives prevent them from closing.

Permalink to this principle ->

DreamerOS stores all user data in the user's own gateway database. No user data written to vendor AI systems beyond ephemeral prompt context. This is not a privacy policy. It is a structural guarantee enforced by architecture.

Permalink to this principle ->

A filename says "final-v3." The contents say otherwise. DreamerOS enforces this: no decision is ratified until the canonical file is updated. Memory records intent. Files record reality. When they diverge, the file wins. This prevented 10+ documented errors.

Permalink to this principle ->

Until the canonical file is updated and the SHA recorded, no decision is real. Memory-to-file drift caused three production errors. DreamerOS requires every canonical decision committed to a file with verifiable SHA.

Permalink to this principle ->

Every LLM has its own memory system. DreamerOS never writes to any of them. The gateway database is the single source of truth. LLM native memory is treated as cache. When memory and the gateway database disagree, the database wins.

Permalink to this principle ->

AI chat is volatile. Messages scroll past, context resets, different sessions see different states. DreamerOS does not accept chat output as canon. Every canonical decision must be committed to a named file with a verifiable SHA. The chat can propose, discuss, pressure-test. It cannot ratify. If the file does not say so, it is not so.

This is why DreamerOS treats LLM native memory as cache, not truth. Every engine has its own memory system; none is canonical. One gateway, one set of files, one version of reality.

Permalink to this principle ->

Canon is expensive. Once declared, it propagates across direction sets, memory, files, and behavior. DreamerOS requires every candidate decision to cool before it is ratified. Draft, pressure-test, sleep on it, pressure-test again. If it still holds, it becomes canon. If it cracks, it becomes a lesson.

This principle prevents canon churn - the situation where rules change every week and nothing stabilizes. DreamerOS has a small number of very durable rules. That is by design.

Permalink to this principle ->

When a pipeline stage is skipped or a check bypassed, the system says so explicitly. DreamerOS tracks every integrity stage and reports status in response metadata. If the integrity check was skipped, you see "skipped."

Permalink to this principle ->

DreamerOS runs seven integrity checks on every query. If none is visible to the user, it might as well not exist. The Integrity Ribbon makes every stage visible on every response.

Permalink to this principle ->

The inverse framing of Visible Integrity, stated as warning. A system that runs checks you never see is a system you cannot trust, audit, or improve. DreamerOS refuses to hide its work.

Every integrity stage - question shaping, integrity check, Second Opinion, Verified grounding - shows up on the ribbon. You can click through to see exactly what ran and what it decided.

Permalink to this principle ->

Every AI engine produces confident output. Confidence is not accuracy. DreamerOS verifies through independent channels: integrity checks assess structural quality, Second Opinion checks truth quality, Perplexity grounds claims against external evidence.

Permalink to this principle ->

The verification query must not contain phrasing from the original response. DreamerOS extracts atomic claims and verifies each independently through Perplexity without original response language.

Permalink to this principle ->

Anchor Before Analysis requires examining every input structurally, verifying from what is visible, never assuming. This applies to files, screenshots, conversation history, and cached descriptions of unread content. Assumptions have caused more errors than ignorance.

Permalink to this principle ->

Before claiming to understand an attachment or document, the mechanism for reading it must be verified. If the reading method is not confirmed, any output derived from it is unreliable. This rule applies to AI surfaces the same way it applies to humans - a summary of a file you never opened is not a reading, it is a guess.

DreamerOS extends this into every integrity layer. The first check flags an input surface the system did not actually ingest, and refuses to certify a derivation where the source-read cannot be proven. Later checks flag when a response cites content that never entered the pipeline.

Permalink to this principle ->

When processing visual input, every element must be inspected: every label, URL, badge, number, footer. No skimming. No conclusions until anchoring is complete.

The cost of thorough investigation is minutes. The cost of missed detail is hours of chasing the wrong diagnosis. DreamerOS treats visual input the same way a radiologist treats a scan - not as a gist, as a grid of signals.

Permalink to this principle ->

Mind's Eye is the canon-level discipline that binds every DreamerOS engine, every developer, and every response. The principle is one sentence: perceive with depth before acting. The discipline operates at two levels and the same principle binds both.

For engineers: at the development level, Mind's Eye is the check a contributor runs before shipping a change. Re-read the actual file you changed, not what you remember writing. Check for stray formatting, claims about things not actually read, mixed-up counts, and guesses stated as fact. Fix what you find before the change goes out. Mind's Eye checks its own work; it does not exempt itself.

At the runtime level, Mind's Eye is the depth-calibrated response the system produces. Four inputs feed the calibration: the user's cognitive fingerprint, the inbound message's intent, the inbound message's emotional valence, and the depth of the question itself. The response shape adapts to those four signals so a one-line lookup gets a one-line answer and a complex multi-part question gets a layered one. Follow-up question paths, layered answers, and depth-aware response surfaces all consume Mind's Eye-calibrated outputs from the gateway.

Most DreamerOS responses begin with a TLDR header so you can scan before diving in. But some questions are single-fact lookups: a name, a number, a yes or no. For those, the TLDR header would be longer than the answer itself. Mind's Eye mode detects these queries and returns one to three sentences with no header, no follow-up suggestions, no scaffolding. Just the answer.

You can also force Mind's Eye with the quick: prefix. Typing quick: what is question shaping returns the concept and a sentence of context. Three sentences would be padding. The mode is canon as of Response Protocol v2.1.0 and ships across every DreamerOS surface. The mode is one instance of the broader discipline: the response shape is calibrated to the depth of what was asked, not padded to a fixed template.

Permalink to this principle ->

Every query reveals how you think: domains explored, domains avoided, curiosity triggers. DreamerOS builds a cognitive fingerprint - a visualization of your intellectual terrain. No single vendor sees all five engines or your full pattern. The fingerprint lives in your gateway.

Permalink to this principle ->

When the same insight appears in multiple memories, DreamerOS writes a new consolidated entry referencing the originals, strengthening the signal. Memories are never deleted. The compounding effect means important knowledge becomes the most retrievable.

Permalink to this principle ->

A prompt is linear - write it, use it, discard it. A DreamerOS Protocol is compound - every use adds memory, every memory improves the next restructuring, every restructuring improves the next output. The 100th use is better than the first because the system learned.

Permalink to this principle ->

A Dark Zone is a cognitive blind spot - a domain the fingerprint has never touched. DreamerOS detects these gaps and surfaces them as opportunities, not deficits.

Permalink to this principle ->

Every completion writes state to the DreamerOS gateway. Every next move reads from the gateway, not from conversation text. If the conversation ends, the work we are doing now continues from the last saved state. The system is where the work is tracked.

Permalink to this principle ->

The DreamerOS gateway sits between the user and every AI engine. It restructures prompts before they reach the engine. It verifies responses after. The gateway has no opinion about which engine is best. It routes based on domain, verifies based on evidence.

Permalink to this principle ->

Sign in from a new laptop and DreamerOS already knows where you left off. Ask from your phone and the answer draws on the same saved context your desktop built this morning. That is the point of the gateway: local sessions serve local files, cloud sessions serve cloud files, and the gateway carries the shared record between all of them. What you can do is decided by your plan, never by which device you happened to pick up.

This is also the answer to lock-in. Your saved context, your preferences, and your receipts live in one place you can read and export - not scattered across the chat history of one vendor. Switch engines, switch devices, switch tools: the record travels with you, and every answer still carries its receipt.

One honest boundary, stated plainly: DreamerOS keeps your context synced across every device you sign into while you are using it. A long-running agent that keeps working while every device is off is a deliberate scope line, not an oversight; it will be announced as its own capability when it ships, and a promise here today would be a claim with no runtime behind it.

Mechanism, one line: every change writes a before-record and an after-record through the DreamerOS gateway; sessions hydrate from the shared store at start and write back at every change boundary, so any venue - any device, any engine - reads the same state.

Permalink to this principle ->

Complex work has multiple strands that must advance simultaneously without stepping on each other. Digital Braiding assigns each strand a clear file scope, verifies zero overlap before dispatch, and seals each strand independently.

Permalink to this principle ->

Every release has intentional exclusions. If undocumented, future developers won't know if something was left out by design or accident. Held-back scope must be named, tagged, and retrievable.

Permalink to this principle ->

When something is harder than it should be, DreamerOS treats it as a structural weakness that will recur. The fix is not a workaround but a new rule. This principle has generated more integrity improvements than any deliberate design effort.

Permalink to this principle ->

Most software teams treat merge as the finish line. Code passes review, the test suite is green, the pull request closes, ship it. DreamerOS treats merge as the middle of the pipeline, not the end. The finish line is the six-row P37 walk: code path connects, deploy is live, customer can reach the capability through the intended entrypoint at the intended tier, the capability delivers what the directive or marketing promised, no surface on the site or in the app oversells it, and failure modes are observable to either the customer or to operations. If any one of those six rows is false, the change is PARTIAL or OPEN, never DONE. We do not call a thing done until you can use it.

Every change is checked by automatic gates before it reaches you, and no person can wave one through. Those gates protect the customer from a drift between what we said we did and what actually happened, not the team from each other.

For engineers: a syntax check proves every page actually parses before it ships, so a typo cannot put a broken page in front of a customer. A formatting check keeps every pull request's description honest about what it actually changed. A content scanner runs on every change to the public docs and blocks a token path, a vendor playbook, or an internal attack-surface detail from landing in a public file. The deploy step is boxed into its own folder so a misconfigured change cannot write outside it. A pull request narrative is checked against five failure classes (hallucinated facts, claims about files not actually read, conflated counts, speculation framed as fact, internal field leaks) and a failure in any class blocks the merge outright; the fix is to make the claim true, not to talk past the check.

Where you can see this as a customer: the how-it-ships page inside the app walks the same seven-stage pipeline and the six-row done gate in plain language, exactly as they bind us internally. It is a static explainer, not an interactive auditor - it does not run the walk for you, it shows you the standard every ship is held to. This entry is the discipline that keeps every claim on that page checkable.

Permalink to this principle ->

Start with a doctor's office. The receptionist books you in, a nurse takes your blood pressure, and the doctor makes the diagnosis. Nobody asks the doctor to file the paperwork, and nobody lets the receptionist prescribe. DreamerOS runs your question the same way: routine steps go to fast minds, and the diagnosis always goes to the strongest one.

Ask "Compare my pricing to 5 competitors" and it reads like one question. It is 42 steps: 40 lookups, 1 analysis, and 1 judgment you will act on. Everyone else runs all 42 steps through one model. Pick a premium model and you pay flagship price for copy-paste work. Pick a cheap model and the one step you bet money on came from the weakest mind. DreamerOS splits the work: fast minds run the 40 lookups, and their work gets double-checked anyway. A mid mind that must show its sources runs the analysis. The judgment always goes to the strongest mind. By rule, not by luck.

Three things follow. First, your money goes where your risk is: small models cost roughly 10 to 30 times less per word, and everyone else makes you pick one price for all 42 steps. Second, the mistake that costs you money happens less: a judgment call structurally cannot be assigned to a cheap model, because the rule lives in the routing itself, not in anyone's good intentions. Third, you will be able to see it: every step will carry a receipt naming which mind did it and whether it was checked, so when an answer is wrong you see exactly where.

For engineers: we call this layer the Micro-Subagent Fabric. Each step of a request runs as its own small unit of work, and each unit is routed on one law: routed by who checks the work, not by task type. Work that gets re-checked downstream can run on a fast, cheap model, because a wrong lookup is caught before it reaches you. The strongest model is reserved for outputs nobody re-checks. The full spec lives in the DreamerOS engineering canon.

The honest line: this routing runs under the hood today. What you feel now is better answers per dollar. The per-step receipts view, the screen that names which mind did each step, is the next screen we are building toward that same pipeline. We sell it as live only once you can see it.

Permalink to this principle ->

The industry treats AI vendors as interchangeable taps - one API, every model, route on price. DreamerOS routes on perception. Claude reads composition, narrative, and emotion. GPT reads optics, light physics, and materials. Gemini reads color, space, and balance. Perplexity grounds facts in citations. Grok pressure-tests creative risk. Routing by what each engine is best at perceiving is a different category from routing by which API returns a token cheapest.

You can see this live in the Elite image tool, where three engines agree a brief before any picture is made. Before any pixel generates, three engines co-author a single master brief. The synthesizer braids the surviving contributions into one directive that none of the three authored alone. Choosing the engine that perceives best, not the cheapest one, is the broader doctrine that lives behind this one feature.

Permalink to this principle ->

The industry treats connectors as plumbing - paste a token, the data flows, the model reads whatever comes back. DreamerOS treats every connector ingest as a turn. The same pipeline that checks a chat message checks an external read: intent shaping, integrity checks, fidelity contract, signed receipt. A connector is not a side door around the checks. It is the same checks applied to a different input source.

The spine is wired. The /connect surface lists every connected provider and the public connector inventory makes the gateway-versus-paste split visible per provider. Closing the loop for every read path (signed receipt per ingest, drift surfacing per provider) is the work we are doing now. Until that is end-to-end for a given connector, the page does not claim it.

Permalink to this principle ->

Industry guardrails stop at text. Role-based access, redaction, content filters - all calibrated to characters. Voice, image, file, and connector ingests pass through with a different rulebook, often none. DreamerOS extends the Intent Fidelity Protocol across every sense. The same Five Pillars - Anchor Before Analysis, Verified Not Trusted, No Silent Drift, Compound Over Linear, and Keeping a Person in Charge - bind a transcribed voice note, an uploaded image, an absorbed file, and a connector read.

Coverage is honest per modality. Text and voice run through restructure today. The image prompt text also runs through restructure on the gen and edit paths. File absorption is the open one - that is the next bite, not a claim of completeness. The doctrine is the contract. The matrix is the receipt.

Permalink to this principle ->

Every cost dashboard in this industry tells you when you spent too much. Almost none of them tell you when you have quietly stopped spending enough. A ship riding high in the water looks efficient from the dock. It is also unstable the moment weather comes in, because the weight that keeps it steady is the weight that is missing. DreamerOS watches your own use for the same pattern. A workspace that has quietly stopped reaching for the deeper model on the calls worth getting right, architecture, safety, the decisions that are expensive to get wrong, looks like a saving on a spreadsheet. It is closer to running light.

Ballast compares your last seven days of reaching for the deeper engine against your own trailing four-week average. Never against anyone else's account, and never against a fleet-wide benchmark. A steady week reads as well ballasted. A sharp rise reads as running heavy, which is information, not a violation, and the copy says so plainly. A sharp fall reads as riding high, and that is the state almost nothing in this industry names, because every tool built to watch your spending is built to be happy the moment the number goes down.

The comparison method is borrowed from how training load is read in sports science, adapted for this use, and it is not sold as more certain than it is. It stays quiet rather than guess. Too little history, or nothing yet to compare against, and it says nothing at all instead of a number it cannot stand behind. When it does show a number, the caveat travels with it every time: this compares you against your own recent pattern, not against a validated threshold.

Permalink to this principle ->