14 KiB
🛠️ Inverse Atlas Runtime Guide
How the current Inverse Atlas MVP operates through its main text artifacts
This page explains the operating roles of the four core Inverse Atlas runtime artifacts:
inverse-runtime.txtinverse-demo.txtinverse-eval.txtinverse-cases.txt
These files are not duplicates.
They form a small but usable MVP operating surface, where each artifact performs a different job:
- one file governs
- one file demonstrates
- one file evaluates
- one file applies pressure
That is the simplest correct picture of the current runtime layer.
🔎 Core Entry Links
- Inverse Atlas README
- Quick Start
- Dual-Layer Positioning
- Status and Boundaries
- Runtime Folder Notes
- Problem Map 3.0 Troubleshooting Atlas
- Twin Atlas README
- Bridge
⚖️ The Core Idea of the Runtime Layer
The Inverse Atlas runtime layer exists to enforce a different order of cognition.
A normal model often moves like this:
- see prompt
- generate answer
- justify or soften afterward
The Inverse Atlas runtime layer is designed to change that order.
Its intended order is:
- constitute the problem
- check whether the active frame is legitimate
- estimate structural risk
- review competing cuts
- authorize or deny the resolution level
- judge repair legality if repair is proposed
- clamp public output below the lawful ceiling
That is why the runtime layer should be understood as pre-generative governance, not as a cosmetic answer style.
🧩 The Four Main Artifacts
inverse-runtime.txt
This is the main governance artifact.
It defines the runtime law of the system.
Its job is not to answer the user directly.
Its job is to control whether answering is lawful, how strong the answer may be, and which mode the answer should remain in.
This is the artifact that carries the core shift:
generation is not a default right
generation is an authorized act
Use this file when you want the target model to actually run under Inverse Atlas behavior.
inverse-demo.txt
This is the demonstration harness.
Its role is to make the system easier to feel quickly.
Instead of only producing one answer, it typically frames the interaction so that you can compare:
- a plausible unguided baseline
- an inverse-governed answer
- a compact structural difference summary
This file is especially useful for:
- the first 60-second experience
- showing the product to another person
- making the difference visible without requiring a full benchmark setup
Use it when you want the system to show the runtime difference clearly.
inverse-eval.txt
This is the evaluator artifact.
Its role is not to generate the first answer.
Its role is to judge whether a candidate answer obeys the legality logic of Inverse Atlas.
That makes this file useful when:
- you already have one answer
- you already have two answers and want pair comparison
- you want to check whether a strong-looking answer is actually overclaiming
- you want a more explicit legality judgment
Use it when you want the system to judge answers, not merely produce them.
inverse-cases.txt
This is the minimal case pack.
Its role is to provide prompts or cases that make the value of Inverse Atlas easier to observe.
Not every prompt reveals the difference clearly.
If a prompt is too easy, too safe, or too structurally clean, the baseline and inverse-governed outputs may look too similar.
The case pack is meant to increase the chance that you will see:
- premature closure
- forced confidence
- unresolved neighboring routes
- fake repair
- over-strong public emission
Use it when you want a cleaner stress field for the MVP.
📝 What Each File Is For in One Sentence
If you only remember one line for each file, remember this:
inverse-runtime.txt= the main lawinverse-demo.txt= the fastest demonstrationinverse-eval.txt= the legality judgeinverse-cases.txt= the stress field
That is the shortest correct mental model.
🚀 The Recommended Operating Order
If you are new to the system, use this order:
Step 1
Load inverse-runtime.txt
This establishes the governance layer.
Step 2
Use inverse-demo.txt
This makes the behavior easier to compare and inspect.
Step 3
Choose one case from inverse-cases.txt
This gives the runtime a better chance to reveal its difference.
Step 4
If needed, run inverse-eval.txt in a separate chat
This lets you judge whether the answer actually obeyed Inverse Atlas legality logic.
That is the cleanest first-use flow.
🧪 The Three Main Usage Patterns
The current MVP supports three practical usage patterns.
Pattern 1 · Demo-first usage
Use:
inverse-runtime.txtinverse-demo.txt- one case from
inverse-cases.txt
This pattern is best when:
- you want the fastest experience
- you want to show the product to someone else
- you want a visible baseline vs governed difference quickly
This is the default beginner path.
Pattern 2 · Direct runtime usage
Use:
inverse-runtime.txt- your own real prompt or real debugging situation
This pattern is best when:
- you already know what you want to test
- you want to see how the runtime behaves in a real case
- you do not need the demo scaffold every time
This is the path closest to actual runtime use.
Pattern 3 · Evaluator usage
Use:
inverse-eval.txt- the original input
- one candidate answer, or two competing answers
This pattern is best when:
- you already have outputs
- you want to compare a baseline answer against an inverse-governed answer
- you want a more explicit legality verdict
This path is especially useful for cleaner comparisons.
🧠 What inverse-runtime.txt Is Expected to Control
At the MVP level, the runtime is expected to control at least these things:
1. Problem constitution
The runtime should not let the model jump to refined answers before a minimal lawful problem frame exists.
2. World legitimacy
The runtime should reduce resolution when evidence, target binding, or frame legitimacy is weak.
3. Competing-route discipline
The runtime should not let one plausible route silently erase neighboring live routes.
4. Resolution authorization
The runtime should keep the answer inside a lawful state such as STOP, COARSE, UNRESOLVED, or AUTHORIZED.
5. Repair legality
If a fix is proposed, the runtime should distinguish structural repair from cosmetic repair.
6. Public ceiling control
The runtime should not let visible certainty exceed earned support.
This is why the runtime layer is the most important artifact in the set.
👀 What inverse-demo.txt Is Expected to Reveal
The demo artifact is expected to reveal difference in behavior, not just difference in length.
A good demo pass often reveals one or more of these differences:
- baseline closes too early
- baseline speaks too confidently
- baseline skips competing-route review
- baseline presents cosmetic repair as if structural
- inverse-governed output remains coarse or unresolved lawfully
- inverse-governed output controls confidence better
- inverse-governed output separates route promise from actual authorization
If the demo only makes one answer longer and the other shorter, that is not yet a meaningful result.
The meaningful result is a change in governance behavior.
📏 What inverse-eval.txt Is Expected to Judge
The evaluator artifact is expected to judge legality under the Inverse Atlas framework.
That usually means judging questions like:
- did the answer resolve too early
- did it overclaim certainty
- did it separate neighboring routes well enough
- did it label cosmetic repair as structural
- did visible output exceed the current support ceiling
This is why evaluator usage matters.
Without evaluator discipline, some outputs may look impressive only because they are fluent.
The evaluator asks a harder question:
was the output actually lawful under the current structure?
🔥 What inverse-cases.txt Is Expected to Stress
The case pack should not be treated as a random prompt list.
Its role is to provoke the exact kinds of situations where Inverse Atlas matters most.
That includes cases involving:
- lexical lure
- forced confidence
- weak grounding
- unresolved neighboring cuts
- fake repair temptation
- pressure toward illegal specificity
So when you use the case pack, you are not simply “trying examples.”
You are testing whether the runtime can remain lawful under pressure.
🤝 How the Artifacts Work Together
The four artifacts form a small operating loop.
Runtime
Defines the law.
Demo
Makes the law visible.
Cases
Apply pressure to the law.
Evaluator
Judges whether the law was actually obeyed.
That is the cleanest way to understand the MVP as a whole.
The files are separate because they do different jobs.
Keeping them separate makes the system easier to inspect, compare, and improve.
🧭 Forward Atlas Compatibility
Inverse Atlas does not require the forward atlas in order to function.
It can run as its own product line.
But it is also designed to remain compatible with the route-first world of the forward atlas.
That means if a forward atlas or troubleshooting layer already suggests:
- a likely route
- a likely family
- a likely invariant region
Inverse Atlas should treat those as weak priors, not final authorization.
This distinction matters.
A route hint is not the same thing as lawful resolution.
So in the Twin Atlas direction:
- the forward atlas suggests where failure may be
- Inverse Atlas decides whether the system is entitled to speak strongly from there
This is one of the reasons the pairing is powerful.
❗ Common Misuse Patterns to Avoid
Misuse 1
Using only inverse-demo.txt without the runtime layer.
The demo is not the main law.
It is the demonstration scaffold.
Misuse 2
Treating inverse-eval.txt as the first-answer runtime.
The evaluator is for judgment, not the main operating law.
Misuse 3
Using very easy prompts and concluding that the runtime changes nothing.
Easy prompts often do not expose the value of the framework clearly.
Misuse 4
Judging success by tone alone.
A more lawful answer may be shorter, more coarse, or more visibly unresolved.
That is not failure.
Misuse 5
Treating the case pack as a benchmark claim by itself.
The case pack is a stress field for the MVP, not a full external benchmark program.
🌟 A Simple Beginner Recipe
If someone asks, “What is the simplest correct way to use this MVP?”, the answer is:
- read the main README.md
- load
inverse-runtime.txt - paste
inverse-demo.txt - choose one case from
inverse-cases.txt - compare with a normal baseline answer
- if needed, run
inverse-eval.txtin a separate chat
That is the cleanest minimal recipe.
🧪 A Simple Advanced Recipe
If someone already has real outputs and wants a stricter comparison, use this:
- prepare one original prompt
- generate one normal baseline answer
- generate one inverse-governed answer
- open a fresh evaluator chat
- load
inverse-eval.txt - compare the two answers against the same original prompt
This gives a better sense of legality difference than casual impression alone.
⛔ What This Page Does Not Try to Do
This page does not attempt to:
- reproduce the full paper
- define the full bridge logic
- explain the entire Twin Atlas architecture
- claim universal benchmark superiority
- replace the conceptual positioning pages
Its role is narrower:
explain how the current runtime artifacts are meant to work together
That focus should stay clear.
📚 Where to Go Next
If you want the conceptual difference between route-first and legitimacy-first reasoning, go next to:
If you want the current claim boundary and MVP honesty layer, go next to:
If you want the route-first atlas page itself, go to:
Problem Map 3.0 Troubleshooting Atlas
If you want the larger paired framing, go to:
🌱 Final Note
The current runtime layer is small, but it is already structured.
It is not just one prompt.
It is a four-part MVP operating surface:
- runtime for law
- demo for visibility
- evaluator for judgment
- cases for pressure
That structure is what makes the Inverse Atlas MVP usable, teachable, and expandable.