DAHN Space Navigator Design Specification v0.12¶

Status¶

Draft normative design specification.

Change Log¶

Version	Changes from prior version
v0.12	Places discovery rationale under Technical Details and defines one disposable top-level Inspector session with owned nested inspection.
v0.11	Defines Load Holons result transaction lineage, retained response reads, independent presentation and committed-member review contexts, and usage persistence boundaries.
v0.10	Adds a Space Navigator-owned collapsible auxiliary information region, custom Visualizer definition inspection, occurrence-bound targeting, and responsive hosting.
v0.9	Keeps Load Holons with its affording HolonSpace and initiation in HolonInspector's action bar; Space Navigator supplies the enclosing exploration context.
v0.8	Separates Dancer roles and subject bindings from launch, Path Inspector, Holon Inspector, and Table Collection authority.
v0.7	Replaces default visibility of empty relationships with progressive population-gated browsing; defines destination-first pending presentation and stable collection switching.
v0.6	Defines column-oriented sorting semantics separately from table-level default row ordering, including descriptor-backed Sequence and Key defaults and occurrence-local restoration.
v0.5	Defines the bounded DAHN Launch Experience: its narrative, application-shell boundary, readiness and handoff behavior, accessibility, observational-imagery provenance, and MVP deferrals.
v0.4	Adds `LoadHolons` as a Space Navigator Action Bar operation, invoked as the canonical Dance through the active `HolonSpace`; defines Space-Navigator-scoped feedback and makes host source selection ingress rather than a second semantic loading protocol.
v0.3	Baseline normative Space Navigator design specification.

Purpose¶

Space Navigator is a Dancer for exploring and manipulating the local MAP Space. It owns experience roles, their semantic subject bindings, coordination, and Space/transaction-scoped interaction. Canvas hosts the experience.

Its top-level RootedNavigation slot initially binds the local HolonSpace. DAHN selection chooses a conforming Visualizer; Space Navigator does not require Path Inspector's two-axis grammar. Selected Visualizers own their recursive child composition. Node, PropertyMap, Value, and Collection roles beneath them are not therefore direct Space Navigator responsibilities.

DAHN architecture owns subsystem and semantic-state boundaries. The Space Navigator grammar owns Dancer interactions. Concrete navigation belongs to the selected RootedNavigation Visualizer; the current Path Inspector design and its grammar are independent authorities.

1. Design Goals¶

1.1 Descriptor-Driven¶

Space Navigator obtains semantic subjects and effective affordances through MAP. Its role composition remains descriptor-driven rather than hard-coded to known domain types. Selected Visualizers interpret the properties, relationships, Dances, cardinality, permissions, and editability supplied by those descriptors.

1.2 Generic¶

Space Navigator supports previously unknown Holon types by requesting applicable Visualizers through the DAHN selection policy. It does not choose a fallback implementation when selection or realization fails. A selected RootedNavigation Visualizer may recursively compose specialized Node, Collection, PropertyMap, Value, or Action Visualizers; those are its descendants, not an additional list of direct Dancer slots.

1.3 Shape-Oriented¶

Semantic subject shape informs slot requirements and applicability through the Visualizer kinds. The selected Visualizer decides how it realizes those semantics. Space Navigator does not assign an axis or presentation region from relationship cardinality.

1.4 Context-Preserving¶

The navigation role must preserve meaningful exploration context: the inspected subject, how it was reached, the producing affordance, and relevant prior navigation context. The selected Visualizer chooses how that context remains visible or recoverable; Space Navigator does not prescribe lineage geometry.

1.5 Spatially Scalable¶

The navigation role must support sustained exploration within the host-provided allocation while keeping prior context recoverable. Axis-specific compression is Path Inspector's strategy, not a requirement on every RootedNavigation substitute.

1.6 Unified Read and Edit Experience¶

The experience supports inspection and permitted editing without requiring a separate application. Selected Visualizers own their view/edit presentation; MAP owns staged semantics and the Dancer coordinates transaction interaction.

1.7 Incrementally Implementable¶

Delivery sequencing is defined in the implementation plan. Incremental delivery preserves the same composition boundaries.

1.8 DAHN Launch Experience¶

The DAHN Launch Experience is an application-shell presentation. It coordinates readiness and handoff without becoming a Space Navigator-owned Visualizer or Dancer-selection mechanism.

2. Core Design Principles¶

2.1 Definitions Determine Structure¶

Descriptor semantics distinguish declared cardinality from runtime population. Visualizers use those inputs without turning them into a universal spatial grammar.

Visibility, focus, and navigation layout belong to the selected RootedNavigation Visualizer. Space Navigator owns its direct experience-role allocation.

2.3 Descriptors Determine Editability¶

Descriptors and effective permissions determine editability; visibility does not confer permission to mutate a subject.

2.4 Staged State Determines What Is Being Changed¶

The architecture state boundary distinguishes presentation state from authoritative staged semantics.

2.5 Compression Hides Presentation, Not State¶

Space Navigator preserves the shared state-survival contract when coordinating its roles. It does not define a child's compression strategy.

3. Direct Experience Roles¶

Direct role	Subject / context binding	Required capability and ownership
Space context	Local HolonSpace	Presents the space itself; when visual, requests a compatible Node realization through DAHN.
Afforded Dancers	Dancer affordances exposed by that HolonSpace	Composes access to the afforded Dancers; no concrete visual contract beyond established source behavior is presumed.
Rooted navigation	Initially the local HolonSpace; explicit new-context anchor where requested	RootedNavigation with recoverable context and bounded participation, specified below.
Space Navigator Action Bar	Space Navigator experience session and active MAP transaction	Coordinates Space/transaction-scoped actions, with selectable action presentations where supported.

For each visual slot actually defined, Space Navigator supplies the slot, accepted Visualizer contract/types, semantic subject, and applicable context to DAHN selection. These role descriptions do not introduce schema relationships or formal slot names beyond the existing design.

A future AgentSpace may extend HolonSpace with agent, social, governance, membership, LifeCode, or We-Space affordances. Such roles are not prerequisites of the current Space Navigator.

4. Space Navigator Experience Composition¶

4.1 Responsibility¶

The Space Navigator Dancer owns HolonSpace-specific orchestration, including:

representing the HolonSpace and its afforded Dancers as experience concerns;
selecting the navigation role rooted at that HolonSpace;
using Holons OwnedBy the HolonSpace as initial heterogeneous semantic context;
transaction-level interaction surface;
coordination of selected role realizations.

The ownership topology (HolonSpace -> OwnedBy Holons) is semantic context, not the complete navigation topology. Rooted Navigation unfolds its distinct, interaction-derived topology through relationships traversed from the root and may therefore extend beyond directly owned Holons.

The selected RootedNavigation Visualizer owns navigation realization and its child roles. Space Navigator neither assigns those children nor dictates their geometry. The local HolonSpace is a subject binding, not an implementation dependency on HolonSpace inside the selected generic Visualizer.

4.2 Experience Structure¶

The Space Navigator consists conceptually of:

a pinned Space Navigator Action Bar;
the navigable Space Navigator area containing visualizer occurrences.

Conceptually:

+------------------------------------------------------+
| Space Navigator Action Bar                           |
| Undo | Redo | Commit | ...                           |
+------------------------------------------------------+
|                                                      |
| Rooted Navigation Visualizer                          |
|                                                      |
| Internal realization belongs to selected Visualizer  |
|                                                      |
+------------------------------------------------------+

The Space Navigator Action Bar remains pinned while traversal occurs beneath it. It is Dancer chrome, not Canvas chrome.

4.3 RootedNavigation Slot Boundary¶

The slot requires the RootedNavigation semantic capability, rooted exploration through applicable Holon affordances, inspection of reached subjects, recoverable navigation context, and participation within its supplied allocation. Space Navigator supplies the initial local HolonSpace, effective Theme and runtime context, and relevant agent/experience context. DAHN selection resolves the slot under its normal compatibility and choice policy.

No contract here requires two axes, horizontal singular traversal, vertical plural traversal, table placement, a sidebar, or Path Inspector's Node compression states. Those choices belong to the selected realization and its own slots. Path Inspector is the current conforming realization, not the slot's permanent implementation identity.

4.4 New Exploration Contexts¶

The Dancer interaction grammar owns routing an explicit Holon anchor to a new exploration tab within the same Space Navigator experience. Space Navigator owns the tab collection and each tab's RootedNavigation slot; the selected Visualizer owns navigation within it. The first tab is rooted at the local HolonSpace; an additional tab may bind a different compatible anchor while retaining the same HolonSpace, Dancer, Theme, and agent/runtime context. The enclosing Canvas and Window Manager context do not change. Each tab retains independent occurrence topology and view state.

Read-only tabs share the Space Navigator-owned read transaction, bound references, and semantic cache. Closing a tab disposes its presentation, not that transaction or sibling tabs. Read and write transactions remain segregated; editing across tabs requires an explicit policy before it is enabled. Re-root, branch close, and focus are distinct intents. Failure or refusal preserves the source.

A future presentation option may detach an exploration tab into its own window. Space Navigator remains the shared experience and read-transaction owner; the Window Manager supplies the additional top-level context and display allocation. Detachment moves the existing exploration presentation while preserving its navigation state; it does not imply a new Dancer session, semantic copy, or transaction. Window closure and reattachment behavior require a separate design.

4.5 Auxiliary Information Region¶

Space Navigator's experience composition owns a collapsible auxiliary region outside its selected RootedNavigation Visualizer. The region has a stable desktop location. While open, its width remains stable across focus changes, inspection targets, and content updates. Opening or closing the region is an explicit layout action that changes the allocation supplied to RootedNavigation; the selected Visualizer continues to own layout within that allocation.

The first consumer is a custom Visualizer for shared Visualizer definition holons, selected through a dedicated experience slot under DAHN's normal selection policy. It leads with the selected Visualizer's display name and a plain-language description of what it helps the user do. Built-in definitions supply purpose descriptions through their holonic property contract. Internal identifiers, captured occurrence provenance, slot name and accepted kind(s), properties, applicability, composition, implementation, and token relationships remain accessible inside one initially closed “Technical details” disclosure. Accepted kind labels come from the captured slot's AcceptsVisualizerType declarations. The initial view does not ask users to choose a Visualizer; eligible-alternative discovery and choice remain in later slices. Definition information remains distinct from VisualizerUsage configuration and history.

Ordinary choice leads with each alternative's purpose, preview, and Choose action. Technical discovery rationale belongs under the initially closed Technical details disclosure, with a plain-language entry such as “How these choices were identified.” It presents the existing Rust discovery chain, declaration provenance, eligibility evidence, and endpoint/reason through a Visualizer Inspector-owned Structure slot, as defined in DAHN discovery evidence and recursive inspection. The technical explorer and its evidence are materialized when that disclosure is first opened, rather than as a prerequisite for ordinary inspection or choice. Further inspection of the explorer opens only through its explicit v. The explanation concerns the captured current context, not selection history; why a Visualizer was selected is stated only when actual selection evidence is available. Missing selection rationale is identified without speculation.

Each presented slot selection exposes a small lowercase circled v with the selected Visualizer display name in its tooltip. Invoking that control captures the presentation occurrence, containing context, actual slot and owner, presented subject, and selected Visualizer. Focus changes and exploration-tab switches do not retarget an open inspection. A new explicit v invocation in the main viewing area disposes the current top-level Visualizer Inspector and its owned resources before establishing the new session. There is one top-level information session for the Space Navigator experience; independent retained sessions per exploration tab are not required. That Inspector owns its explorer, nested session stack, and pending/presentation resources under the DAHN lifecycle contract. Nested v invocations stay within that ownership boundary and retain the invoking target/state for return. Closing the information experience or invalidating its top-level target clears the entire chain; the Space Navigator-owned outer region shell may remain. While the information view is visible, its live invoking v is highlighted as selected; replacing, hiding, or dismissing the view clears the previous highlight. The view identifies its captured subject and occurrence so that its binding stays clear across tab switches.

The definition heading offers the standard “Explore from here” icon. Explicit activation opens the captured Visualizer holon as the root of a new exploration using the ordinary RootedNavigation tab lifecycle. Reading information alone does not navigate.

An initially closed “Presentation structure” disclosure exposes the live parts of this presentation, distinguishing selected child Visualizers from regions implemented by their containing Visualizer. It permits inspection of those parts; it does not list candidates or change selection. In Table, its column entries identify the Value Visualizer shared by every cell in the respective column. Declared composition slots remain in Technical details. The consumed Theme token list identifies the active Theme and shows the PresentationValue supplied by its ThemeTokenAssignment for each exact DesignToken version. These are the validated assignment values projected with the active Theme, not inferred CSS values. Tokens not consumed by this Visualizer are omitted; an unavailable assignment is identified explicitly rather than substituted from another Theme or token version.

Closing the inspected occurrence dismisses its information view and restores focus to an appropriate surviving control. Explicit dismissal restores focus to the live invoker where possible. Late asynchronous results must not populate a closed or superseded inspection. Desktop target closure may leave the auxiliary region open for another tool or inspection.

On narrow displays, the same region is presented as a full-width overlay within the experience instead of reserving sidebar width. Its keyboard focus is contained while open; closing it restores navigation and an appropriate focus target. Exploration state and semantic targeting survive presentation changes.

Read-only inspection does not change the inspected definition, occurrence selection, usage, or staged editing state. Realizing the custom presentation may create transient invocation/projection holons through the established materialization pipeline; it does not authorize staging or committing semantic changes.

Later choice slices may present Rust-authorized alternatives and support explicit selection in this information experience. An alternatives list contains only other Visualizers satisfying every selection criterion for the captured slot, owner, and subject; it is never a global Visualizer catalog and may be empty. Discovery, usage selection, and safe occurrence replacement remain governed by their separate contracts. Future tools such as annotations or comments may share the auxiliary region, but each must state whether its target is captured or follows focus.

5. Space Navigator Action Bar¶

5.1 Purpose¶

The Space Navigator Action Bar contains actions whose semantic scope is the current Space Navigator experience session or active MAP transaction. A Canvas may separately provide desktop-manager actions that launch, tile, focus, or switch Dancer windows; it MUST NOT offer the Space Navigator's Undo or Redo.

These actions SHOULD NOT be repeated in every Node Visualizer.

5.2 Transaction Actions¶

The Space Navigator Action Bar SHOULD support transaction-scoped operations such as:

Undo;
Redo;
Commit;
transaction status;
abandon/revert transaction where supported.

Because one transaction may contain staged changes to multiple holons, Commit belongs here rather than in an individual Node Visualizer.

5.3 Space Navigator Actions¶

The Space Navigator Action Bar MAY additionally contain:

Space Navigator view controls;
layout controls;
Space Navigator-specific navigation controls;
Space Navigator experience-visualization controls;
other Space-Navigator-level operations.

LoadHolons belongs to its affording HolonSpace and is initiated through that holon's HolonInspector action bar. Space Navigator supplies the enclosing exploration context. Source selection, request preparation, and result presentation participate in the holon-level action interaction; host ingress does not define a second semantic loading protocol. Normal inspection reflects committed results through MAP-backed reads.

5.3.1 Load Holons Result Transaction Lineage¶

A Load Holons result page coordinates distinct transaction contexts. These contexts are separately opened within the local space; their relationship is ownership and retained evidence, not nested commit or rollback.

Context	Responsibility	Lifecycle
Space Navigator exploration	Owns the originating HolonSpace exploration and its afforded action.	Independent of the load interaction; closing the result page does not dispose this context.
Loader	Owns request preparation, execution, transient response and diagnostic evidence, and the imported holons staged by loading.	Successful loading commits imported holons. Retained response and diagnostic references remain readable through the archived context until the action releases it.
Result presentation	Realizes the result's selected RootedNavigation, Node, and child Visualizers, including replacement presentations.	Remains open for presentation invocation objects while the result page exists; released when the page closes.
Committed-member review	Reads imported holons as saved state, using the loader's committed membership identities.	Separately opened for saved-member inspection and released when the result page closes.
Usage persistence	Initializes VisualizerUsage and records successful presentation and explicit preference.	Independent transactions commit usage data without committing, abandoning, or mutating the caller's subject transaction.

The result presentation context and committed-member review context MUST remain distinct in responsibility. Presentation requires an open context for realization; committed-member review provides saved-state references for imported members. The term review MUST distinguish presentation from committed-member inspection when identifying transaction ownership.

The response root and its transient diagnostic descendants retain their loader-bound references. Committed members cross into the committed-member review by persisted identity alone; staged maps or cached loader values MUST NOT be copied into that review as saved-state evidence. Inspection uses the context that owns the subject reference. Visualizer realization uses the open result presentation context even when the subject is read through the archived loader.

5.3.2 Replacing a Load Result Node¶

Changing the response root's Visualizer follows these boundaries:

Validate the candidate against the retained response, exact subject descriptor, slot contract, composition owner, and Theme through the subject's bound context.
Resolve or initialize the selected Visualizer's applicable usage through an independent usage transaction, as defined by DAHN Usage Persistence.
Prepare the replacement and its child Visualizers in the open result presentation context. Read response values through their retained subject references; do not rebind transient response evidence into another context.
Publish the replacement only after initialization and allocation admission. Preserve occurrence identity, navigation provenance, and action-owned result collections and their contracted view state. A failed or cancelled preparation leaves the existing presentation usable.
Report successful explicit choice through independent usage persistence. Reporting failure does not roll back the published Node or block interaction.

Selection and usage command admission MUST permit a retained committed subject context: the caller supplies readable evidence, while usage writes occur in a separate transaction. Realization operations that create invocation objects still require an open presentation context. This distinction does not reopen the loader or permit mutation of its committed state.

5.3.3 Result Page Release¶

Closing the load interaction cancels pending presentation work, releases the result navigation and owned collection presentations, drains outstanding reads and realization work, and disposes the committed-member review and result presentation contexts before releasing the loader's retained evidence. It leaves the originating Space Navigator exploration available. Persisted imported holons and committed usage configuration survive presentation disposal.

5.4 Personalization¶

The Space Navigator defines a set of Dancer-level actions and their relative semantic importance.

Where supported, the person MAY personalize:

ordering;
prominence;
visible versus overflow placement;
Action Visualizer choice.

Reordering or replacing action presentations MAY emit adaptive signals according to the architecture specification.

5.5 Action Scope Rule¶

Actions SHOULD appear at the lowest common scope that owns their effect.

Examples:

value action → Value Visualizer;
property action → owning PropertyMap or Value Visualizer, according to its effect;
collection action → Collection Visualizer;
holon action → Node Visualizer;
transaction action → Space Navigator Action Bar.

6. Active Traversal Frontier¶

See Active Traversal Frontier. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

7. Node Visualizer¶

See Node Visualizer. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

8. Full Node Geometry¶

See Full Node Geometry. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

9. Node Title Bar¶

See Node Title Bar. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

10. Node Action Bar¶

See Node Action Bar. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

11. Property Viewer Pane¶

See Property Viewer Pane. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

12. Array-Valued Properties¶

See Array-Valued Properties. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

13. Vertical Single-Value Tab Rail¶

See Vertical Single-Value Tab Rail. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

14. Editing Single-Valued Relationships¶

See Editing Single-Valued Relationships. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

15. Horizontal Collection Tab Bar¶

See Horizontal Collection Tab Bar. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

16. Relationship Presentation¶

See Relationship Presentation. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

17. Dance Result Presentation¶

See Dance Result Presentation. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

18. Collection Visualizer¶

See Collection Visualizer. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

19. Table Collection Visualizer¶

See Table Collection Visualizer. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

20. Editable Collection Visualizers¶

See Editable Collection Visualizers. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

21. Editable Value Arrays¶

See Editable Value Arrays. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

22. Editable Multi-Valued Relationships¶

See Editable Multi-Valued Relationships. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

23. Dance Result Collection Editability¶

See Dance Result Collection Editability. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

24. Semantic Editing Ownership¶

The Space Navigator MUST distinguish editing a relationship or collection from editing a contained target holon.

For example, if A has a Friends collection containing B:

adding or removing B from Friends edits A;
changing B's name edits B.

Visual containment MUST NOT imply semantic editing ownership.

25. Descriptor-to-Presentation Mapping¶

See Descriptor-to-Presentation Mapping. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

26. Applying the Interaction Grammar¶

See Applying the Interaction Grammar. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

27. Focus and Concrete Extent Realization¶

See Focus and Concrete Extent Realization. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

28. Compression and Editing¶

See Compression and Editing. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

29. Loading States¶

See Loading States. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

30. Progressive Retrieval¶

See Progressive Retrieval. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

31. Entering Edit Mode¶

See Entering Edit Mode. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

32. Continuous Preservation of Staged Work¶

In-progress staged work is preserved by MAP snapshot mechanisms.

The person SHOULD NOT need a conventional Save button merely to protect work from loss.

The design therefore distinguishes:

preservation of staged work;
explicit transaction Commit.

33. Multiple Holons in Edit Mode¶

The Space Navigator MAY contain staged changes to multiple holons in the same active transaction.

For example:

A [editing]
  |
  C
  |
  B [editing] -> D [read-only]

A and B may both contribute staged changes to the same transaction.

This MUST NOT imply separate Commit operations for each node.

34. Staged State and Visualizer Occurrences¶

Visualizer occurrence state and staged semantic state are distinct.

If the same holon appears in multiple occurrences while staged:

all occurrences ultimately reflect the same authoritative staged semantic state;
TypeScript MUST NOT create independent semantic edit copies for each occurrence.

The exact synchronization presentation may evolve, but semantic divergence MUST NOT occur silently.

35. Editing While Navigating¶

See Editing While Navigating. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

36. Compressing Editable Visualizers¶

See Compressing Editable Visualizers. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

37. Create¶

See Create. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

38. Clone¶

See Clone. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

39. Delete¶

See Delete. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

40. Commit¶

Commit is exposed in the pinned Space Navigator Action Bar.

It applies to the entire active transaction, which may include:

updated holons;
newly created holons;
clones;
relationship changes;
array changes;
staged deletions.

It is not a Node Visualizer action.

41. Commit Flow¶

When Commit is invoked:

the active staged transaction is validated;
applicable validation errors are returned if present;
if valid, MAP commits the transaction;
affected visualizers refresh from committed state;
affected staged visualizers return to read presentation;
navigation provenance remains intact.

Commit is a transaction-state transition, not a navigation transition.

42. Commit Failure¶

If validation or Commit fails:

staged transaction state remains intact;
affected visualizers remain in edit mode;
the person may correct the staged state and retry;
errors SHOULD appear as close as practical to affected visualizers;
the Space Navigator MAY also display a transaction-level summary.

Failure MUST NOT silently discard staged work.

43. Undo and Redo¶

Undo and Redo are exposed in the pinned Space Navigator Action Bar.

They apply to the active transaction.

They MUST operate on Rust-owned staged semantic state rather than merely reversing TypeScript presentation.

44. Undo Boundaries¶

TypeScript determines when a meaningful UX interaction constitutes a new Undo boundary.

Examples may include:

completing a property edit;
adding/removing a relationship target;
completing an array mutation;
completing another semantically meaningful editing gesture.

Low-level preservation snapshots need not correspond one-to-one with user-visible Undo steps.

45. Undo Flow¶

Conceptually:

edit gesture completes
      |
meaningful Undo boundary established
      |
later: Undo
      |
Rust restores prior staged snapshot
      |
affected visualizers refresh

Undo MAY therefore affect multiple visible visualizers if one interaction changed shared transaction state.

46. Redo Flow¶

Redo restores the next recoverable transaction snapshot and refreshes affected presentation.

Its availability SHOULD be reflected in the Space Navigator Action Bar.

47. Abandon or Revert Transaction¶

The Space Navigator SHOULD eventually provide a clear transaction-level mechanism for abandoning or reverting staged work.

The exact user-facing term and semantics remain to be finalized.

Possible semantics include:

revert entire active transaction to its starting state;
abandon all staged changes;
preserve recoverable staged state for later resumption.

The behavior MUST be explicit and MUST NOT silently lose work.

48. Adaptive and Personalizable Interactions¶

See Adaptive and Personalizable Interactions. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

49. Personalization and Constrained Geometry¶

See Personalization and Constrained Geometry. This behavior belongs to the selected Visualizer, not to the Space Navigator Dancer.

50. Interaction Scenarios¶

50.1 Inspect a Holon¶

See Inspect a Holon.

50.2 Open a Multi-Valued Relationship¶

See Open a Multi-Valued Relationship.

50.3 Navigate Through a Collection¶

See Navigate Through a Collection.

50.4 Follow a Singular Relationship¶

See Follow a Singular Relationship.

50.5 Continue Horizontally¶

See Continue Horizontally.

50.6 Continue Vertically¶

See Continue Vertically.

50.7 Mixed Traversal¶

See Mixed Traversal.

50.8 Enter Edit Mode¶

See Enter Edit Mode.

50.9 Edit Scalar Property¶

See Edit Scalar Property.

50.10 Edit Array¶

See Edit Array.

50.11 Edit Multi-Valued Relationship¶

See Edit Multi-Valued Relationship.

50.12 Edit Singular Relationship¶

See Edit Singular Relationship.

See Edit Related Holon Separately.

50.14 Create¶

See Create.

50.15 Clone¶

See Clone.

50.16 Delete¶

See Delete.

50.17 Undo Across Multiple Holons¶

Given staged changes to A and B:

complete a meaningful edit gesture;
create Undo boundary;
make later edits;
invoke Undo from Space Navigator Action Bar;
Rust restores transaction state;
all affected visible occurrences refresh accordingly.

50.18 Commit Multiple Holons¶

Given:

A [updated]
B [created]
C [relationship changed]
D [deleted]

all staged in one transaction:

invoke Commit from the Space Navigator Action Bar;
validate the full transaction;
if valid, commit all staged state atomically according to MAP semantics;
refresh affected occurrences;
return staged visualizers to appropriate read state.

50.19 Compress While Editing¶

See Compress While Editing.

51. Open Design Questions¶

51.1 Sibling History¶

See Sibling History.

51.2 Compression Thresholds¶

See Compression Thresholds.

51.3 Horizontal Overflow¶

See Horizontal Overflow.

51.4 Vertical Overflow¶

See Vertical Overflow.

51.5 Scalar Dance Results¶

See Scalar Dance Results.

51.6 Dance Result Tabs¶

See Dance Result Tabs.

51.7 Empty Singular Relationships¶

See Empty Singular Relationships.

51.8 Branch Closing¶

See Branch Closing.

51.9 Focus Presentation¶

See Focus Presentation.

51.10 Transaction Abandon Semantics¶

Define exactly what happens when the person abandons or reverts an active transaction.

51.11 Multiple Occurrences of a Staged Holon¶

See Multiple Occurrences of a Staged Holon.

51.12 Relationship Target Selection¶

See Relationship Target Selection.

51.13 Deleted Holon Presentation¶

See Deleted Holon Presentation.

52. Non-Goals of the Initial Design¶

The initial integrated delivery may defer the following capabilities. Items concerning a Visualizer are delivery limits on that realization, not requirements that Space Navigator imposes on every substitute:

arbitrary free-form positioning within the Canvas;
draggable visualizer placement;
graph auto-layout;
unlimited simultaneous sibling branches;
persistent Space Navigator sessions;
collaborative Space Navigator state;
complete mobile optimization;
sophisticated animation;
complete keyboard navigation;
every specialized visualizer;
production Visualizer Commons package loading;
all adaptive scoring algorithms;
arbitrary query construction.

These capabilities may evolve within their owning components without changing Space Navigator's direct-role contract.

53. Normative Design Invariants¶

53.1 Descriptor Semantics Over Runtime Accident¶

Declared cardinality and result shape determine structural presentation.

53.2 Visualizer Categories Are Roles¶

Do not equate a category such as Node Visualizer with one permanent concrete implementation.

53.3 Generic Candidates Preserve Basic Use¶

Generic candidates obey the DAHN selection policy. Absence is an explicit error; neither this Dancer nor its client chooses a hard-coded fallback.

53.4 Singular Traversal Goes Right¶

See Singular Traversal Goes Right.

53.5 Plural Traversal Goes Down¶

See Plural Traversal Goes Down.

See Navigation Preserves Provenance.

53.7 Holon Identity Is Not Occurrence Identity¶

See Holon Identity Is Not Occurrence Identity.

53.8 Child Content Claims Space Only When Activated¶

See Child Content Claims Space Only When Activated.

53.9 Parent Geometry Constrains Subordinate Geometry¶

See Parent Geometry Constrains Subordinate Geometry.

53.10 Compression Preserves State¶

See Compression Preserves State.

See Read and Edit Share One Visual Grammar.

53.12 Staging Is Holon-Specific; Commit Is Transaction-Wide¶

Individual holons enter staged edit state.

The Space Navigator commits the active transaction.

53.13 Multiple Holons May Participate in One Transaction¶

The design MUST support concurrent staged changes to multiple holons.

53.14 Undo and Redo Are Space Navigator/Transaction Operations¶

They are not local Node history operations.

53.15 Editing Membership Is Not Editing the Target¶

Relationship mutation and target-holon mutation remain semantically distinct.

53.16 Immediate Personalization and Durable Adaptation Are Distinct¶

The visible experience changes immediately; persistent learning is handled through DAHN adaptive architecture.

53.17 Lazy Population, Early Structure¶

See Lazy Population, Early Structure.

54. Summary¶

Space Navigator binds the local HolonSpace to a RootedNavigation role and coordinates its direct experience roles and transaction-level actions. It can host a conforming alternative with a different navigation layout without adopting that Visualizer's internal grammar. MAP owns semantic and staged state; selected Visualizers own their experiential realization and recursive children.

Inspection, Create, Clone, Delete, property/relationship editing, and navigation remain available through the composed experience. Their concrete controls belong to the appropriate selected Visualizer; Commit, Undo, and Redo remain scoped to the active transaction and exposed by the Dancer.

Selection authority¶

Direct Dancer roles and recursively requested children use the DAHN slot-directed selection policy. Each slot narrows eligible candidates; subject applicability and selection policy resolve the selected Visualizer within that boundary.