Door
Door is the Pen for addressable thresholds, media-realized traversal, and pocket-drop evidence. It explains how a route becomes a physical witness path, how Muq walks that path, and how every touched node receives complete inflow, error, or result truth without poller risk.
The traveler does not stop to write the note. The traveler is the note. When the traveler passes through a door, the pocket falls open, and the path itself becomes the record.
0. Prelude — The Man Who Did Not Stop
There is a familiar image: a man moving quickly through a building, opening doors, passing through, never stopping long enough to leave a written message. Someone behind him asks why he did not leave a note. The answer is that he did not need to. He was the note.
Everything about him—what he carried, where he stepped, what he touched, which door he passed through—was already a message. The system did not need a note after the fact. It needed to observe the traversal.
1. Door Is Not Merely an Entry
In ordinary systems, a door is treated as an entrance: a URL endpoint, a page, a controller action, or a file. In PhoMaster, that is not enough. A Door is an addressable threshold that records traversal.
Door = addressable threshold = route node = traversal witness = pocket-drop event
A Door is therefore not merely something the request goes through. It is something that remembers the request went through. Once a Door remembers, the system no longer depends on central reconstruction, fragile session inference, or remote database lookup as the only source of truth.
2. From Logging to Shedding
Conventional logging is retrospective. Something happens, and a system writes about it. Door changes that model. Door uses shedding: as the traveler moves, complete local truth falls out at every node touched.
The note is not written later. The traversal sheds its own evidence as it proceeds. This is why the pocket-drop metaphor matters. Each node receives a complete pocket, and each pocket can stand alone.
3. The Pocket Doctrine
The pocket is the atomic unit of Door. Each node touched by traversal receives one. Not optionally. Not only at the final endpoint. Every meaningful node in the interpreted route receives enough local truth for audit, action, and accounting.
Every door touched receives the traveler's pocket.
That pocket contains the full request, the interpreted mantle, the node position, the route decision, and the outcome. It does not require upstream queries or cross-node stitching. The local pocket provisions the polling consumer with everything needed to react.
4. Inflow, Error, and Result Grammar
Door uses three output classes for route evidence:
| Class | Extension | Meaning |
|---|---|---|
| Inflow | .json | The complete incoming route packet: request, host, path, query, headers, mantle, node, timing, and pending decision. |
| Error | .eson | The error return packet: exception, sink reason, denied condition, failed dependency, or damaged traversal report. |
| Result | .zson | The retreat/result packet: served, sunk, rerouted, denied, faulted, artifacts written, elapsed time, and route outcome. |
This keeps the route grammar visible by file type. Inflow arrives as ordinary JSON. Error has its own error-son form. Result has its own zson form so a poller can distinguish raw arrival from finished consequence without opening every file first.
5. Rename Instantiation Law
If a poller sees a half-written file, the Door contract is broken. Therefore Door output must always be instantiated by rename.
write: Ingress_abc123.json.tmp close rename: Ingress_abc123.json write: Error_abc123.eson.tmp close rename: Error_abc123.eson write: Result_abc123.zson.tmp close rename: Result_abc123.zson
This is the observer safety law. Pollers can use directory seek and extension detection without locks, without partial parse risk, and without becoming consumers of an unfinished artifact.
6. Door as Media Node
Door expands beyond token dispatch. A door token such as
?command=door&door=PrintDocs remains a valid public knock
pattern, but Door also describes every media node that a routed traversal touches.
A URL such as:
child2.child1.f-ire.pho.rip/level1/level2?x=1
may resolve into:
F:ire\ F:ire\child1\ F:ire\child1\child2\ F:ire\child1\child2\level1\ F:ire\child1\child2\level1\level2\
Each folder in that walk can receive its own _route pocket:
_route\ Ingress_*.json Error_*.eson Result_*.zson
7. Muq as Root Walker
Muq is the one who walks. Door is what records the walk.
Muq receives the incoming host, scheme, path, query, headers, user context, and route intent. It then decodes the host and path, resolves the mantle pinnacle, materializes the route nodes, writes ingress pockets, dispatches or sinks the request, and finally writes error or result pockets during retreat.
incoming URL → Muq root controller → decode host/path/query/hash → resolve Mantle pinnacle → materialize every node as folder → write verbose ingress at every node → execute / route / sink → write retreat result at every node
8. Mantle Pinnacle Table — The Current Situational Object
A DNS-resolvable pinnacle such as f-ire.pho.rip represents the
public form of a Mantle pinnacle such as F:ire. But
f-ire does not necessarily mean the literal hard drive
F:\. It means the current F:ire mantle cwd locus.
That locus is determined by a current situational object: the Mantle pinnacle table. This table cross-references mantle pinnacles to their active drive or cwd settings.
| DNS token | Mantle pinnacle | Current locus meaning |
|---|---|---|
f-ire | F:ire | Current F:ire cwd root, not necessarily hard F:\ |
s-end | S:end | Current Send/service cwd root |
p-hos | P:hos | Current Photoshop/Print preparation cwd root |
a-gent | A:gent | Current Agent cwd root |
w-ow | W:ow | Current Wow/deck cwd root |
This table is not a static publication chart. It is a live situational object. It tells the route walker where the mantle currently resolves in media.
9. BasicData, Parentop, and Parental Lookup
The Mantle pinnacle table belongs in window.BasicData at the level
that knows the current mantle settings. A child frame or resident panel may not
have the full table locally. Therefore the route intelligence must be able to
climb through Parental and ultimately Parentop to find
the BasicData that actually contains the pinnacle-to-locus mapping.
window.BasicData local context Parental.BasicData immediate parent context Parentop.BasicData topmost host / apex context
This is important because Door must not assume that the current iframe or panel is the authority. The authority is the nearest available BasicData context that carries the Mantle pinnacle table and session identity needed for the walk.
10. Routing Certainty and Window Identity
Door can be sure it is being routed when three identities line up:
- the incoming host resolves to a known Mantle pinnacle token,
- the BasicData hierarchy yields the current pinnacle table for that token,
- the active window identity confirms which frame, panel, or resident route surface is making or receiving the traversal.
This means window identity is not cosmetic. It tells the system whether the request is arriving at the apex, a child iframe, a resident Wow panel, a hosted route surface, or a Muq-controlled browser socket. The route can then decide whether to act locally, ask Parentop for authority, or sink the request as unserviceable.
11. Session Identity
Session ID is not the same thing as mantle identity. Mantle identity answers:
Where does this route live in media?
Session identity answers:
Which traversal instance is this?
Door needs both. The mantle table resolves the path. The session or request ID binds ingress, error, and result pockets together across all nodes touched by the walk. Without session identity, every node may still know the route, but the distributed pockets cannot be reliably grouped as one traversal.
A useful Door packet therefore carries both:
{
"requestId": "door-20260430-...",
"sessionId": "...",
"windowId": "...",
"mantleToken": "f-ire",
"mantleName": "F:ire",
"cwdRoot": "...",
"nodePath": "...",
"nodeDepth": 2
}
The request ID is the traversal stitch. The session ID is the continuity stitch. The window ID is the surface stitch. The mantle table is the media stitch.
12. Door and Parenting Residue
Traditional systems propagate state through parameters, headers, and sessions. Door does not reject those, but it does not depend on them alone. Every node pocket contains the full route context, and that context can include the relevant BasicData snapshot or reference.
This means downstream consumers do not have to ask where the request came from. The pocket carries enough residue to provision local action, audit, and accounting.
13. Door and Sink
When routing fails, Door does not permit a broken path. A failed route still becomes lawful arrival at Sink. Sink writes the error or result pocket back through the same node trail.
status: served sunk rerouted denied faulted maintenance warming
The failed traversal is therefore still inspectable. It still has a session ID, request ID, window identity, mantle token, node path, and result packet.
14. Door and Actuation
Door aligns with the older Rell/Tell grammar: web-shaped intent becomes
filesystem-shaped state. Print writes intention artifacts such as
/Work/Mms/Prt_*. Upload assembles temporary files before rename.
Commerce writes order and purchase artifacts. Messaging writes SMS/MMS
artifacts.
Door generalizes that pattern. It does not only dispatch a request; it leaves artifacts for asynchronous consumers to observe and act upon.
27. Left-Hand and Right-Hand Descendency
Door now recognizes two major forms of URL descendency. The first is the left-hand host descendency, expressed by dot-separated subdomain segments before the Mantle pinnacle. The second is the right-hand path descendency, expressed by slash-separated path segments after the host.
In a route such as:
child2.child1.f-ire.pho.rip/step1/step2/step3?some=this
the left-hand descendency resolves first:
child2.child1.f-ire.pho.rip -> F:ire\child1\child2
Then the right-hand descendency extends the route from that resolved locus:
/step1/step2/step3 -> F:ire\child1\child2\step1\step2\step3
The important point is that the right-hand path is not lesser than the subdomain path. Once the Mantle apex and left-hand descent have produced the target route folder, the right-hand pathing becomes the relative branch below that final target. Every node in that branch is treated with the same Door rules: pocket-drop, Glue copy, filter evaluation, result retreat, and poller visibility.
28. Up and Down Filter Arrays
To prevent left-hand and right-hand path methods from being confused, Door
segregates filter groups into Up and Down arrays.
These are not arrays in the database sense; they are folder-instantiated
method collections whose subfolders may be exact names or wildcard patterns.
Door\
Up\
Ch###e\
In\
Out\
Down\
step$\
In\
Out\
Up belongs to the host-side, dot-separated, reverse descendency.
It applies while interpreting names such as child2.child1.f-ire.
Down belongs to the slash-separated branch after the host and
applies while interpreting names such as step1/step2/step3.
This separation gives Door a clean grammar:
Up: child2.child1.f-ire.pho.rip filters: Door\Up\... Down: /step1/step2/step3 filters: Door\Down\...
Both sides still use the same wildcard substitution law:
$ means *, and # means ?.
The difference is the side of the URL being interpreted.
29. Up Filtering — Host-Side Descent
Up filters operate on the left-hand DNS/subdomain descent. They are the filters for the part of the address that walks from the public Mantle pinnacle into its host-side children.
Door\Up\Ch###e\
A filter such as Ch###e may match a host-side node named
Change. If the exact folder Door\Up\Change\ also
exists, wildcard matches execute first in alphabetical order, and the exact
folder executes last.
30. Down Filtering — Path-Side Branching
Down filters operate on the slash-separated path after the host. Once the
route has resolved to a locus such as F:ire\child1\child2, the
URL path /step1/step2/step3 becomes the branch
F:ire\child1\child2\step1\step2\step3.
Door\Down\step$\
A filter such as Door\Down\step$\ may match step1,
step2, and step3. Each node is still evaluated
independently, pocketed independently, and recorded into Glue independently.
31. Pathing Order — Up Then Down, Retreat Back Through Both
Door traversal now has a clearer walk:
1. resolve Mantle pinnacle 2. walk Up host-side descendency 3. arrive at the target route locus 4. walk Down right-hand path branch 5. consume by final controller or sink 6. retreat through Down nodes 7. retreat through Up nodes 8. return to apex
Glue records both halves. The route can distinguish a host-derived node from a path-derived node even if the visible folder name is the same.
32. Bookshelf — URL Parameters as Route Shelf
The second vast area of active routing is the query string: everything after the question mark. These parameters are not necessarily pathing, but they are often essential to the meaning of a route. Rell has long used URL parameters as operational carriers, and Muq also receives route meaning through view, deck, mode, step, intent, portal, target, and similar values.
Door names this parameter layer Bookshelf.
?some=this&view=prn&session=abc
A parameter may be a single page, or it may point to an entire book. It may carry a direct scalar value, a hex-encoded payload, a reference to a file, a route intent, a stage instruction, or a global OS file that supports the route. Bookshelf is therefore not merely query parameters. It is the route shelf of named carried references.
33. Bookshelf Availability at Every Transit
Bookshelf is available to Muq during every node transit, both In and Out. It is also available to polling consumers because every node pocket and Glue copy can carry the relevant query parameter map.
Bookshelf: some = this view = prn deck = dtfhub stage = stable target = ...
This means a filter does not have to rediscover URL parameters. The parameter shelf travels with the route. A node-level filter may decide that a parameter applies locally, that it points to an outside artifact, that it should be copied into Glue, or that it should reshape the route.
34. Bookshelf as Page or Book
A Bookshelf entry may be tiny or vast. A parameter such as some=this
may be a single page of information. A parameter such as manifest=...,
body=..., or target=... may refer to an entire book
of route meaning. Door allows both.
The important law is that Bookshelf entries are not treated as second-class route data. They are carried into Glue and node pockets so that filters, controllers, and pollers can judge the totality of the route, not merely its folder descent.
35. Parenting Filters — Same Grammar, Different Medium
Folder/file filters are not the only filter form. The same grammar exists in
Parenting. At the window level, BasicData may carry filter
structures that parallel the filesystem prototype bin.
BasicData.Filter.In.Ch$ BasicData.Filter.Out.ste#2
A BasicData filter can carry the same conceptual payload as filter.txt
and filter.js in the folder world:
{
"js": "jjjjjj",
"txt": "ttttt"
}
36. Parental Filter Climb
Parenting filters obey the same inheritance instinct as BasicData itself. If the local window does not resolve a needed filter, the search climbs to the Parental context, then upward again, until a matching filter is found or the hierarchy is exhausted.
window.BasicData.Filter -> if not resolved Parental.BasicData.Filter -> if not resolved Parentop.BasicData.Filter
This means a child iframe or resident panel can inherit route behavior without duplicating every method locally. The apex may define broad route filters. A child may define local overrides. Exact matches still have final force at the level where they are found.
37. Filer-ing and Parent-ing Parity
The intent is identical across Filer-ing and Parent-ing. A filesystem filter and a BasicData filter both represent a method that may examine route context, execute or describe a behavior, and record its effect into Glue.
Filer-ing: Door\Up\Ch###e\In\filter.js Door\Down\step$\Out\filter.txt Parent-ing: BasicData.Filter.In.Ch$ BasicData.Filter.Out.ste#2
The difference is medium, not doctrine. The folder version is durable, inspectable, and poller-friendly. The Parenting version is resident, window-aware, and immediately available to a live frame hierarchy.
38. Combined Route Judgment
A filter judges the totality of the route. That totality now includes Up host-side descendency, Down path-side branch descendency, Bookshelf query parameters, Glue route memory, node pockets, BasicData, Parental and Parentop context, session ID, request ID, and window identity.
This is not a simple filename match. It is a route intelligence point. It can decide what a node means in the context of everything being carried through and around that node.
39. Updated Door Formula
Door = Up host descent + Down path branch + Bookshelf parameters + Glue route whiteboard + Filer-ing filters + Parent-ing filters + node pockets + retreat result
The traveler is still the note, but the note is now richer. It has a path, a shelf, a window identity, a session continuity, filter methods, and a Glue record of every push, reshape, withdrawal, redo, sink, or result.
40. Angle — The Third Kingdom of URL Navigation
Door now recognizes the fragment after # as the third active
kingdom of URL navigation. Up handles dotted host descendency. Down handles
slash pathing. Bookshelf handles the query string. Angle handles the Angular,
panel, client, or resident route after the hash.
f-ire.pho.rip/step1/step2?command=stop&reason=fail#angle1/angle2 f-ire.pho.rip/step1/step2?command=stop&reason=fail#/abs1/abs2
A hash without a leading slash is relative. A hash with a leading slash is absolute. Door treats that distinction as intent.
41. Relative Angle and Absolute Angle
A relative Angle begins without a slash, such as #angle1/angle2.
It means navigation from the current Glued angle. If Glue has no Angle value,
the default base is /, so the first relative angle is effectively
absolute by default. If Glue has collected an Angle prefix, the relative hash
extends that prefix.
An absolute Angle begins with #/, such as #/abs1/abs2.
It is routed after inbound Glue has been created, but it overrides the normal
relative continuation and starts from the Mantle root.
42. Glue Angle
Glue now carries an Angle property. This is the accumulated
client or Angular prefix gathered during ingress and optionally implanted by
filters.
{
"kind": "Glue",
"Angle": "/glueang1/glueang2",
"AngleMode": "relative",
"AngleResolved": "/glueang1/glueang2/angle1/angle2"
}
Filters may append to the Glue Angle. Bookshelf parameters, BasicData, Parentop signals, or node-local prototype methods may also implant Angle segments. Angle therefore becomes recorded route state, not hidden client ornament.
43. Angle Resolution Examples
Suppose Up and Down pathing have resolved the final target as:
F:ire\child1\child2\step1\step2\
Then a relative Angle:
#angle1/angle2
resolves as:
F:ire\child1\child2\step1\step2\angle1\angle2\
If Glue has already collected /glueang1/glueang2, then the same
relative Angle resolves as:
F:ire\child1\child2\step1\step2\glueang1\glueang2\angle1\angle2\
By contrast, an absolute Angle:
#/abs1/abs2
starts from the Mantle root:
F:ire\abs1\abs2\
44. Angle Nodes Are Real Media Nodes
The resolved Angular route is mirrored in Mantle storage. Every node of the final Angle route is instantiated with the same Door obligations as every Up or Down node. It receives the pocket, the Glue copy, and the audit/accounting/ action evidence.
_route\ Ingress_*.json Error_*.eson Result_*.zson Glue_*.zson
Angular no longer has to infer everything from the live app alone. Its stage directives, local assets, current Glue, and node-specific instructions may already live in the real-media folder it has entered.
45. Angle Under the Same Geas
Angle is under the same geas as the rest of Door. A hash route is not free from evidence just because browsers often treat it as client-side. If Door resolves it, Door sheds into it.
Every Angle node may receive the original URL, resolved URL, Up chain, Down chain, Bookshelf map, Glue Angle before and after resolution, filter actions, and final result or sink condition.
46. Angular as Enhanced Resident Navigation
Angular is strengthened by this doctrine because it does not need to carry all stage directives and assets inside the client route. It can arrive at a resolved media node that already contains route evidence, stage directives, assets, and Glue.
Nothing important has to remain invisible outside the node. The route itself provisions the place, and the Angular surface can rely on Glued information.
47. Relative Angle from the Final Target Node
Up: child2.child1.f-ire.pho.rip → F:ire\child1\child2 Down: /step1/step2 → F:ire\child1\child2\step1\step2 Relative Angle: #angle1/angle2 → F:ire\child1\child2\step1\step2\angle1\angle2
Relative Angle behaves like a child branch of the already resolved route, not as detached client decoration.
48. Absolute Angle as Override
Absolute Angle begins with #/ and starts from the Mantle root
after inbound Glue is established. Because it overrides the current target
branch, it must be recorded clearly in Glue.
{
"action": "AngleOverride",
"from": "F:ire\\child1\\child2\\step1\\step2",
"to": "F:ire\\abs1\\abs2",
"reason": "absolute hash route"
}
49. Garbage Cleaning
Complete transit evidence creates many files. Door therefore expects garbage cleaning as a maintenance layer. Old Glue copies, expired ingress pockets, redundant snapshots, and superseded result files can be pruned or archived by policy after evidence has safely arrived.
Cleaning never interferes with rename instantiation and never exposes pollers to half-written files.
50. Updated Door Navigation Formula
Door = Up host descent + Down path branch + Bookshelf parameters + Angle hash route + Glue route whiteboard + Filer-ing filters + Parent-ing filters + node pockets + retreat result
This is the full Door walk: DNS-side ascent into Mantle, path-side descent into branch, parameter-side Bookshelf intent, and hash-side Angle residency. The traveler is still the note, but now even the Angular shadow of the route drops a pocket.
52. Body-Carried Styling for Brancher Absorption
Door now follows the same body-carried styling law used by Route and the stabilized PenPals/Brancher absorption path. A gathered Pen donates its body. Therefore, essential readability cannot depend on a style block that lives only in the document head.
The Door Pen carries its baseline ink, spacing, panel, card, table, and code styling inside the body itself. When Brancher extracts the Door body, the visual doctrine travels with the doctrinal text. Door remains readable as a standalone page and remains readable as a gathered Pen body.
Door\index.html head = document identity body = donated doctrine + donated style style = carried with the body for PenPals / Brancher survival
This does not change Door ownership or Cull scope. It only prevents the extracted Door body from becoming visually orphaned when absorbed by another Pen.
53. Closing Doctrine
Door is the doctrine of traversal made visible. It transforms a route from a hidden controller decision into a walk across media. Every node touched receives a pocket. Every pocket is written safely by rename. Every pocket knows the mantle, session, window, route, and result.
The system does not merely remember what happened. The system is composed of where it happened.
16. Glue — The Route Whiteboard
Door now adds Glue: the route-global zson that begins at the initial Mantle decision and carries forward through the entire traversal. When Muq resolves the pinnacle token, the drive or cwd locus, and the first media node, it also provisions Glue as a whiteboard for the route. Glue records the original URL, current URL, session, request, window identity, mantle, touched nodes, filter activity, route reshaping, restaging, sink decisions, artifacts, and final result.
incoming URL -> Mantle pinnacle decision -> drive / cwd locus resolved -> node path provisioned -> Glue.zson created -> traversal begins
Glue is not merely a log. A log observes after the fact. Glue participates during traversal. It is available to the final controller, to any filter that must judge the route, and to the retreat path as the final result is carried back through every touched node.
17. Glue as zson Result Carrier
Door already separates inflow, error, and result artifacts as json, eson, and zson. Glue belongs to the zson family because it records route consequence even while the route is still in motion.
{
"kind": "Glue",
"requestId": "...",
"sessionId": "...",
"windowId": "...",
"mantleToken": "f-ire",
"mantleName": "F:ire",
"cwdRoot": "...",
"originalUrl": "...",
"currentUrl": "...",
"nodes": [],
"filters": [],
"actions": [],
"result": null
}
As traversal proceeds, Glue gains node touches, filter matches, URL reshaping events, redirection proposals, restaging notes, sink decisions, artifact references, timing, and final status.
18. Glue Propagates Down and Back
Glue moves in both directions. On descent, Muq carries Glue through the route as each node is provisioned and touched. On retreat, Glue carries the final result back through the same touched path.
descent: apex -> child1 -> child2 -> level1 -> level2 retreat: level2 -> level1 -> child2 -> child1 -> apex
Every node traversed downward or upward receives a copy of the current Glue. That way a node does not merely know that a request passed through. It can also know what the request became after later decisions.
19. Path Filters — Methods Attached to Route Names
Door now gains a method layer: Path Filters. A Path Filter is a named or wildcarded method surface that can attach behavior to any similar node in a route path. As Muq transits a node, it examines available filter prototypes and determines whether any filter applies to that node name and route condition.
Door\Change\ Door\Cha$\ Door\Ch###e\
In this grammar, $ stands for *, and #
stands for ?. Thus Cha$ and Ch###e can
both match Change, while Change remains the exact
folder.
20. Filter Direction — In and Out
A route has direction. Filters therefore have direction. In
filters execute during descent into a node; Out filters execute
during retreat out of a node.
Door\Change\In\ Door\Change\Out\
An In filter may provision, gate, annotate, reshape, push, or restage the route before the final controller consumes it. An Out filter may interpret the final result and leave accounting, rollback, redo, sink, or completion residue behind.
21. Filter Ordering — Wildcards Before Exact
Filter order matters. Door uses a folder-based cascade. All wildcard filter folders that match the node are considered in alphabetical order. If an exact folder exists for the node name, the exact folder executes last.
For node: Change 1. Cha$ 2. Ch###e 3. Change
The exact folder comes last because it can uniquify the final behavior for the concrete node. Broad prototype rules apply first; the named node gets the last word, similar to element-level style after broader CSS rules.
22. Filter Effects — Push, Reshape, Residue, Restage
A filter judges the totality of the route shed into the node. It may inspect the inflow pocket, Glue, BasicData, Parentop-derived Mantle table, window identity, session ID, request ID, and local node state.
| Effect | Description |
|---|---|
| Annotate | Add residue to Glue without changing navigation. |
| Push | Cause a node to emit a result or trigger local action. |
| Reshape | Rewrite or refine URL, route target, path, query, or fragment. |
| Restage | Pause the current path and restart through a revised route point. |
| Withdraw | Mark a prior route change as withdrawn or superseded. |
| Redo | Declare that the route should be attempted again under changed conditions. |
| Sink | Send traversal into controlled sink with full Glue context. |
Every effect must be written into Glue. Filters may change the route, but they must not hide the fact that the route changed.
23. Prototype Bin — Generic Methods for Named Nodes
The prototype bin is where generic route methods live before being attached to a particular media node. Door is the natural Pen to hold the doctrinal prototype examples because Door defines traversal, pocket-drop, Glue, and filter order.
Door\
Change\
In\
filter.txt
filter.js
Out\
filter.txt
filter.js
Cha$\
In\
filter.txt
filter.js
Ch###e\
In\
filter.txt
filter.js
The text representation explains the filter. The JavaScript representation supplies the executable or inspectable route method.
24. Glue and Filter Relationship
Glue and filters are complementary. Glue is the route whiteboard. Filters are the local hands that may write on that whiteboard.
Glue: remembers the route Filter: reads the route may change the route records that change into Glue
A filter without Glue would be dangerous because it could alter navigation invisibly. Glue without filters would be passive because it could record the walk but not reshape it. Together they create a route that is observable, accountable, and still capable of intelligent local transformation.
25. Poller Consequence — Local Knowledge Without Cross-Reference
Every node receives Glue for the same reason every node receives a pocket: asynchronous consumers must be able to react locally. A poller waking at a node should not have to search the apex to learn whether the route was redirected, sunk, restaged, or completed.
_route\ Ingress_*.json Error_*.eson Result_*.zson Glue_*.zson
That gives the polling consumer enough information for audit, action, and accounting.
26. Door After Glue and Filters
Door is the threshold system where traversal becomes evidence, Glue becomes the carried route whiteboard, and Path Filters become local methods capable of reshaping, annotating, withdrawing, restaging, or completing the route while preserving the full history of what happened.