Alternative chronological interpretations have always been part of how an archaeologist reasons about a stratigraphic record. Two excavation teams reach different conclusions about the sequence of a wall’s construction phases; a single team produces a primary hypothesis but documents a secondary one for completeness; a synthesis pass over a long-running project compiles five competing reconstructive narratives from different periods of fieldwork. The EM language has long had the Time Branch group node (DP-43) as the data structure for hosting these alternatives — each branch is a coherent slice of the graph carrying its own version of the stratigraphic story — but two things have been missing.
The first missing piece is the relationship BETWEEN branches: are two branches mutually exclusive (only one can be true) or compatible (they describe complementary aspects of the same reconstruction and can both be active)? Without that distinction in the language, the matrix carries the alternatives but doesn’t carry the modeller’s claim about how they relate to each other. The second missing piece is the authoring affordance: a modeller looking at a matrix with five branches has no clear way to switch between them, no panel that lists the alternatives with their summaries, no filter that hides all-but-one branch when they want to focus.
DP-12 closes both. The sequencing is the standard EM data-layer-first discipline: the language layer ships first, the manager UI ships on top of a correct data model. The principle is the same one DP-62 (canonical edges first, then UI), DP-66 (property inheritance edges first, then authoring affordance), and DP-67 (USNV class first, then rendering dispatcher) have established as the right shape for cross-cutting EM extensions.
Language layer — two inter-branch connectors. The current absorbed DP-42 contribution gives us excludes_branch: a dashed edge between two TimeBranch group nodes that says these two branches cannot both be true at once. DP-12 adds its complement: concatenates_with_branch, a second connector style for the case where two branches are compatible and link into a coherent multi-hypothesis sequence. The two edges are mutually exclusive at the graph level — a single pair of branches can be either excluding or concatenating, not both — and together they exhaust the legitimate relationships between sibling branches. CIDOC mapping is clean: crminf:J3_in_exclusive_disjunction_with for the excluding case, and either crminf:J4_complements or an em: extension for the concatenation case if CRMinf doesn’t have an exact predicate match. Both edges round-trip through the canonical-edges + multilingual-rapporti pipeline DP-62 and DP-63 established; the pyArchInit reverse export drops them with a warning (until a real consumer needs the round-trip fidelity, at which point a side-channel column is the natural extension).
TimeBranchNode payload. Every alternative chronological interpretation is a TimeBranchNode (an extension of the existing Time Branch group node from DP-43) carrying four fields that the manager UI consumes: a stable branch_id for the SPARQL / multilingual identifier, a macro_description (one-paragraph human-readable summary, editable inline from the manager panel and persisted on the node), an is_active flag (per-session, not per-graph — so multiple modellers exploring the same graph can each have their own active branch without conflict), and the existing membership edges is_in_timebranch that connect stratigraphic units to the branch they belong to. Authoring stays in yEd at the graph level; the manager UI in EM Tools is a thin overlay that consumes and surfaces what the graph already encodes.
Manager UI — sibling of Activity and Epoch managers. Once the language layer has shipped, the Temporal Branch Manager panel lands in EM Tools as a sibling of the existing Activity Manager and Epoch Manager (both already living under the DP-35 Visual Manager family). One row per TimeBranch in the active matrix, columns: branch name, truncated macro description (hover-to-expand), member count (how many stratigraphic units belong to this branch via is_in_timebranch), and an active-row dropdown that lists the alternative branches connected to the current one via excludes_branch edges. Picking a branch from the dropdown re-filters the scene and the US Manager to that branch, with a short fade transition matching the UX of the existing CronoFilter epoch slider (DP-10).
US Manager branch filter — three-axis filtering converging. When a TimeBranch is active, the Stratigraphy Manager (and any other panel consuming the same scene context) shows only the units that belong to that branch via is_in_timebranch, hiding all the others. Combined with the existing Epoch filter (chronological dimension via DP-10 CronoFilter) and Activity filter (activity dimension via DP-43 group node membership), the modeller has three orthogonal filtering axes converging on the same panel. They can answer “show me the units that belong to the foundation Activity, in the early Augustan Epoch, in the Western Phase branch” with three toggles. The filter combinations don’t intersect destructively — a unit appears if it satisfies all three active filters, hides otherwise.
Concatenation as navigation, not just edge type. The concatenates_with_branch edge isn’t only a passive data-layer assertion; it surfaces in the manager as a navigation affordance. From branch A, the manager offers ‘follow concatenation chain’ — jump to branch B that follows it, then to C, building a coherent multi-hypothesis sequence the modeller can walk through one branch at a time. This is captured here for the long view; it doesn’t ship in the first cycle of the manager UI (the dropdown switching between exclusive alternatives is the MVP), but the language-layer edge ships first so the data structure is ready when the navigation affordance lands.
Why this matters now. The Sarmizegetusa case study has long pushed the limits of the existing TimeBranch construct — multiple competing chronologies of the temple complex with overlapping evidence sets, where the current language can name the alternatives but not formalise how they relate. With the two new connectors and the manager UI, an archaeologist working Sarmizegetusa can declare ‘these two phases are alternative readings of the same evidence’ (excludes) or ‘these two phases are sequential parts of a longer hypothesis’ (concatenates) and then navigate the alternatives without leaving the EM Tools workflow. The Basilica Iulia case (DP-25) brings the equality-connection layer that complements this work — both DPs together give EM the full vocabulary for expressing the relationships between coexisting graph fragments.
Open decisions to thread at review. Six points the language and UI work will settle: (1) the concatenation edge name (proposed: concatenates_with_branch for parity with excludes_branch); (2) is_active scope (proposed: per-session, scene property); (3) auto-refresh vs explicit apply on branch switch (proposed: auto-refresh with fade transition, parity with CronoFilter); (4) yEd palette colour calibration for the two connectors (proposed: dashed-red for excludes, dashed-green for concatenates, defer to DP-30 for chromatic consistency); (5) flat list vs tree view for deeply nested concatenation chains in the manager (proposed: flat list with cross-links for MVP); (6) pyArchInit reverse-export behaviour when the EM graph carries inter-branch connectors (proposed: warning + drop in MVP, side-channel column when a real consumer needs round-trip fidelity).
1.6
Sarmizegetusa
Absorbs former DP-42 (Dashed Connector) as the `excludes_branch` case. Substantially expanded 2026-06-09 to formalise the architectural sequencing — **language layer first, manager UI second** — plus the second connector type (concatenation) that complements exclusion, plus the manager-panel + US-Manager-filter UI surface that parallels the existing Activity + Epoch managers. The architectural rationale for ‘connectors before manager’ is the standard EM data-layer-first discipline that DP-62 / DP-66 / DP-67 already follow: the graph language must express the structure cleanly first, so the UI is a thin authoring layer on top of a correct data model — not the other way around. Open decisions to thread at review: (1) the concatenation edge name — `concatenates_with_branch` is descriptive but verbose; alternatives `links_to_branch`, `chains_with_branch`, `is_compatible_with_branch`. Proposal: `concatenates_with_branch` for parity with `excludes_branch` (both are explicit verb-phrases acting on branches as objects). (2) Whether `is_active` on TimeBranchNode is a per-graph or per-session flag — proposal: per-session (a scene property, not a graph property), so multiple modellers exploring the same graph can each have their own active branch without conflict. (3) When the modeller switches active branch via the dropdown, should the scene filter immediately (auto-refresh) or wait for an explicit apply? Proposal: auto-refresh with a short fade transition, same UX as the Epoch Slider already provides via DP-10 CronoFilter. (4) The yEd colour proposals for the two connectors need calibration with the existing EM palette (defer to DP-30). (5) Whether scaling the manager to support deeply nested branch concatenations (A → B → C → D) needs hierarchical view (tree) vs flat list with cross-links — proposal: flat list for MVP, tree affordance only if real use cases demand it. (6) The pyArchInit reverse-export edge case (no native concept of inter-branch connectors) — proposal: warning + drop on reverse export for MVP, side-channel column in a follow-up if a real consumer needs round-trip fidelity. Cross-refs: DP-42 (the dashed connector, absorbed), DP-43 (Time Branch group node — the parent class of TimeBranchNode), DP-10 (Multigraph + CronoFilter — sibling chronological-filter affordance), DP-32 (Propagative Metadata Resolver — branch context flows through), DP-39 (Transformation Connector — the dotted edge type, conceptually adjacent), DP-30 (Reconstructive Elements + palette calibration), DP-62 / DP-63 (round-trip + multilingual plumbing reused for the new edge types), DP-66 (property inheritance — inter-property reuse pattern conceptually adjacent), DP-19 (Canvas Project — eventual in-tool matrix where the branch dropdown could surface natively).