# 🖼️ Figure Notes > The visual companion layer for the current Inverse Atlas MVP This page explains the role of the current core figures used in the Inverse Atlas project. These figures are not decoration. They are the visual compression layer of the current MVP. They help make the framework easier to understand, easier to teach, and easier to discuss. At the current stage, the figure set performs five important jobs: - establish the public visual identity of Inverse Atlas - make the governance shift easier to see - make the runtime order easier to follow - clarify the difference between default design and inverse design - explain how Inverse Atlas fits inside the broader atlas family This page exists so the visual layer can be read as a coherent system rather than a pile of image files. --- ## 🔎 Core Entry Links - [Inverse Atlas README](../README.md) - [Quick Start](../quickstart.md) - [Runtime Guide](../runtime-guide.md) - [Dual-Layer Positioning](../dual-layer-positioning.md) - [Status and Boundaries](../status-and-boundaries.md) - [Runtime Artifacts](../runtime/README.md) - [Paper Notes](../paper/README.md) - [Problem Map 3.0 Troubleshooting Atlas](../../wfgy-ai-problem-map-troubleshooting-atlas.md) - [Twin Atlas](../../Twin_Atlas/README.md) - [Bridge](../../Twin_Atlas/Bridge/README.md) --- ## 📦 Current Figure Assets The current Inverse Atlas public figure layer uses five core figures: 1. [Main Hero](./inverse_atlas_main_hero.png) 2. [Order Shift](./inverse_atlas_hero_order_shift.png) 3. [Design Contrast](./inverse_atlas_design_contrast.png) 4. [Governance Map](./inverse_atlas_governance_map.png) 5. [Family Positioning](./inverse_atlas_family_positioning.png) Together, these five figures form the official first visual layer of the current MVP. They should be understood as the public visual companion set for the current Inverse Atlas release. --- ## 🧭 The Shortest Reading Order If someone is new to the project and only wants the cleanest visual reading path, use this order: 1. [Main Hero](./inverse_atlas_main_hero.png) 2. [Order Shift](./inverse_atlas_hero_order_shift.png) 3. [Design Contrast](./inverse_atlas_design_contrast.png) 4. [Governance Map](./inverse_atlas_governance_map.png) 5. [Family Positioning](./inverse_atlas_family_positioning.png) This order works well because it moves from: - first contact and identity - to conceptual contrast - to design contrast - to governance structure - to family-level positioning In simple terms: - first feel the project - then see the shift - then understand the design difference - then understand the runtime logic - then understand where it fits That is the cleanest beginner sequence. --- ## 🌟 Main Hero [Open Main Hero](./inverse_atlas_main_hero.png) This figure is the visual entry point of the current release. Its job is not to explain every part of the methodology. Its job is to establish public identity, gravity, and first-contact presence. A strong hero figure matters because Inverse Atlas is not only a folder of artifacts. It is also a named methodology line, and the project needs one image that can hold that role. ### Best use Use this figure when you need a first-contact visual. ### Good for - README opening section - project landing pages - release announcements - first-contact previews - visual anchors for public discussion ### Main takeaway This figure gives Inverse Atlas a recognizable public face. --- ## ⚖️ Order Shift [Open Order Shift](./inverse_atlas_hero_order_shift.png) This figure is the fastest conceptual contrast figure in the set. Its job is to show the core shift between: - default answer-first generation - legitimacy-first governed generation This figure is not mainly about system detail. It is about contrast. It helps readers understand the deepest move in the framework: **generation is not a default right** **generation is an authorized act** ### Best use Use this figure when you want to explain the basic intuition of Inverse Atlas as quickly as possible. ### Good for - README pages - short presentations - social posts - first-contact explanations - overview slides ### Main takeaway This is the figure that most quickly shows why Inverse Atlas is not just another prompt trick. --- ## 🧱 Design Contrast [Open Design Contrast](./inverse_atlas_design_contrast.png) This figure explains the difference between default AI design pressure and inverse-governed design pressure. Its role is to make one important thing easier to see: Inverse Atlas is not simply a stricter tone. It is a different design logic. This figure is especially useful because many readers still misclassify the project too early. Without a design contrast figure, they may think they are looking at: - a prompt pack - a cautious wrapper - a style adjustment layer This figure helps stop that misunderstanding. ### Best use Use this figure when you want to explain why the framework should be read as a governance design rather than only as a runtime trick. ### Good for - README theory sections - packaging explanations - product positioning discussions - anti-misclassification sections - “what this is not” explanations ### Main takeaway This figure helps the reader distinguish between surface caution and structural governance design. --- ## 🗺️ Governance Map [Open Governance Map](./inverse_atlas_governance_map.png) This figure shows the operating flow of the Inverse Atlas runtime logic. Its job is to make the internal governance sequence visually legible. That includes the current core structure around: - problem constitution - world alignment - collapse or route estimate - neighboring-cut review - resolution authorization - repair legality - public emission control It also connects the runtime flow to the legal output states. This figure matters because runtime logic can sound abstract in plain text. A strong governance map makes the framework feel like an actual operating order rather than a pile of vocabulary. ### Best use Use this figure when you want to explain how Inverse Atlas works internally. ### Good for - runtime-related pages - paper explanation sections - technical walkthroughs - artifact onboarding - structure explanations ### Main takeaway This is the figure that turns the idea into a readable operating process. --- ## 🌉 Family Positioning [Open Family Positioning](./inverse_atlas_family_positioning.png) This figure is the family-level positioning figure. Its job is to show that Troubleshooting Atlas and Inverse Atlas are not duplicates. Instead, they belong to different layers of the broader atlas family: - Troubleshooting Atlas is route-first - Inverse Atlas is legitimacy-first This figure is extremely important because it prevents one of the most common misunderstandings: that Inverse Atlas is merely a softer or stricter version of the forward atlas It is not. It is a different layer with a different question. ### Best use Use this figure when you want to explain how Inverse Atlas relates to Troubleshooting Atlas and why both lines are needed. ### Good for - dual-layer positioning pages - Twin Atlas pages - family-level architecture explanations - bridge prefaces - README family-positioning sections ### Main takeaway This is the figure that shows why two atlas lines are needed. --- ## 📝 What Each Figure Contributes in One Line If you want the shortest possible memory aid, use this: - [Main Hero](./inverse_atlas_main_hero.png) = establishes public identity - [Order Shift](./inverse_atlas_hero_order_shift.png) = shows the core contrast - [Design Contrast](./inverse_atlas_design_contrast.png) = shows the design difference - [Governance Map](./inverse_atlas_governance_map.png) = shows the runtime order - [Family Positioning](./inverse_atlas_family_positioning.png) = shows the atlas relation That is the fastest correct summary of the current visual layer. --- ## 📄 How These Figures Relate to the Paper The figures and the paper should be understood as companions. The paper provides: - the formal framing - the conceptual definitions - the runtime logic - the dual-layer explanation - the evaluation direction The figures provide: - visual compression - faster intuition - clearer onboarding - better structural memory - easier communication of the same ideas So the figures are not secondary decoration for the paper. They are the visual expression of the same MVP framework. If you are reading the paper, the figures help the architecture click faster. If you are seeing the figures first, the paper helps stabilize what the visuals actually mean. --- ## 🤝 How These Figures Relate to the Runtime Artifacts The figure set also has a direct relation to the runtime layer. The runtime artifacts provide the operating surface: - runtime law - demo behavior - evaluator judgment - case pressure The figures provide the visual explanation of that surface. A simple way to remember it is: - runtime files make the system act - figures make the system visible That is why the figure layer matters even for readers who mainly care about text artifacts. --- ## 🌌 How These Figures Relate to the Larger Atlas Family These figures belong to Inverse Atlas first. But they also matter for the broader family. ### Main Hero Helps establish Inverse Atlas as a real public methodology line. ### Order Shift Helps establish why a legitimacy-first layer is needed at all. ### Design Contrast Helps clarify that Inverse Atlas is not just a style adjustment. ### Governance Map Helps show that Inverse Atlas has internal operating logic, not only slogans. ### Family Positioning Helps establish the conceptual basis of the Twin Atlas direction. This is why the figure layer already has value beyond one folder. It gives public shape to the inverse side of the atlas family. --- ## ✨ Recommended Usage Across Documentation If you want the cleanest way to reuse these figures across documentation, use this pattern: ### Use Main Hero when you need first-contact identity ### Use Order Shift when you need a fast conceptual introduction ### Use Design Contrast when you need anti-misclassification support ### Use Governance Map when you need runtime explanation ### Use Family Positioning when you need family-level positioning This reuse pattern keeps the visual language consistent across pages. --- ## ❗ Common Mistakes to Avoid ### Mistake 1 Treating the figures as decoration only. They are structural communication tools, not just illustrations. ### Mistake 2 Using Family Positioning before the reader understands the basic contrast. For many readers, family-level explanation works better after the core shift is already visible. ### Mistake 3 Using Governance Map without explaining that the output states are legal modes. Without that explanation, the figure may look like a generic state chart instead of a governance map. ### Mistake 4 Using the figures as if they already prove the full bridge layer is complete. They help prepare the architecture visually. They do not by themselves prove that every future layer is already finished. ### Mistake 5 Letting technical file names become the main user-facing language everywhere. The files can keep technical names. The displayed links and descriptions should stay human-readable. --- ## 🌱 If You Only Show Two Figures First If you must choose only two figures for a new reader, start with: 1. [Main Hero](./inverse_atlas_main_hero.png) 2. [Order Shift](./inverse_atlas_hero_order_shift.png) Why? Because that pair gives the fastest combination of: - public presence - conceptual difference If you have room for a third figure, add: 3. [Governance Map](./inverse_atlas_governance_map.png) That three-figure sequence gives the strongest first impression. --- ## 📚 Where to Go Next If you want the operational artifact side, go to: [Runtime Artifacts](../runtime/README.md) If you want the paper companion, go to: [Paper Notes](../paper/README.md) If you want the conceptual relation between the forward atlas and Inverse Atlas, go to: [Dual-Layer Positioning](../dual-layer-positioning.md) If you want the current honesty boundary, go to: [Status and Boundaries](../status-and-boundaries.md) If you want the route-first counterpart, go to: [Problem Map 3.0 Troubleshooting Atlas](../../wfgy-ai-problem-map-troubleshooting-atlas.md) If you want the paired family view, go to: [Twin Atlas](../../Twin_Atlas/README.md) If you want the future handoff direction, go to: [Bridge](../../Twin_Atlas/Bridge/README.md) --- ## 🌱 Final Note The current figure set is already enough to function as a real visual companion layer for the Inverse Atlas MVP. That matters. It means the project is not only explainable in text, but also communicable in visual form. At the same time, the figure layer should still be read with the same honesty boundary as the rest of the MVP: strong enough to teach, explain, and anchor the framework but not yet a claim that every future architectural layer is already complete.