LoopsWork
Interactive Guide
One end-to-end example

CART 1.0: from purpose to the next Build.

See how Build, Value, and Learning work together on the same shopping cart.

CART 1.0 · two-minute overview

One change. Three loops. The next improvement.

Change quantities in a cart: follow the same product change from purpose to the next small spec. Open only the stages you want to explore.

A continuous teaching example. Data, Jira IDs, repository paths, and budgets are illustrative assumptions; this is not a production shop.

BUILD → VALUE → LEARNING → BUILDThe sequence explains the connections. Measurement planning and learning already begin during Build.

01Problem / purposeHelp customers correct quantities and understand the total.Build

A concrete shopping situation

A customer selected two packs of coffee but needs only one. She should change the quantity in the cart and immediately see the valid total including shipping. Confusing totals and awkward corrections should cause fewer abandoned purchases.

Purpose: Make purchases understandable and editable before checkout. Define the expected impact before building, then measure it.

02Pitch / BudgetA small cart improvement within five team working days and €50 AI spend.Build

Proposal and decision limits

PitchAgreement
CART 1.0Add items, change quantities, remove items, respect stock, and show shipping clearly.
ExpectationImprove checkout starts from 58% to at least 62% of eligible cart sessions.
BudgetAt most 5 team working days + €50 AI costs; checkpoint at half the budget.
Outside scopeDiscount codes, payment, and cross-device synchronisation.
DecisionThe PO prioritises within the mandate; the team owns technical choices and quality. Reagree scope in the Spec Clinic if the budget is insufficient.

Explore investment limits ↗

03Small SpecCART-QTY 1.0 specifies the quantity-change slice of CART 1.0.Build

CART 1.0 remains the agreed overall spec. The agent task below uses quantity changes as a small, separately verifiable slice. Its criteria reference the acceptance-criteria IDs of the overall spec.

SPEC CART-QTY 1.0 · Status: agreed
Owner: Product Owner + Feature Partner · technical contract: team
Reference: CART 1.0 / AK-02, AK-03, AK-04, AK-05, AK-06
Goal: change an existing line quantity; keep totals consistent.
Out of scope: new products, discount codes, payment.

PUT /cart/items/{productId}
Body: { "quantity": 2 }
200: updated cart with server-calculated totals
400: non-integer or negative quantity
404: unknown product
409: stock exceeded; leave cart unchanged
quantity = 0: remove line; empty total = 0, checkout disabled.

Example: 2 × 1,490 cents coffee + 490 cents shipping = 3,470 cents.
Shipping: 490 cents below 5,000 cents basket value, free from 5,000 cents.
Measurement: cart_quantity_changed only after a successful state change.
Errors: displayed and stored cart states remain consistent.

Read and copy the complete CART 1.0 spec ↗

04Small ContextOne task, one agreed spec, a few relevant files.Build

Illustrative Jira structure

Work itemScope
CART-10 · CART 1.0Parent brief with purpose, budget, and a link to the authoritative spec.
CART-12 · SubtaskImplement and verify quantity changes against CART-QTY 1.0.
CART-13 · SubtaskIndependent review of the same spec and code versions.

A Jira subtask groups a bounded task with a verifiable result. It does not replace a spec. Small work items allow separate agent runs; shared interfaces and the authoritative spec remain linked. Not every subtask has to be an independently releasable feature.

Context package for CART-12 (illustrative repository):
• agreed CART-QTY 1.0 + relevant CART 1.0 criteria
• src/cart/updateQuantity.ts
• src/cart/totals.ts
• tests/cart/updateQuantity.test.ts
• stock-interface contract + test command
Exclude: entire Jira project, unrelated features, old spec drafts.
Stop on: unclear price source, conflicting stock rules, or added scope.

Jira and Confluence in context ↗

05Agent AssignmentThe Workmaster gets a bounded task and stop rules.Build

A concrete agent task

Role: Workmaster · Task: CART-12
Source of truth: agreed CART-QTY 1.0, reference CART 1.0.
Task: implement quantity changes without changing other cart functions.
Use only the context package from stage 4; request missing contracts.
Limits: no new dependencies or changes to pricing and stock rules.
Do not weaken tests or acceptance criteria.
Budget: at most 3 correction attempts within the allocated remaining budget.
Stop: conflicting spec, new scope, missing data, or budget limit → ask the team.
Deliver: diff, test command and result, criteria mapping, and remaining risks.
No production release. An independent Reviewer receives a separate context.

Workmaster · Editable prompt template

06BuildRed → Green → Refactor for the same small change.Build

First, a failing test specifies the quantity change. The Workmaster then implements the smallest matching behaviour and refactors while keeping tests green.

// Illustrative implementation sketch — server-side prices and stock.
function updateQuantity(cart, product, quantity) {
  assertIntegerAtLeastZero(quantity);
  assertWithinStock(quantity, product.stock);
  const next = replaceOrRemoveLine(cart, product.id, quantity);
  return calculateTotalsInCents(next);
}

The result is a reviewable diff against CART-QTY 1.0. Price source, cent arithmetic, error behaviour, and the agreed measurement event are part of the task. Review confirms the technical state.

07Tests & ReviewAutomated criteria checks are reviewed independently.Build
AKTest caseExpected result
AK-02Quantity 2 → 0; also test −1 and 1.5.Line removed; invalid quantities rejected.
AK-036 coffees with stock 5.409, cart unchanged.
AK-04Change quantity from 1 to 2.Total 3,470 cents including shipping; consistent display.
AK-054.999 / 5.000 Cent490 / 0 cents shipping.
AK-06Remove the final line.Total 0, checkout disabled.

The separate Reviewer also examines counterexamples, state transitions, and integration. A human reviewer assesses the spec, code, and test evidence together and grants technical approval. Evidence identifies the spec version, criteria ID, and checked commit.

Run the existing demo checks ↓ · The browser demo does not replace server or integration tests.

08AcceptanceThe Feature Partner confirms the agreed behaviour.Build

On day 5, the Feature Partner checks shopping scenarios in the Acceptance Slot using the prepared test version: change quantity, cross the shipping threshold, and remove the final item. They confirm the criteria or return specific deviations.

Human decision

“The agreed criteria are met for this version.” This is business acceptance. It is not yet proof of product impact or automatic production approval. New wishes are prioritised separately.

Acceptance Slot ↗

09DeploymentActivate one approved version in a controlled release.Build

After technical and business approval, the designated release owner decides on activation for a limited user group. Record the spec, commit, release, and group attribution together.

  • Verify measurement events and attribution after activation.
  • Watch errors and performance; keep the rollback route ready.
  • Respond to incidents immediately; do not wait for the next Value Review.
10MonitoringOperational signals and product measurement follow the same released change.Value

All values and triggers below are illustrative example data.

SignalObservation / ruleResponse
Quantity-change errors0,6 % · guardrail ≤ 1%Alert the team above 1% for 10 minutes and review activation.
Performance p951,2 s · guardrail ≤ 1.5 sInvestigate sustained breaches and pause expansion.
State errorOn day 8, a displayed total sometimes remains stale after a quantity change.Pause next work; separate fix with regression test, 0.5 team day, and €5 AI budget.
Product metricCheckout starts per eligible cart session; deduplicate events per session.Attribute release, group, and window; do not infer impact from broken events.
Missing evidenceCompleted purchases and price complaints remain incomplete.Assign an owner to close the data gap.

Technical stability is a prerequisite. The scorecard evaluates customer and business impact.

11Value Loop / Scorecard58% baseline, at least 62% target, 64% observed.Value

Feature Scorecard · CART 1.0

Invented example data — not measurements of this website.

FieldCART 1.0 finding
HypothesisEasier quantity changes and clear totals increase checkout starts.
Baseline / target58 % / ≥ 62 %
Measurement planDays 6–18, concurrent comparison and variant; 1,000 eligible sessions each is illustrative, not a universal minimum.
Observed580/1.000 = 58 % → 640/1.000 = 64 % · +6 percentage points
GuardrailsChange errors 0.6% ≤ 1%; p95 1.2 s ≤ 1.5 s.
UncertaintyRandomisation unverified; possible group differences; purchase and complaint findings missing. Account for the day-8 fix in analysis.
InterpretationThe numerical target is reached. This does not establish additional purchases or causality.

Complete scorecard and copyable template ↗

12Value ReviewKeep the limited variant and collect specific missing evidence.Value

On day 20, the Measurement Partner presents the updated scorecard with gaps and a recommendation. PO, Feature Partner, and team assess value, risk, and evidence strength. The PO decides within the mandate.

CART 1.0 decision

Keep the limited variant, without expanding yet. The Measurement Partner investigates comparability and missing purchase and complaint findings. The team adds required measurement points. Next checkpoint in five working days.

Keep, change, expand, roll back, or investigate further are possible decisions. Numbers do not automatically approve a release. The regular Value Review is every four weeks; specific evidence can trigger an earlier checkpoint.

13Learning LoopThe stale-total defect leads to a bounded state-transition testing experiment.Learning

The day-8 fix removes the defect. In the day-10 retrospective, the team investigates the recurring pattern: tests check final states but too rarely the transition between them.

Working materialConcrete trial change
Spec templateAdd a “Before → action → after” field including error state.
Test / AI testing skillVersion 0.2 checks quantity 1 → 2 → 0, rejected stock, and totals after every change.
Prompt / agent instructionsVerify displayed state, stored state, and total after each transition; report missing cases explicitly.
Working agreementReview evidence includes criteria ID and a before-and-after case. Keep context size constant during comparison.

This is one experiment centred on the versioned testing skill. The related spec and prompt guidance makes the same rule usable. Compare suitable cases by defects, rework, human review time, and AI costs. Evaluate on day 20; adopt permanently only with evidence of benefit, or continue the trial if evidence is thin.

Learning experiment template ↗

14Back to the Build LoopCART-OBS 1.1 adds a missing measurement point and trials the new testing skill.Build

The next small change

SPEC CART-OBS 1.1 · next slice requiring agreement
Purpose: attribute checkout starts to a valid cart revision.
Change: assign cart_revision only after an accepted state transition;
checkout_started references that revision, release, and experiment group.
Criteria: no success event for rejected quantities; one checkout event per session;
quantity 1 → 2 and rejected stock keep consistent attribution.
Limits: no new pricing logic, no personal free-text fields.
Evidence: automated event tests + verified telemetry in a test environment.
Before implementation: PO, Measurement Partner, and team agree spec and small budget.

The Value Review supplies the measurement gap; Learning supplies improved testing. Together they produce a new bounded Build task for the same cart. Value continues observing; the loops work in parallel.

↻ Back to the spec stage
Detailed reference: the same CART story over 20 working days
Interactive case study · 20 working days

From need to the next adjustment.

Scan four weeks, then explore individual days. Day 1 is a Monday; weekends are omitted. The loops run in parallel — this calendar is an example, not a required development cycle.

  1. Need
  2. Hypothesis
  3. Specs
  4. Implementation
  5. Evidence
  6. Measure value
  7. Learn
  8. Next adjustment

Rules and numbers are example assumptions. Each day shows its focus and expected output. Labels identify the loops involved. Support, small tasks, and the Flow Check continue throughout all four weeks.

Week 1

Clarify, build, and activate

Day 1BuildValueLearning

Clarify need and impact

Focus: Agree on the problem, hypothesis, and investment limits.

Output: A bounded brief, initial hypothesis, and measurement plan.

View detailsClose details

Agent support

Scout · Planner

Evidence & decision

Budget: at most five team working days and €50 in AI costs; checkpoint at half the budget.

Work and rituals on this day

B1–B4 / V1–V2
Problem, spec & measurement plan

Day 1: agree on the problem, budget, hypothesis and measurement plan. Day 2: confirm rules, plan implementation and test cases. Example limits for the first cart: at most 5 team working days and €50 in AI costs; team effort is not calendar duration. The Spec Clinic postpones the additional wishlist.

Participants: PO, Delivery Team, Feature Partner and Measurement Partner; Scout and Planner support.

Everyday operations
Support & small tasks

Ongoing work across all four weeks, not continuous full-time utilisation. Review requests, rank them by impact and urgency, and pull them within the agreed work limit. A small ticket includes actual/expected behaviour, an owner and evidence.

Participants: Delivery Team; PO or Feature Partner when a decision is needed.

Open related guidance ↗
L1–L2
Gather experience

Record rework, feedback and waiting times from the start. The day 8 bug fix provides a specific finding: state transitions were insufficiently covered. The team examines the pattern in the retrospective on day 10.

Participants: Team and Loop Guide; Learning Guide consolidates approved observations.

daily · 09:00
Flow Check

Every working day at 09:00, up to 10 minutes: correct the current picture, clarify completion and blockers, confirm the next action and owner. Operational work and displaced tasks are visible.

Participants: Delivery Team; PO and Loop Guide as needed.

Open related guidance ↗
weekly · 10:00
Refinement

Mondays at 10:00 for 45 minutes. Prepare the next small piece of work, check scope and budget. On day 1 this concerns the cart, then the next work; ongoing features are not replanned every week.

Participants: PO, team and relevant Feature and Measurement Partners.

Open related guidance ↗

The concrete shopping cart scenario

B1–B2 + V1

Which problem is being solved?

Customers should easily correct their selection and understand the total before checkout. The first small change includes adding items, changing quantities, removing items, and transparent shipping costs.

Product Owner prioritizes within the mandateFeature Partner provides examplesScout identifies open questions

Impact hypothesis

If customers can change quantities directly and see the total, more users with a filled cart will reach checkout.

Next evidence

A short user test checks whether quantities, removal, and shipping costs are understood without explanation.

Clarify open questions deliberately

  • What happens at quantity 0?
  • How should insufficient stock be handled?
  • When does shipping become free?
  • Who determines the valid price?

A small start

Illustrative task: the department leader sets direction through the ‘Simplify shopping’ initiative. The Product Owner defines the cart contribution and decides within delegated authority. The B1 example budget is at most five team working days plus €50 in AI costs, with a review at half the budget spent. Discount codes, guest-account synchronization, and payment are outside this change. If the budget is insufficient, the Product Owner and team use the Spec Clinic to shape the scope further. Price accuracy, stock limits, and required tests remain mandatory.

Specs, prompts & artifacts

VALUE

Feature scorecard

Template for hypothesis, measurement plan, results, uncertainty, and decisions.

Open template ↗

Possible mapping to Jira / Confluence

Link the pitch or brief to the small Jira issue. Reference CART 1.0 as the authoritative versioned source; record open rules and decisions.

Explore the tooling approach ↗

Try the cart & run the demo tests ↓

Day 2BuildValueLearning

Confirm the spec and narrow the scope

Focus: Clarify rules and measurement needs; postpone the wishlist in the Spec Clinic.

Output: Agreed CART 1.0 with acceptance criteria and an implementation plan.

View detailsClose details

Agent support

Scout · Planner

Work and rituals on this day

Problem, spec & measurement plan
Process and participants · day 1 →
Support & small tasks
Process and participants · day 1 →
Gather experience
Process and participants · day 1 →
Flow Check
Process and participants · day 1 →
as needed · day 2
Spec Clinic

Day 2 at 11:00, 30 minutes: the additional wishlist exceeds the limits. Confirm the useful core, postpone the wishlist, and synchronise the spec, tests and measurement requirements. The Clinic is triggered by a need, not a mandatory weekly ritual.

Participants: PO, responsible developers, Feature Partner; Loop Guide as needed.

Open related guidance ↗

The concrete shopping cart scenario

B3 + V2 · SPEC CART 1.0

Agreed behavior, not “just build a shopping cart.”

The Product Owner and Feature Partner confirm the rules. The team adds the technical contract. The same approved spec version guides tests, implementation, and documentation.

Read and copy the complete CART 1.0 spec · Fill in your own spec

One specific version for everyone involved

This demo uses Spec CART 1.0 as its agreed source. In a real project, it could be stored as specs/cart.md in the repository. The work order names CART 1.0 and the exact commit link. Tests can reference CART 1.0 / AK-05. Review and acceptance also record the verified code version. The release connects this evidence to the Scorecard.

Example: from CART 1.0 to a change proposal
  1. Starting point: CART 1.0 / AK-05 agrees on free shipping from 5,000 cents. Preserve this confirmed version.
  2. Proposal: Draft CART 1.1 proposes changing the threshold to 6,000 cents. The change history records the rationale, affected rule AK-05, proposer, and date. This is a hypothetical follow-up; the demo keeps the 5,000-cent threshold.
  3. Check the effects: The Product Owner and Feature Partner decide the new rule. The team considers display, calculation, and boundary tests; the Measurement Partner checks the hypothesis and comparability. Ongoing AI tasks are checked for effects.
  4. Implement only after confirmation: CART 1.1 receives confirmation and a fixed version reference. Change spec, code, and tests together, including 5,999 and 6,000 cents. Acceptance and release document the version actually verified. Impact analysis assigns data before and after the rule change separately.

Key point: A new draft does not silently replace the previous agreement. After rollback, code, configuration, and the associated spec version must match.

CriterionAgreed ruleTest example
AK-01Adding an item increases the quantity of an existing line item.Add coffee twice → one line item, quantity 2.
AK-02Quantities must be whole numbers. A quantity of 0 removes the line item.Change from 1 to 0 → line item removed; reject negative quantities.
AK-03Stock limits cannot be exceeded.6 coffees when only 5 are in stock → error; keep the cart unchanged.
AK-04Calculate prices in cents. The server is the source of truth.2 × 1,490 + 490 shipping = 3,470 cents.
AK-05Shipping costs 490 cents and is free for basket values of 5,000 cents or more.4,999 → shipping 490; 5,000 → shipping 0.
AK-06An empty cart totals 0; checkout is disabled.Remove the final item → no checkout.

Example interface contract

PUT /cart/items/{productId}
Body: { "quantity": 2 }  // sets the requested quantity
200: updated cart including server-side totals
400: invalid quantity · 404: unknown item
409: insufficient stock · cart remains unchanged
quantity: 0 removes the line item; the response contains the remaining cart.

The demo runs these rules in the browser. A production implementation must check access, current prices, and stock on the server. This contract is a draft, not a live API endpoint.

Measurement points from V2: successful quantity changes, cart errors, and checkout starts. Attribute events to each action and do not collect free-text personal data.

Specs, prompts & artifacts

SPEC

Versioned spec · CART 1.0

Complete sample with rules, acceptance criteria, measurement, and operations.

Open spec ↗

Possible mapping to Jira / Confluence

Link the pitch or brief to the small Jira issue. Reference CART 1.0 as the authoritative versioned source; record open rules and decisions.

Explore the tooling approach ↗

Try the cart & run the demo tests ↓

Day 3BuildValueLearning

Connect test cases and small implementation steps

Focus: Test quantities, stock, cent totals, and the shipping threshold; implement measurement events.

Output: Test cases linked to acceptance criteria and a first verifiable implementation.

View detailsClose details

Human responsibilities

Delivery Team

Agent support

Reviewer · Workmaster

Evidence & decision

The agreed acceptance criteria define the test standard. A Red test must fail on missing behavior before the smallest matching implementation follows.

Work and rituals on this day

B5–B8
Test, build & review

Days 3–4: tests for quantities, stock, totals in cents and the shipping threshold; small implementation, refactoring and independent review. Confirm the remaining scope at the agreed budget checkpoint. Measurement events are built in.

Participants: Delivery Team with Reviewer and Workmaster; independent human reviewer.

Support & small tasks
Process and participants · day 1 →
Gather experience
Process and participants · day 1 →
Flow Check
Process and participants · day 1 →

Specs, prompts & artifacts

SPEC

Versioned spec · CART 1.0

Complete sample with rules, acceptance criteria, measurement, and operations.

Open spec ↗

Possible mapping to Jira / Confluence

Connect the Jira issue, spec version, acceptance criteria, pull request, and test evidence. Acceptance and release reference the same verified state.

Explore the tooling approach ↗

Try the cart & run the demo tests ↓

Day 4BuildLearning

Refactor and review independently

Focus: Review the change and edge cases; confirm remaining scope at the budget checkpoint.

Output: Review findings and test evidence tied to the checked code and spec versions.

View detailsClose details

Human responsibilities

Delivery Team · Product Owner

Agent support

Reviewer · Workmaster

Work and rituals on this day

Test, build & review
Process and participants · day 3 →
Support & small tasks
Process and participants · day 1 →
Gather experience
Process and participants · day 1 →
Flow Check
Process and participants · day 1 →

The concrete shopping cart scenario

B4–B10

From test case to approved change.

This walkthrough uses CART 1.0. The AI task references the agreed spec version, and test evidence cites its acceptance-criteria IDs. Review, business acceptance, and release connect that version to the verified code. New spec drafts become the source of truth only after explicit approval.

StepConcrete actionAccountability / AI
B4 · PlanPlan the cart state, cent-based calculations, and quantity rules as small components.Team / Planner
B5 · RedTest: adding an item twice creates one line item with quantity 2. It must fail before implementation.Team / Reviewer
B6 · GreenImplement only the required behavior until the tests pass.Team / Workmaster
B7 · RefactorConsolidate calculations without changing the rules. Run the tests again.Team / Workmaster
B8 · ReviewAlso test counterexamples: 0, −1, decimals, insufficient stock, and the shipping threshold.Human reviewer / separate AI Reviewer
B9 · AcceptanceThe Feature Partner checks real shopping flows and confirms the criteria.Feature Partner; Product Owner clarifies changes
B10 · ActivationRelease to a small user group. Check measurement, error rates, and rollback.Team + human approval

The demo test cases can be run.

The button in “Try the cart” checks quantities, stock limits, totals to the cent, and shipping costs. It does not replace server integration or business acceptance.

Open the testing task in the prompt workshop

Specs, prompts & artifacts

SPEC

Versioned spec · CART 1.0

Complete sample with rules, acceptance criteria, measurement, and operations.

Open spec ↗

Possible mapping to Jira / Confluence

Connect the Jira issue, spec version, acceptance criteria, pull request, and test evidence. Acceptance and release reference the same verified state.

Explore the tooling approach ↗

Try the cart & run the demo tests ↓

Day 5BuildValueLearning

Accept and activate in a controlled way

Focus: Accept real scenarios at 14:00, then activate only with the required approvals.

Output: Acceptance and release evidence, plus verified measurement events.

View detailsClose details

Agent support

Reviewer · Workmaster

Evidence & decision

Business acceptance and production release remain separate decisions. Do not activate without the required approvals.

Work and rituals on this day

B9–B10
Acceptance & activation

Day 5, 14:00: Acceptance Slot for real cart cases. Then activate only with approvals in place and check measurement events. Record the release and user groups in the scorecard.

Participants: Feature Partner accepts the business outcome; the team and release owner deliver.

Open related guidance ↗
Support & small tasks
Process and participants · day 1 →
Gather experience
Process and participants · day 1 →
Flow Check
Process and participants · day 1 →
ready for acceptance · day 5/8
Acceptance Slot

Day 5 at 14:00: 20 minutes for the cart. Day 8 at 13:30: brief targeted check of the bug fix, 10 minutes in this example. For low-risk tasks, the same feedback can be asynchronous.

Participants: Feature Partner or deputy with the responsible developer.

Open related guidance ↗

Specs, prompts & artifacts

SPEC

Versioned spec · CART 1.0

Complete sample with rules, acceptance criteria, measurement, and operations.

Open spec ↗

Possible mapping to Jira / Confluence

Connect the Jira issue, spec version, acceptance criteria, pull request, and test evidence. Acceptance and release reference the same verified state.

Explore the tooling approach ↗

Try the cart & run the demo tests ↓

Try the cart & demo test casesAdd items, change quantities, and check the agreed rules.

The small online shop

Try it

Coffee

500 g · whole beans · 5 available
€14.90

Green tea

100 g · loose leaves · 4 available
€8.50

Ceramic mug

350 ml · dark blue · 3 available
€12.00

Shipping costs €4.90. Shipping is free for basket values of €50.00 or more. Identical items are grouped into one line item.

Your shopping cart

0 items

Check the cart rules

Overview of parallel work and rituals
EXAMPLE / FOUR WEEKS

From the first brief to impact.

A complete example timeline with feature work, a bug fix, everyday operations and all seven rituals. Day 1 is a Monday; it shows 20 working days without weekends.

How to read this: Bars show time windows, dots individual days. They are not effort estimates and do not require full-time work. Click a row or ritual for roles, time and outcome.
TimelineWeek 1Week 2Week 3Week 4
Working day1234567891011121314151617181920
BuildValueLearningEveryday operationsRitual
Workflow

Problem, spec & measurement plan

Day 1: agree on the problem, budget, hypothesis and measurement plan. Day 2: confirm rules, plan implementation and test cases. Example limits for the first cart: at most 5 team working days and €50 in AI costs; team effort is not calendar duration. The Spec Clinic postpones the additional wishlist.

Participants: PO, Delivery Team, Feature Partner and Measurement Partner; Scout and Planner support.

The four-week cadence belongs to the Value Review, not a prescribed development cycle. A feature may finish earlier or later. Acceptance, incident resolution and release do not wait for a regular ritual.