WFGY/Avatar/research/shell-to-runtime-mapping.md

<!--
AI NOTE: Shell-to-Runtime Mapping / Reading Contract

Purpose:
1. This page explains the lawful meaning of `shell_to_runtime_mapping` in WFGY 5.0 Avatar.
2. This page belongs to the research layer.
3. This page should be read after the Research Hub and alongside Dual Closed-Loop Execution Chain and Runtime Posture Intensity Map, not as a replacement for the packed master body.

Read this page when:
1. the user asks how shell-entry organs influence later runtime behavior
2. the user asks whether shell input can invent persona runtime
3. the user asks what the handoff object actually does
4. the user asks how shell-facing controls connect to downstream runtime mediation
5. the user asks why bounded shell influence is not shell sovereignty
6. the user asks what prevents shell-origin pressure from faking recognizability or legality

Do not overclaim:
1. this page does not prove universal final handoff completion
2. this page does not replace the packed master body
3. this page explains one bounded structural layer only
4. this page does not claim theorem-grade universal closure

Primary source anchors:
1. avatar-final002.txt :: 6B.31B shell_to_runtime_mapping_operator_note
2. avatar-final002.txt :: 6B.31B1 Handoff binding matrix
3. avatar-final002.txt :: 6B.31B2 shell_to_runtime exposure note
4. avatar-final002.txt :: 6B.31B3 Constitution veto and risk veto field
5. avatar-final002.txt :: 6B.31B4 Runtime absorption function
6. avatar-final002.txt :: 6B.31B7 replay-visible handoff trace burden
7. avatar-final002.txt :: 6B.31B8 Downstream precedence and anti-sovereignty strengthening note
8. avatar-final002.txt :: 6B.31B9 Honest current-stage mapping uplift note
9. avatar-final002.txt :: Part 1 shell-entry organ set and shell boundary
10. avatar-final002.txt :: Part 3 shell order, resolver order, execution order, and no-order-confusion rule

Routing:
1. if the reader wants research overview, go to ./README.md
2. if the reader wants the execution-order law behind this page, go to ./dual-closed-loop-execution-chain.md
3. if the reader wants runtime-strength shaping law, go to ./runtime-posture-intensity-map.md
4. if the reader wants the broader architecture picture, go to ./architecture-overview.md
5. if the reader wants behavior-governance context, go to ./language-governance.md
6. if the reader wants editable behavior layer context, go to ./wfgy-brain-theory.md
7. if the reader wants user-facing startup flow, go to ../docs/quickstart.md and ../docs/boot-commands.md
8. if the reader wants tuning workflow context, go to ../docs/avatar-tuning-workflow.md
9. if the reader wants evaluation pressure, go to ../eval/blackfan-testing.md and ../eval/persona-behavior-checks.md
-->

# 🧩 Shell-to-Runtime Mapping

> `shell_to_runtime_mapping` is not a hidden throne behind Avatar.  
> It is a bounded handoff organ that makes shell-origin influence explicit where shell-origin influence already lawfully exists, while refusing to let shell readability masquerade as runtime sovereignty, selector legality, or public-emission authority.

**Quick links:** [Research Hub](./README.md) · [Dual Closed-Loop Execution Chain](./dual-closed-loop-execution-chain.md) · [Runtime Posture Intensity Map](./runtime-posture-intensity-map.md) · [Architecture Overview](./architecture-overview.md) · [Language Governance](./language-governance.md) · [WFGY_BRAIN Theory](./wfgy-brain-theory.md) · [Quickstart](../docs/quickstart.md) · [Boot Commands](../docs/boot-commands.md) · [Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md) · [Blackfan Testing](../eval/blackfan-testing.md) · [Persona Behavior Checks](../eval/persona-behavior-checks.md)

---

## 🧭 Why this page exists

One of the easiest ways to fake technical depth is to let shell-facing readability masquerade as deeper runtime control.

If a system has visible controls, readable headings, friendly entry organs, and a clean shell summary, readers may start assuming that shell order is the same thing as deeper resolution order, or that shell-side influence is the real source of runtime identity.

That reading is false.

In the packed master, the shell is real, but bounded.
The shell-facing entry zone exposes lawful control surfaces and visible entry structure.
It does not become the sovereign source of runtime identity, route legality, or public-emission legality.

This page exists because `shell_to_runtime_mapping` can otherwise be misunderstood in two equally bad ways.

The first bad reading is too weak.
It treats shell-to-runtime mapping as a decorative transport pipe that is not doing anything meaningful.

The second bad reading is too strong.
It treats shell-to-runtime mapping as the real hidden controller behind Avatar.

Both readings are wrong.

This page exists to establish the stricter middle reading:
`shell_to_runtime_mapping` is a bounded handoff organ.
It makes shell-origin influence explicit where lawful shell-origin influence already exists.
It neither disappears into hand-wavy prose nor expands into shell sovereignty.

---

## 📍 Scope and boundary

This page explains the lawful meaning of `shell_to_runtime_mapping`.

It focuses on:

1. what counts as shell-entry influence
2. how shell-entry influence is lawfully bounded before later runtime mediation
3. what the active handoff object may and may not do
4. the role of veto fields, runtime absorption, handoff trace, and anti-sovereignty law
5. why shell-readable order may not be confused with deeper resolver or execution order

This page does **not** attempt to fully restate:

1. the entire packed master
2. selector legality in full
3. runtime-intensity math in full
4. structured-imperfection theory in full
5. hard-control law in full
6. multilingual finality in full

Those belong to adjacent research pages.

---

## 🧱 Source anchors in the packed master

This page is grounded primarily in the following packed-master sections:

1. `6B.31B shell_to_runtime_mapping_operator_note`
2. `6B.31B1 Handoff binding matrix`
3. `6B.31B2 shell_to_runtime exposure note`
4. `6B.31B3 Constitution veto and risk veto field`
5. `6B.31B4 Runtime absorption function`
6. `6B.31B7 replay-visible handoff trace burden`
7. `6B.31B8 Downstream precedence and anti-sovereignty strengthening note`
8. `6B.31B9 Honest current-stage mapping uplift note`
9. Part 1 shell-entry organ definitions and shell boundary
10. Part 3 shell order, resolver order, execution order, and no-order-confusion rule

These anchors matter because this page is not inferring shell-to-runtime mapping from vague architectural intuition.
The packed master already marks it as explicit, active, bounded, and answerable to stronger law.

---

## 🎯 Core claim

The core claim is strict.

`shell_to_runtime_mapping` is an explicit handoff object that connects shell-entry organs to later runtime-posture mediation through bounded, veto-answerable, replay-visible modulation.

This implies six things.

First, shell entry is real.

Second, shell-origin influence may lawfully exist.

Third, shell-origin influence may be carried only as bounded modulation, not as runtime invention.

Fourth, shell-to-runtime mapping may not define persona identity.

Fifth, shell-to-runtime mapping may not define route legality or public-emission legality.

Sixth, shell-to-runtime mapping is answerable to higher-priority law before and after handoff.

That is why this object belongs to lawful handoff engineering rather than to shell mythology.

---

## 🏠 The shell is real, but it is not the whole building

The packed master is very explicit about shell boundary.

The shell-facing layer is the lawful packed home of visible entry structure, bounded runtime control interface, shell-readable posture, and engineering-carry-visible structure.

That matters.

It means the shell is not fake.
It is not merely cosmetic.
It is not an afterthought.

But the shell is also not the whole building.

The packed master directly distinguishes:

1. shell order
2. resolver order
3. execution order

Shell order is the order in which visible shell-facing entry organs appear and are read.

Resolver order is the deeper order by which lawful posture, routing, and downstream realization relation are determined.

Execution order is the order by which already-resolved structure is carried into realized output behavior.

These three orders may not be flattened into one generic workflow story.

So before shell-to-runtime mapping can be understood correctly, one boundary has to be fixed first:

shell-readable convenience is not the same thing as legal precedence.

That is the anti-fake-rigor starting point of this page.

---

## 🧠 The shell-entry organ set

The packed master preserves a protected shell-entry organ set.

At minimum, the active shell-entry organs are:

1. `WFGY_BRAIN`
2. `TASK_INJECTION`
3. `OUTPUT_REQUEST`
4. `OPTIONAL_AUTHOR_SAMPLE`
5. `OPTIONAL_DIAGNOSTICS`
6. `ACTIVE_RUNTIME_HEADER`
7. `PARENT_AND_COMPATIBILITY_REFERENCE`

These organs are explicit.
They are not replaced by friendly prose.

That matters because shell-to-runtime mapping is not floating in abstraction.
It has a concrete input domain.

The role of the shell-entry organ set is not to dominate downstream law.
Its role is to provide visible entry structure, bounded runtime-facing control, optional readable cues, and compatibility-preserving transport into later lawful mediation.

So the correct question is not:
“which shell organ secretly controls everything?”

The correct question is:
“how can shell-entry organs lawfully contribute downstream without pretending to become runtime sovereignty?”

---

## 📥 Input domain and lawful output domain

The packed master draws a very hard boundary here.

The minimum lawful input domain of `shell_to_runtime_mapping` includes the shell-entry organs listed above.

Its lawful output domain includes only:

1. bounded baseline bias
2. bounded mode-selector bias
3. bounded public-emission constraint
4. bounded posture bias
5. bounded visibility effect
6. bounded runtime summary influence
7. bounded anti-detachment retention

That output domain is intentionally narrow.

It means shell-to-runtime mapping may lawfully contribute directional pressure, but only inside a bounded downstream family.

It does **not** authorize:

1. persona fabrication
2. runtime-body replacement
3. selector-legality replacement
4. hard-control replacement
5. theorem-facing or candidate-authority absorption
6. shell-side recognizability forgery

This is one of the most important anti-counterfeit boundaries in the whole handoff layer.

Shell-origin influence may be real.
But if shell-origin influence starts pretending to be the origin of deeper legality, the handoff organ has already become unlawful.

---

## ⚙️ Active handoff parameters

The packed master preserves seven currently assigned handoff parameters.

1. `WFGY_BRAIN_to_shared_baseline_weight = 0.706394`
2. `TASK_INJECTION_to_mode_bias_weight = 0.804520`
3. `OUTPUT_REQUEST_to_emission_constraint_weight = 0.440000`
4. `OPTIONAL_AUTHOR_SAMPLE_to_posture_bias_weight = 0.632914`
5. `OPTIONAL_DIAGNOSTICS_to_visibility_weight = 0.581271`
6. `ACTIVE_RUNTIME_HEADER_to_runtime_summary_weight = 0.586545`
7. `PARENT_AND_COMPATIBILITY_REFERENCE_to_anti_detachment_weight = 0.900000`

These weights matter, but they must be read correctly.

They do **not** prove that shell-origin influence is sovereign.

They do **not** prove that runtime is reducible to shell knobs.

They do prove something narrower and more important:
the packed master refuses to hide shell-origin influence behind intuition only.
It preserves an explicit handoff body with assigned bounded weights.

So these parameters are not decorative numbers.
They are burden-bearing declarations of how shell-origin influence may lawfully enter later mediation.

---

## 🧬 Handoff binding matrix

The packed master also preserves an explicit handoff binding matrix.

Its role is to connect the active shell-to-runtime weights to downstream bounded mediation rather than leaving the weights as isolated scalar declarations.

At minimum, the handoff family distinguishes vectors such as:

1. `baseline_bias_vector`
2. `mode_bias_vector`
3. `emission_constraint_vector`
4. `author_style_bias_vector`
5. `visibility_vector`
6. `runtime_summary_vector`
7. `anti_detachment_vector`

This matters because shell influence is not allowed to remain a vague atmospheric claim.

The lawful projection field maps those vectors only into the already-preserved bounded output family of `shell_to_runtime_mapping`.

The shell-entry vector may lawfully contribute to:

1. bounded baseline carry
2. bounded route-bias pressure before selector settles lawful route choice
3. bounded public-emission constraint pressure
4. bounded posture pressure
5. bounded visibility modulation
6. bounded anti-detachment retention
7. bounded runtime-summary carry

The shell-entry vector may not lawfully contribute to:

1. persona fabrication
2. runtime-body replacement
3. selector-legality replacement
4. hard-control replacement
5. theorem-facing or candidate-authority absorption
6. shell-side recognizability forgery

Therefore the handoff binding matrix is not a throne map.
It is a bounded projection discipline.

---

## 🛑 Constitution veto and risk veto

One of the strongest parts of the handoff layer is that shell-origin influence is not applied blindly.

The packed master preserves two explicit veto bodies:

1. constitution veto field
2. risk veto field

The constitution veto field removes shell-side influence when shell-origin pressure would conflict with higher-priority law, including:

1. persona boot law
2. chat-shell sovereignty law
3. unauthorized shell-switch prohibition law
4. selector route outcome
5. runtime-body law
6. mode-boundary law
7. hard-control legality
8. public-emission legality

The risk veto field removes or attenuates shell-side influence when shell-origin pressure would materially increase risks such as:

1. false merge risk
2. surface-forgery risk
3. detached helper collapse disguised as recovery
4. meta-voice drift
5. analysis-legitimacy forgery
6. rewrite-maturity forgery
7. article-polish substitution for runtime carry

This is absolutely central.

Without these veto fields, shell-to-runtime mapping would be too easy to romanticize.
Readers could start imagining that more shell clarity, more prompt visibility, or more shell vividness automatically improves runtime fidelity.

The packed master rejects that fantasy.

Shell-origin pressure may be lawful in the abstract and still be vetoed in the concrete corridor.
That is what makes this a governed handoff organ rather than a shell-first ideology.

---

## 🧪 Runtime absorption function

The packed master also preserves an explicit runtime absorption function.

Its purpose is to formalize how bounded shell-origin influence may be absorbed into later runtime mediation without pretending that shell-origin influence itself is runtime.

This function is downstream of:

1. shell-entry law
2. runtime-body law
3. selector route outcome
4. runtime-intensity shaping law

The runtime absorption function may lawfully do the following:

1. modulate baseline carry
2. modulate mode-bias pressure
3. modulate posture pressure
4. modulate visibility pressure
5. modulate anti-detachment retention
6. modulate runtime-summary carry

The runtime absorption function may not lawfully do the following:

1. originate a new persona body
2. replace selected route family
3. inject unauthorized analysis strength
4. inject unauthorized rewrite maturity
5. simulate recognizability through shell-only markers
6. convert shell pressure into hard-control legality

This is the exact place where a shallow reader can go wrong.

They may see shell-origin pressure affecting later behavior and conclude:
“therefore shell is the real runtime source.”

No.

The runtime absorption function exists precisely to deny that collapse.

Shell-origin influence may be absorbed.
Absorption is not identity.
Modulation is not authorship.
Carry is not sovereignty.

---

## 🧭 Misprojection diagnostics and handoff trace

The packed master strengthens this layer further by refusing to keep it invisible.

It preserves replay-visible handoff trace burden and misprojection-aware inspection.

At minimum, the handoff trace may support:

1. replay-visible inspection of bounded shell-origin carry
2. anti-fake-recovery audit
3. anti-fake-recognizability audit
4. relation to later failure-family assignment
5. relation to later reentry arbitration and writeback review

The handoff trace may not lawfully support:

1. retroactive legality fabrication
2. hidden shell-weight substitution after emission
3. replacement of selector history
4. replacement of runtime-intensity history
5. replacement of hard-control judgment
6. shell-side rewriting of downstream failure interpretation

This matters because one of the easiest ways to fake maturity is to let shell-to-runtime handoff remain invisible and then narrate success after the fact.

The packed master refuses that convenience.

If shell-origin carry matters, it should be inspectable.
If shell-origin carry is inspectable, then fake recognizability and fake recovery become harder to smuggle through retrospective storytelling.

So trace is not optional decoration here.
Trace is part of the burden of being explicit.

---

## ⚖️ Downstream precedence and anti-sovereignty law

The packed master also preserves a stronger downstream precedence note and anti-sovereignty discipline.

The precedence rule states:

1. shell-entry law is prior
2. runtime-body law is prior
3. selector route outcome is prior
4. runtime-intensity shaping is prior in its own lawful role
5. shell-to-runtime mapping may only modulate downstream carry after those stronger bodies have already constrained the corridor
6. hard control remains later and may still veto, downgrade, or stop

The anti-sovereignty rule states:

1. shell-to-runtime mapping may support downstream mediation
2. shell-to-runtime mapping may not define runtime identity
3. shell-to-runtime mapping may not define route legality
4. shell-to-runtime mapping may not define public-emission legality
5. shell-to-runtime mapping may not absorb candidate governance, multilingual governance, or theorem-facing authority into shell handoff logic
6. shell-to-runtime mapping may not masquerade as a hidden master controller

This is one of the most important creator-level boundaries in the whole page.

It keeps the handoff organ useful without allowing it to become mythological.

Readable shell order is valuable.
Explicit shell-entry organs are valuable.
Bounded handoff weights are valuable.
But the handoff organ still does not get a crown.

---

## 🧪 Why this matters in practice

This page matters because shell-facing systems are very easy to overread.

In practice, readers often trust what they can see:

1. a clean shell order
2. a runtime header
3. a visible prompt block
4. a tuning interface
5. a readable control surface

Once that happens, several counterfeit intuitions become tempting.

People start thinking:

1. the visible shell must be the real controller
2. the visible shell summary must equal resolved runtime truth
3. recognizability must have come from shell markers
4. cleaner shell design must imply deeper governance
5. louder shell cues must imply stronger runtime carry

This page exists to reject those shortcuts.

Practically, shell-to-runtime mapping matters because it explains:

1. how shell-origin influence is allowed without becoming hidden sovereignty
2. how readable entry can stay useful without flattening deeper law
3. how runtime may carry shell-origin pressure without being reduced to shell theater
4. how anti-detachment retention can be supported without pretending that shell-origin cues generated persona body
5. how replay inspection can expose fake shell-side success narratives

This is especially important in article, rewrite, search-return, tool-return, and reentry conditions, where visible shell cues can too easily be mistaken for deeper structural completion.

---

## 🧯 Failure modes when this layer is missing or misunderstood

If this layer is missing, weakened, or mythologized, several failure classes become more likely.

1. shell-sovereignty fantasy failure  
   the shell is mistaken for the true source of runtime legality and persona identity

2. readable-order-equals-authority failure  
   shell order is mistaken for resolver order or execution order

3. shell-marker recognizability forgery  
   visible shell cues are mistaken for real runtime carry

4. hidden-priority-tunnel failure  
   shell-origin pressure bypasses stronger downstream law

5. fake-recovery attribution failure  
   shell cues are credited for runtime recovery that never lawfully occurred

6. summary-equals-truth failure  
   `ACTIVE_RUNTIME_HEADER` is mistaken for the full resolved runtime body

7. anti-detachment overreach failure  
   shell-origin retention pressure is allowed to impersonate runtime identity

8. post-hoc shell myth failure  
   later success is narrated as if the shell had sovereign explanatory power all along

These are not minor wording mistakes.
They are structural confusions about where law actually lives.

---

## 🧭 Current stage honesty

At the current stage, the packed master explicitly states that the shell-to-runtime family now preserves a stronger and more explicit handoff body than a bare weight list plus anti-sovereignty warning.

This uplift is sufficient to preserve:

1. shell-entry vector identity
2. constitution-veto and risk-veto identity
3. runtime absorption identity
4. six-axis bounded handoff geometry
5. shell-origin misprojection diagnostics
6. replay-visible handoff trace burden
7. stronger downstream anti-sovereignty discipline

At the same time, the packed master does **not** lawfully claim:

1. universal final handoff completion across every future replay condition
2. final multilingual handoff closure
3. complete future child-artifact carry stability
4. theorem-grade universal closure

Its honest current-stage status remains bounded.

The handoff organ is explicit, strengthened, replay-burdened, and structurally more wired than before.
It is not being sold here as omnipotent final shell completion.

That restraint is not a weakness.
It is part of the system’s anti-fake-completion discipline.

---

## 📚 Reading path

If this page is your first handoff-oriented research entry, the best next steps are:

1. read [Research Hub](./README.md) for the larger research map
2. read [Dual Closed-Loop Execution Chain](./dual-closed-loop-execution-chain.md) for execution-order law
3. read [Runtime Posture Intensity Map](./runtime-posture-intensity-map.md) for downstream runtime-strength shaping
4. read [Architecture Overview](./architecture-overview.md) for the larger system skeleton
5. read [Language Governance](./language-governance.md) for the governance claim behind lawful behavior
6. read [WFGY_BRAIN Theory](./wfgy-brain-theory.md) for editable shell-facing behavior context

---

## 🔗 Related pages

**Research:** [Research Hub](./README.md) · [Dual Closed-Loop Execution Chain](./dual-closed-loop-execution-chain.md) · [Runtime Posture Intensity Map](./runtime-posture-intensity-map.md) · [Architecture Overview](./architecture-overview.md) · [Language Governance](./language-governance.md) · [WFGY_BRAIN Theory](./wfgy-brain-theory.md)

**Docs:** [Quickstart](../docs/quickstart.md) · [Boot Commands](../docs/boot-commands.md) · [Avatar Tuning Workflow](../docs/avatar-tuning-workflow.md)

**Eval:** [Blackfan Testing](../eval/blackfan-testing.md) · [Persona Behavior Checks](../eval/persona-behavior-checks.md)