Aliases: telescoping; zoom; expressibility; navigation; root story; readability; PM.
At the widest view, a reader sees the selected business promise. A deliberate step inward reveals the constituent contracts and their compatibility. Further steps reveal how actual work is bound and how leaves perform it. Each level answers the next relevant question; it does not silently add responsibility to the story.
The audience changes the depth of reading, not the promise. A domain owner should be able to review the selected policy and consequences without reconstructing low-level code. An engineer should be able to follow the same names into executable relationships and implementation. A directory tree, diagram or fluent sentence can help, but cannot substitute for those relationships.
Preserve a useful path from the root into entry, later visits, independent obligations and recovery where the selected story owes them. Do not create a universal lifecycle contract merely to fit everything on one page. A deep abstraction earns its place through the product questions it answers.
A story register selects executable realizations and binds occurrences to actual resources. Binding untrusted input does not confer authority. Keep the selected relationships visible; a global service locator hiding them is not a telescope. Source organization serves decision ownership without mechanically copying an organizational chart. Search can find the entrance, but must not be the only way to reconstruct the story.
Relationship map for a protected story; runtime admission applies where its commitment needs current facts:
flowchart TD
S[Selected story: compile-time abstraction] --> C[Compatible constituent contracts]
C --> N[Permitted successor contracts]
S -. realized by .-> I[Implementation]
I -. binds .-> O[Occurrence: actual actor, input and resources]
O --> A[Current-fact admission]
A --> W[Bound continuation]
N -. constrains .-> W
Your Reflection
Notes are browser-local. Export a copy to keep them; they are not submitted or judged.