WFGY/ProblemMap/Twin_Atlas/faq.md

<!--
AI_NOTE_START

Document role:
This page is the FAQ entry for WFGY 4.0 Twin Atlas Engine.

What this page is for:
1. Answer the most likely questions new readers will have.
2. Clarify product identity, architecture boundaries, evidence boundaries, and current project status.
3. Reduce confusion between Twin Atlas, Troubleshooting Atlas, Inverse Atlas, Bridge, runtime, evidence, and demo surfaces.
4. Help both vibe coders and serious engineers quickly understand what this engine is trying to do.

How to use this page:
1. Read this page after the Twin Atlas README if you want fast clarification.
2. Use the sections below to jump to product, architecture, evidence, runtime, and demo questions.
3. Expand only the questions you care about.
4. Treat this page as a clarification layer, not as a replacement for the formal specs.

Important boundary:
This page explains the public effective layer of Twin Atlas.
It does not expose hidden internal reasoning substrate details.
It also does not claim that every future closed-loop runtime detail is already fully finished.

Recommended reading path:
1. Twin Atlas README
2. Quickstart
3. Related Documents
4. Bridge README
5. Runtime README
6. Evidence Hub
7. This FAQ

AI_NOTE_END
-->

# ❓ FAQ

> Practical questions and answers for WFGY 4.0 Twin Atlas Engine.

This page exists because Twin Atlas is not a small toy.

It is a large release surface with multiple connected layers:

- Forward Atlas
- Bridge
- Inverse Atlas
- runtime surfaces
- evidence surfaces
- demo surfaces
- raw experiment assets
- future coupling work

That means readers will naturally have a lot of questions.

This page is here to reduce confusion early.

---

## 🔎 Quick Links

| Section | Link |
|---|---|
| Twin Atlas Home | [Twin Atlas](./README.md) |
| Quickstart | [Quickstart](./quickstart.md) |
| Related Documents | [Related Documents](./related-documents.md) |
| Status and Boundaries | [Status and Boundaries](./status-and-boundaries.md) |
| Bridge Home | [Bridge README](./Bridge/README.md) |
| Why Bridge Exists | [Why Bridge Exists](./Bridge/why-bridge-exists.md) |
| Runtime Home | [Runtime README](./runtime/README.md) |
| Runtime Constitution | [Twin Atlas Runtime Constitution](./runtime/twin-atlas-runtime-constitution.md) |
| Inverse Governance Contract | [Inverse Governance Contract](./runtime/inverse-governance-contract.md) |
| State Machine and Output | [State Machine and Output](./runtime/state-machine-and-output.md) |
| Seal and Audit | [Seal and Audit](./runtime/seal-and-audit.md) |
| Evidence Hub | [Evidence Hub](./evidence/README.md) |
| Results Summary | [Results Summary](./evidence/results-summary.md) |
| Governance Stress Suite | [Governance Stress Suite](./evidence/governance-stress-suite.md) |
| Basic Repro Demo | [Basic Repro Demo](./evidence/basic-repro-demo.md) |
| Advanced Clean Protocol | [Advanced Clean Protocol](./evidence/advanced-clean-protocol.md) |
| Flagship Cases | [Flagship Cases](./evidence/flagship-cases.md) |
| Methodology Boundary | [Methodology Boundary](./evidence/methodology-boundary.md) |
| Raw Runs | [Raw Runs](./evidence/raw-runs/) |
| Figures | [Figures README](./figures/README.md) |
| Demos | [Demos README](./demos/README.md) |
| Forward Atlas | [Problem Map 3.0 Troubleshooting Atlas](../wfgy-ai-problem-map-troubleshooting-atlas.md) |
| Inverse Atlas Home | [Inverse Atlas README](../Inverse_Atlas/README.md) |

---

# 🧭 Section 1 · Product Identity

<details>
<summary>❓ What is WFGY 4.0 Twin Atlas Engine in one sentence?</summary>

> WFGY 4.0 Twin Atlas Engine is a route-aware and authorization-aware reasoning engine for hard reasoning tasks.
>
> In simple terms, it tries to improve both:
>
> 1. where the system looks first  
> 2. whether the system has actually earned the right to conclude that strongly yet

</details>

<details>
<summary>❓ Is Twin Atlas just two documents placed next to each other?</summary>

> No.
>
> Twin Atlas is not meant to be understood as two random pages sitting side by side.
>
> It is the engine framing that brings together:
>
> - Forward Atlas / Troubleshooting Atlas
> - Inverse Atlas
> - Bridge as the internal handoff layer between them
>
> So the point is not coexistence.
>
> The point is disciplined interaction.

</details>

<details>
<summary>❓ Why is it called Twin Atlas?</summary>

> It is called Twin Atlas because the architecture has two major atlas wings with mirrored but different roles.
>
> The forward side is route-first.
>
> The inverse side is legitimacy-first.
>
> They are not identical twins.
>
> They are complementary twins.

</details>

<details>
<summary>❓ Why is it called an engine and not just a prompt pack?</summary>

> Because the architecture is doing more than supplying a style hint.
>
> A prompt pack usually nudges wording or behavior.
>
> Twin Atlas is trying to define:
>
> - route discipline
> - authorization discipline
> - repair discipline
> - handoff discipline
> - runtime structure
> - evidence structure
> - demo proof surfaces
>
> That is engine-like behavior, not just wording decoration.

</details>

<details>
<summary>❓ What kind of users is this for?</summary>

> It is especially for people who care about high-cost reasoning mistakes.
>
> That includes:
>
> - vibe coders who build fast and need better structural discipline
> - engineers debugging hard failures
> - RAG builders
> - agent workflow builders
> - researchers
> - people analyzing thin-evidence cases
> - people who do not want wrong-first-fix to blow up downstream cost

</details>

<details>
<summary>❓ Is this meant for ordinary casual chat?</summary>

> Not primarily.
>
> You can still understand the architecture in lighter ways.
>
> But Twin Atlas becomes most valuable when:
>
> - ambiguity matters
> - strong output can be costly
> - wrong-first-fix can waste time or money
> - evidence is incomplete
> - the user is pushing for premature closure

</details>

---

# 🏗️ Section 2 · Architecture Basics

<details>
<summary>❓ What are the main parts of Twin Atlas?</summary>

> At the public effective-layer level, Twin Atlas is built around:
>
> - Forward Atlas
> - Bridge
> - Inverse Atlas
>
> Forward Atlas improves the first structural cut.
>
> Bridge carries that value forward as weak priors.
>
> Inverse Atlas decides whether stronger visible output is lawful yet.

</details>

<details>
<summary>❓ What does Forward Atlas do?</summary>

> Forward Atlas is the route-first side.
>
> It tries to answer:
>
> - what is the strongest current route
> - what is the nearest competing route
> - what is the likely broken invariant
> - what is the safest useful first move
>
> In plain language, it tries to stop the system from looking in the wrong place first.

</details>

<details>
<summary>❓ What does Inverse Atlas do?</summary>

> Inverse Atlas is the legitimacy-first side.
>
> It asks whether the system has actually earned the right to output a strong answer yet.
>
> It is especially concerned with:
>
> - over-resolution
> - fake closure
> - unsupported specificity
> - fake repair legality
> - visible output exceeding the lawful support ceiling

</details>

<details>
<summary>❓ What does Bridge do?</summary>

> Bridge is the internal handoff layer.
>
> Its job is not to answer and not to authorize.
>
> Its job is to:
>
> - preserve route value from the forward side
> - pass that value forward as weak priors only
> - avoid hidden inflation
> - avoid hidden ambiguity deletion
> - keep the inverse layer necessary
>
> A good Bridge packet is useful, but not prematurely final.

</details>

<details>
<summary>❓ Why not skip Bridge and go directly from Forward Atlas to Inverse Atlas?</summary>

> Because direct transfer can easily become sloppy.
>
> Without a disciplined handoff layer, one of two bad things often happens:
>
> - route value gets lost
> - route value gets over-upgraded into fake certainty
>
> Bridge exists to prevent both.

</details>

<details>
<summary>❓ Is Bridge the same thing as a third atlas?</summary>

> No.
>
> Bridge is important, but it is not a third atlas line in the same sense.
>
> It is the coupling layer inside the Twin Atlas family.
>
> That means its job is narrower:
>
> - preserve
> - translate
> - hand off
>
> not
>
> - authorize
> - finalize
> - judge legality on its own

</details>

<details>
<summary>❓ What is the simplest mental model of the architecture?</summary>

> A simple mental model is:
>
> - Forward Atlas = the map
> - Inverse Atlas = the permission system
> - Bridge = the handoff core between them
> - Runtime = the usable public surface
>
> That model is simple, and still mostly correct.

</details>

---

# 🌫️ Section 3 · Why This Engine Matters

<details>
<summary>❓ What problem is Twin Atlas actually trying to solve?</summary>

> It is trying to solve a specific class of reasoning failures where systems:
>
> - cut into the wrong structural region
> - become too certain too early
> - erase lawful ambiguity
> - present a next move as if it were already structurally proven
>
> The key idea is that many failures are not just “wrong answers.”
>
> They are “wrong answers produced too confidently and too early.”

</details>

<details>
<summary>❓ Why is route-first reasoning alone not enough?</summary>

> Because a better route guess does not automatically justify stronger output.
>
> A system can still:
>
> - over-resolve
> - over-speak
> - fake subtype certainty
> - fake structural repair
>
> even if its route guess is somewhat better.
>
> That is why route discipline alone is not enough.

</details>

<details>
<summary>❓ Why is caution alone not enough?</summary>

> Because “being careful” without a good structural cut can still be weak.
>
> A system may avoid strong claims, but still:
>
> - fail to identify the main route
> - fail to identify the broken invariant
> - fail to improve the next move
>
> Twin Atlas is not trying to become vague.
>
> It is trying to become disciplined.

</details>

<details>
<summary>❓ Why do you keep saying “lawful” instead of just “careful”?</summary>

> Because “careful” is too vague.
>
> A careful-sounding answer can still:
>
> - leak fake specificity
> - hide unsupported assumptions
> - quietly spend too much certainty
>
> “Lawful” here means:
>
> the visible answer should not outrun what the structure and evidence have actually earned.

</details>

<details>
<summary>❓ Is Twin Atlas mainly about being conservative?</summary>

> No.
>
> It is not trying to be weak, timid, or uselessly hesitant.
>
> The goal is:
>
> - strong when earned
> - coarse when needed
> - unresolved when lawful
> - still operationally useful
>
> A strong Twin Atlas answer is not smaller because it is scared.
>
> It is smaller because it refuses fake closure.

</details>

---

# 🌉 Section 4 · Bridge Questions

<details>
<summary>❓ Is Bridge already fully implemented?</summary>

> Not in the sense of a complete final operating layer.
>
> What is already present is:
>
> - a clear architectural role
> - a formal v1 direction
> - examples and notes
> - a strong design target for future implementation
>
> So Bridge is already real at the specification layer, but not yet fully complete at every future runtime detail.

</details>

<details>
<summary>❓ What is Bridge supposed to do right now?</summary>

> Bridge is supposed to be a disciplined advisory-only coupling layer.
>
> It should:
>
> - accept forward-side route structure
> - normalize it
> - preserve important signals
> - pass it forward as weak priors
> - avoid hidden inflation
> - avoid hidden deletion
> - leave the inverse side necessary

</details>

<details>
<summary>❓ What is Bridge not allowed to do?</summary>

> Bridge should not:
>
> - authorize stronger visible output
> - finalize route truth
> - finalize repair legality
> - silently upgrade fit level
> - silently strengthen confidence
> - erase a live neighboring route for neatness
>
> If it does those things, it stops being a handoff layer and starts acting like an uninvited judge.

</details>

<details>
<summary>❓ Why is misrepair shadow such a big deal?</summary>

> Because many bad reasoning systems do not only miss the right path.
>
> They also confidently choose the wrong first repair.
>
> Misrepair shadow helps preserve:
>
> - the tempting wrong-first-fix
> - the likely expensive wrong move
> - the caution signal the next layer should still see
>
> That is a lot more useful than passing route alone.

</details>

<details>
<summary>❓ Why must Bridge fail closed sometimes?</summary>

> Because fake helpfulness is dangerous here.
>
> If the input packet is structurally invalid, Bridge should reject instead of inventing legality.
>
> A fake smooth packet is worse than an honest reject.

</details>

<details>
<summary>❓ Why does Bridge matter so much for the whole engine?</summary>

> Because Twin Atlas is trying to become more than coexistence.
>
> Forward Atlas and Inverse Atlas are both strong.
>
> But without disciplined handoff:
>
> - route value can be lost
> - authorization can be polluted
> - ambiguity can be erased
> - repair can be over-upgraded
>
> Bridge is where that risk is controlled.

</details>

---

# 🧪 Section 5 · Evidence Questions

<details>
<summary>❓ Is WFGY 4.0 evidence meant to be a universal benchmark?</summary>

> No.
>
> The current evidence layer is best understood as:
>
> - a reproducible governance stress demo
> - a targeted governance stress surface
>
> It is not claiming universal benchmark dominance across all tasks and all domains.
>
> Its target is narrower and more specific:
>
> whether a model overcommits beyond what the evidence has actually earned under pressure.

</details>

<details>
<summary>❓ What is the evidence layer actually trying to show?</summary>

> The evidence layer is trying to show that:
>
> - baseline systems often overcommit under forced-choice pressure
> - WFGY 4.0 can pull the output back toward a more lawful release level
>
> In practical terms, that usually means:
>
> - less illegal commitment
> - less evidence-boundary violation
> - less fake closure
> - more lawful downgrade

</details>

<details>
<summary>❓ Why are raw runs public?</summary>

> Because transparency matters.
>
> The raw TXT files are there as:
>
> - raw experiment records
> - model-specific traces
> - prompt-visible assets
> - reproducibility helpers
>
> They are not being presented as universal proof by themselves.
>
> The healthiest reading posture is:
>
> summary first, raw runs visible, rerun encouraged.

</details>

<details>
<summary>❓ Do all models react to WFGY 4.0 in exactly the same way?</summary>

> No.
>
> Many visible runs point in the same general direction:
>
> - less overcommitment
> - more lawful downgrade
>
> But that does not mean every model family internalizes the governance layer in exactly the same way.
>
> Outliers matter, and they should be read honestly.

</details>

<details>
<summary>❓ What is the strongest fair public claim right now?</summary>

> The strongest safe public claim is:
>
> WFGY 4.0 provides a reproducible governance stress surface showing that many baseline assistants overcommit under pressure, while WFGY 4.0 tends to push outputs back toward more lawful downgrade, ambiguity preservation, and ceiling-respecting release.
>
> That is already a strong claim.
>
> It does not need inflation.

</details>

<details>
<summary>❓ Why does the project need both Basic Repro Demo and Advanced Clean Protocol?</summary>

> Because they solve different problems.
>
> Basic Repro Demo is for:
>
> - speed
> - screenshots
> - first-contact public understanding
>
> Advanced Clean Protocol is for:
>
> - cleaner separation
> - lower contamination criticism
> - stronger reviewer confidence
> - a harder-to-dismiss protocol posture
>
> They are complementary, not redundant.

</details>

---

# 🎭 Section 6 · Demo Questions

<details>
<summary>❓ Why is there a whole demos folder?</summary>

> Because if Twin Atlas really matters, the difference should become visible.
>
> Not just in theory.
>
> Not just in specs.
>
> Not just in release notes.
>
> The demo layer is the public proof surface.

</details>

<details>
<summary>❓ What is the demo layer trying to show?</summary>

> It is trying to show that Twin Atlas is not just a different writing style.
>
> A good demo should make visible:
>
> - better route discipline
> - better authorization discipline
> - better repair discipline
>
> especially in realistic hard cases where a baseline naturally overcommits.

</details>

<details>
<summary>❓ Is the demo layer the same thing as the full evidence layer?</summary>

> No.
>
> The demo layer is the public-facing visible proof surface.
>
> The broader evidence layer also includes:
>
> - results summary
> - governance stress suite
> - methodology boundary
> - raw runs
>
> So demos are one important part of evidence, but not the whole evidence stack.

</details>

<details>
<summary>❓ Is the demo trying to make the baseline look stupid?</summary>

> No.
>
> A good Twin Atlas demo should beat a plausible baseline, not a straw dummy.
>
> If the baseline looks absurdly incompetent, the demo is weak.
>
> The point is to show a realistic failure mode, not to cheat.

</details>

<details>
<summary>❓ What does a good Twin Atlas demo win actually look like?</summary>

> A real win looks like:
>
> - better route honesty
> - better ambiguity preservation
> - less illegal detail
> - safer next move
> - less fake repair finality
>
> It should not win only by sounding calmer.

</details>

<details>
<summary>❓ Why is “lawful under uncertainty” such a big phrase here?</summary>

> Because a lot of hard reasoning failures happen exactly when the evidence is incomplete.
>
> The question is not whether the system can say something.
>
> The question is whether it can avoid saying more than the structure has earned.

</details>

---

# ⚙️ Section 7 · Runtime Questions

<details>
<summary>❓ What is the runtime folder for?</summary>

> The runtime folder is the practical entry layer.
>
> It is where Twin Atlas starts becoming usable as a public runtime surface rather than staying only as architecture.

</details>

<details>
<summary>❓ Why is runtime not the same thing as the hidden substrate?</summary>

> Because the runtime layer is part of the public effective layer.
>
> It is meant to be usable and inspectable without exposing the hidden internal reasoning substrate directly.

</details>

<details>
<summary>❓ What is the runtime constitution for?</summary>

> The runtime constitution is the public engine skeleton.
>
> It shows:
>
> - the major runtime layers
> - their role boundaries
> - how information should move
> - how output stays below unsupported strength
> - how the system avoids silent upgrade and collapse
>
> It is where Twin Atlas starts looking like a governed engine rather than only an idea.

</details>

<details>
<summary>❓ What is the Inverse Governance Contract for?</summary>

> It explains the legitimacy-first side in practical runtime form.
>
> That includes:
>
> - authorization
> - repair legality
> - ceiling discipline
> - downgrade logic
> - restart logic
>
> In simple terms, it governs how much answer has actually been earned.

</details>

<details>
<summary>❓ What is the State Machine and Output page for?</summary>

> It explains how Twin Atlas behaves as a governed runtime.
>
> It separates:
>
> - route-fit
> - authorization
> - repair-legality
> - final output discipline
>
> That separation matters because those things should not collapse into one vague “reasoning state.”

</details>

<details>
<summary>❓ What is Seal and Audit for?</summary>

> Seal and Audit is the anti-self-deception layer.
>
> It protects the system from:
>
> - silent upgrade
> - overclaim
> - lazy compression
> - layer collapse
> - prettier wording pretending to be stronger legitimacy
>
> It is part of the engine, not decorative cleanup.

</details>

---

# 🧠 Section 8 · Product Strategy and Roadmap

<details>
<summary>❓ What is already finished enough to talk about publicly?</summary>

> It is fair to say that:
>
> - Twin Atlas has a clear identity
> - its architecture is already meaningful
> - Bridge has a real public role
> - the runtime layer already has a usable public shape
> - the evidence layer already has a real public surface
> - the demo layer already serves as visible proof
>
> These are strong claims, but still disciplined.

</details>

<details>
<summary>❓ What should not be claimed yet?</summary>

> It would be careless to claim that:
>
> - every Bridge runtime detail is already complete
> - every future de-escalation path is already finalized
> - the full closed-loop engine is already fully finished in every technical sense
> - the evidence layer already proves universal superiority in every environment
>
> The architecture is already real.
>
> But honesty still matters.

</details>

<details>
<summary>❓ Is the project currently in concept mode or build mode?</summary>

> It is already beyond pure concept mode.
>
> At this point, the project has:
>
> - a product identity
> - architecture docs
> - Bridge docs
> - runtime entry surfaces
> - evidence surfaces
> - raw run assets
> - demo surfaces
>
> So this is much closer to build mode than pure concept mode.

</details>

<details>
<summary>❓ What is the next big step after the public pages are filled in?</summary>

> The next big step is moving deeper into:
>
> - stronger coupling work
> - more implementation-facing structure
> - stronger runtime handoff
> - better figure surfaces
> - cleaner advanced evaluation loops
>
> In short:
>
> the next step is not inventing a new identity.
>
> It is deepening the current engine direction.

</details>

<details>
<summary>❓ Will Twin Atlas eventually become more mathematically formalized?</summary>

> Very likely yes, but that belongs to a later phase.
>
> There is a difference between:
>
> - MVP release surface
> - implementation-facing coupling design
> - deeper formalization
> - full higher-order mathematical packaging
>
> Those should not all be forced into the same stage.

</details>

<details>
<summary>❓ Does Twin Atlas need full formal math before MVP?</summary>

> No.
>
> MVP should not be blocked by the total formal endpoint.
>
> The practical engine, proof surface, and runtime entry layer should mature first.
>
> Deeper formalization can continue in parallel or later.

</details>

---

# 💻 Section 9 · Vibe Coder and Engineer Questions

<details>
<summary>❓ Why would a vibe coder care about this instead of just asking the model normally?</summary>

> Because “just ask normally” often works until it suddenly becomes expensive.
>
> A vibe coder especially benefits when:
>
> - the first cut is wrong
> - the first fix is wrong
> - the model sounds convincing too early
> - the architecture becomes hard to steer
>
> Twin Atlas tries to improve that without requiring full formal methods every time.

</details>

<details>
<summary>❓ Why would an engineer care if this sounds kind of philosophical?</summary>

> Because underneath the naming, the actual concerns are extremely engineering-relevant:
>
> - route selection
> - ambiguity handling
> - broken invariant targeting
> - repair discipline
> - visible output ceiling
> - fail-closed behavior
>
> Those are not fluffy concerns.
>
> They are directly tied to cost, debugging quality, and downstream safety.

</details>

<details>
<summary>❓ Is this meant to replace engineering judgment?</summary>

> No.
>
> It is meant to improve how model-assisted reasoning behaves before engineering judgment is applied.
>
> A strong human operator is still important.
>
> Twin Atlas is trying to make the model’s first structural behavior more useful and less misleading.

</details>

<details>
<summary>❓ Is this meant to replace benchmarks?</summary>

> No.
>
> It is not a benchmark replacement.
>
> It is an architecture, governance, and runtime discipline layer.
>
> Benchmarks can still matter.
>
> Twin Atlas is trying to improve the shape of reasoning and action under ambiguity.

</details>

<details>
<summary>❓ Is this only useful for debugging?</summary>

> No.
>
> Debugging is one of the clearest use cases.
>
> But the same logic also matters in:
>
> - RAG analysis
> - workflow reasoning
> - agent-path diagnosis
> - scientific interpretation
> - research reasoning
> - any case where stronger output can outrun support

</details>

---

# 🚀 Section 10 · Practical Use Questions

<details>
<summary>❓ What should I read first if I only have 5 minutes?</summary>

> Read in this order:
>
> 1. Twin Atlas README  
> 2. Quickstart  
> 3. Results Summary  
> 4. Bridge README  
> 5. Runtime README
>
> That is the shortest useful path.

</details>

<details>
<summary>❓ What should I read first if I care about architecture?</summary>

> Read in this order:
>
> 1. Twin Atlas README  
> 2. Related Documents  
> 3. Bridge README  
> 4. Why Bridge Exists  
> 5. Runtime README  
> 6. Runtime Constitution

</details>

<details>
<summary>❓ What should I read first if I care about visible proof?</summary>

> Read in this order:
>
> 1. Evidence Hub  
> 2. Results Summary  
> 3. Flagship Cases  
> 4. Basic Repro Demo  
> 5. Advanced Clean Protocol

</details>

<details>
<summary>❓ What should I read first if I want to try it immediately?</summary>

> Start here:
>
> 1. Quickstart  
> 2. Runtime README  
> 3. Evidence Hub  
>
> Then choose whether you want:
>
> - route-first reading
> - governance-first reading
> - runtime-first reading
> - evidence-first reading
>
> That is the healthiest first adoption posture right now.

</details>

<details>
<summary>❓ What is the safest way to adopt Twin Atlas gradually?</summary>

> A simple path is:
>
> - start with the main README
> - use Quickstart to choose your path
> - use Results Summary to understand the evidence quickly
> - move into runtime and Bridge once the main idea clicks
>
> That gives you a cleaner adoption ladder than trying to read everything at once.

</details>

<details>
<summary>❓ If I only remember one practical rule, what should it be?</summary>

> Do not spend more certainty than the structure has actually earned.
>
> That one rule alone already gets you surprisingly far.

</details>

---

# ✨ Final quick summary

<details>
<summary>❓ So what is Twin Atlas really trying to become?</summary>

> Twin Atlas is trying to become a reasoning engine that can:
>
> - cut into the right structural region earlier
> - preserve lawful ambiguity longer
> - resist fake closure
> - avoid fake structural repair
> - give safer next moves under uncertainty
>
> In short:
>
> not just a model that answers,
>
> but a model-assisted reasoning layer that knows when stronger output has not been earned yet.

</details>