design-context-models

Designing context models for routing

The mechanism being optimized

Two files, two unrelated effects. Confusing them makes every later decision guesswork.

File	Key	Effect
_commands/context_inheritance_model.json	base	Adds the base context's commands to the child's callable surface. Controls reachability.
context_hierarchy_model.json	parent	No runtime navigation effect at all. Read at training time only.

A context's classifier does not choose among its surface. Its label set is:

own commands
+ inherited commands (transitive over `base`)
+ framework core commands + `wildcard`
+ every ancestor's surface, trained as `wildcard`     <- this comes from the `parent` axis

go_up and escalation both walk the live object's parent — the Context.get_parent callback returning obj.parent — never the JSON. The parent axis exists to teach a context which utterances are not its own, so it answers wildcard, which makes the runtime climb the live chain and re-predict there.

Three consequences drive everything below:

• A parent edge no command can produce is pure cost. It can never be walked at runtime, and it still enlarges the wildcard class.
• A missing parent edge that is produced at runtime is worse. The child was never taught to reject that ancestor's utterances, so it confidently misroutes instead of escalating.
• Only a lone confident wildcard escalates. wildcard returned beside real candidates raises an ambiguity prompt instead, so "escalation" and "routing" trade against each other and must be scored separately.

Rule 1 — derive the hierarchy from code, never hand-maintain it

The true parent graph is whatever each command constructs and assigns as the current context. Scan for the assignment to current_command_context and record the class being entered; that set is the containment graph. Diff it against the declared JSON and fix both directions: drop edges nothing produces, add edges something produces.