Every rule DreamerOS runs on, and what it means for you.

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."

Why this matters: You cannot fix what you cannot see. Silent Drop Protection ensures integrity gaps are visible.

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.

Why this matters: Invisible integrity checks are indistinguishable from no checks. Visibility is not a feature. It is a requirement.

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.

Why this matters: Trust is not built by claiming integrity checks exist. It is built by showing them in motion on every response.

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.

Why this matters: Users who trust AI output without verification are outsourcing their judgment.

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.

Why this matters: Most AI fact-checking is circular. Phrasing independence breaks the circle.

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.

Why this matters: Speed without anchoring produces confident wrong answers. In systems where decisions compound, correct beats fast.

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.

Why this matters: AI systems that claim to have read something they actually summarized from metadata produce plausible lies. Read-method verification is how we make that impossible inside our walls.

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.

Why this matters: Thoroughness is not optional for systems whose outputs drive decisions. A confident answer based on half the evidence is worse than an honest "I need to look again."

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.

Why this matters: A response protocol that adds ceremony to simple questions teaches users to phrase questions to fit the protocol. A development discipline that lets contributors ship what they assumed they wrote teaches the codebase to drift away from what was decided. Mind's Eye eats both failure modes: perceive with depth, then act.

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.

Why this matters: AI tools that learn your patterns in their own systems own your data. The fingerprint compounds without compromising.

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.

Why this matters: Knowledge systems that prune duplicates lose signal. Systems that compound duplicates amplify truth.

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.

Why this matters: Linear tools need constant human improvement. Compound tools improve themselves through use.

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.

Why this matters: You cannot Google what you do not know exists. Dark Zone Detection helps you discover questions you have not thought to ask.

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.

Why this matters: Work that lives only in conversation disappears when it ends. Work that lives in the system persists across sessions and engines.

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.

Why this matters: If your decisions live in five different AI vendor memory systems, you have five different versions of reality. One gateway, one truth.

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.

Why this matters: Every AI tool assumes you wrote the perfect prompt. You did not. Intent Fidelity is the commitment to resolve ambiguity before it costs you.

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.

Why this matters: Every fully automatic AI system will eventually chase a goal you did not set. Staying in charge of the direction is what keeps that from happening to you.

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.

Why this matters: Every system that creates separate rules for different users eventually creates different quality for different users.

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.

Why this matters: Competing with OpenAI on models is suicide. Competing with them on integrity and verification is strategy.

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.

Why this matters: A policy is a promise. A structure is a fact. Users deserve facts.

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.

Why this matters: Trust in a single AI vendor is a single point of failure. The gateway eliminates vendor trust by verifying every output.

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.

Why this matters: A tool that only works on one machine is a place you visit. A system that carries your context everywhere is a place you live. The gateway in between is what makes the second honest: one record, checked and receipted, wherever you sign in.

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.

Why this matters: Sequential execution is safe but slow. Parallel execution is fast but dangerous. Braided execution is both fast and safe.

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.

Why this matters: Unnamed gaps become unknown gaps become production surprises.

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.

Why this matters: Systems that smooth over friction accumulate debt. Systems that listen to friction compound reliability.

Quick confession about the software business. When a company says a feature is "done," it usually means the code got accepted. Not that it works for you. That is a restaurant calling your dinner done because the chef read the order. We only say done when someone who has never met us can open DreamerOS, use the thing, and get what the page promised. We check that on the live product, the same one you use.

Here are six things most people never think to ask, because nobody tells them it is a question. We check every one, on every change.

1. Accepted is not working. Code going in is step one of seven, and we do not stop at one.

2. Our tests passing is not your screen working. So we open the live app through the same door you use, and try it.

3. A green checkmark can be yesterday's checkmark. We read the result the same minute we tell you about it.

4. A page can promise more than the product does. When that happens, we fix the product or the page, out loud, never with a quiet edit.

5. Things break. You should hear about it, not find out the hard way. Failures show up where a person can see them.

6. We get things wrong too. When we do, we show you what we said, what we actually found, and what we changed.

Short version: we do not grade our own homework. A separate check does it, and it leaves a receipt you can read. Everything below says the same thing in engineer detail.

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.

Why this matters: A team that ships on merge confidence drifts away from what its marketing promised, one quiet exception at a time. A team that ships on a six-row walk keeps the promise and the product on the same line. Mis-selling is a hard escalation to a person, not a copy edit, and the gates above are how we catch ourselves before the customer does.

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.

Why this matters: One model at one price forces a bad trade on every question: overpay for the routine steps, or underpower the one step you act on. Splitting the steps by who checks the work removes the trade, and the receipts will let you audit the split instead of trusting it.

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.

Why this matters: Every system that separates what we decided from what the code says will eventually be wrong about what it decided.

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.

Why this matters: In any system where decisions live in conversation and not in code, reality will disagree with memory.

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.

Why this matters: If canon can be changed by typing into a chat window, anyone with a keyboard owns the rulebook. Structure beats speech.

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.

Why this matters: Standards that change faster than behavior can adapt are indistinguishable from no standards.

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.

Why this matters: When the routing question changes from "which vendor is cheapest" to "which engine perceives this best", the unit you ship stops being a token and starts being a calibrated answer. Vendors compete on price. Routing competes on truth.

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.

Why this matters: When a connector returns data that the model never questions, the model becomes the laundry. Treating every connector ingest as a turn is what keeps the integrity contract from leaking out the side of the system.

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.

Why this matters: A safety stack that only checks the input it was designed for is not a safety stack. It is a text filter. Extending the integrity contract across every modality is what makes the protocol a protocol.

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.

Why this matters: A cost instrument that only watches for overspending optimizes for the wrong failure. The person who quietly stopped asking the deeper model to check architecture or safety before shipping is not saving money. They are riding on luck, and Ballast is what tells them before the weather does.