Agreement A contains policy v1.
The 2018 entry is inside its complete history. The 2022 and 2025 changes are beyond the Root’s verified frontier and therefore do not apply yet.
Scenario 02 · Process Embedded
A policy changes once. Every ready Root must include it at the right point.
A regulator publishes an initial Hospitality Policy and later changes through one public Timeline. Two Agreements already contain embedded policy occurrences but are verified through different frontiers.
Document graph
Public sourceHospitality Regulator Timeline
Policy entries2018 v1 · 2022 v2 · 2025 v3
Root ASupplier Agreement verified through 2021 → policy v1
Root BHotel Agreement verified through 2026 → policy v3
InvariantNo Root ready beyond a policy change may retain the previous policy state
The temporal result
Different frontiers can produce different correct policy states.
Agreement B contains policy v3.
Its feeder has complete evidence through the 2022 and 2025 regulator entries, so both changes have been applied before later governed actions.
BlueId identifies exact state; the frontier explains when that state is complete. A BlueId by itself does not prove that no earlier provider entry is still missing.
Advance the old Agreement
Policy changes are processed before later business actions.
Close provider history.
The feeder obtains a binding completeness frontier from every active Timeline, including the regulator.
Order eligible entries.
The 2022 policy change is ordered before a merchant action submitted in 2024.
Update the embedded policy.
The policy occurrence advances to v2 inside the Agreement Root.
Evaluate the business action.
The later action now runs against the policy state that applies at its position.
The regulator publishes once. It does not rewrite each Agreement. Every Root that advances past the same canonical policy-change position must include the same change before claiming readiness.
Break a prerequisite
Missing completeness causes deferral—not stale execution.
If the regulator provider cannot prove that every entry before the requested frontier has been revealed, the feeder cannot safely know whether an unseen policy change should precede the merchant action.
Correct result: DEFERRED or BLOCKED. The system should not process the action under the old policy and should not misreport the action as commercially denied.
What the UI should show
Last verified throughThe exact frontier for which all required provider history is complete.
Blocked providerWhich Timeline cannot currently supply valid completeness evidence.
Pending actionThe later business entry that cannot yet be ordered safely.
Recovery pathRestore evidence, close the window, process the policy change, then reconsider the action.
Important precision
This scenario starts with the policy already embedded.
It demonstrates ordinary frontier advancement of active embedded occurrences. It does not demonstrate attaching an already-running policy process today and retroactively replaying its pre-attachment history.
Planned / next specification iteration: historical import of a newly attached process established at an earlier frontier requires the explicit admission and catch-up profile described on the Process Embedded page.
Current scenario claim
Initial policy existsEach Root already contains its policy occurrence.
Future regulator entries arriveThe public Timeline changes the policy after the occurrence is active.
Roots advance independentlyEach processes complete history up to its own frontier.
Same frontier, same policy stateGiven matching definitions and provider evidence, the embedded policy substates converge.
Run the scenario
Advance one Root. Remove completeness. Try a governed action.
The Playground lets you compare the two Agreements, move the older one across policy changes, deliberately remove regulator completeness, and observe safe deferral.
Concept model status
The browser scene explains the architecture. Normative behavior and exact release claims remain in the specification and package artifacts.