Stages S5–S7 — Application, Verification, Reversal

Purpose

The approved packet has to become a change in a real system, a reply the customer can read, and evidence that the thing they complained about actually stopped happening. Each of those three has a specific way of going wrong, and each failure is one v1 measured.

What runs this stage

Every stage also uses support.root — the only profile that reaches the human — and the platform's write_executor and write_auditor (Gating).

1. Application

P Nothing is applied outside an approved packet, and every applied change lands in the ledger with its statement, target, environment, mode and row count — never result rows (Trust and Data § 5).

Database corrections

F The discipline is the 5-step write: show → apply uncommitted → verify in the DB → replay the consuming query → COMMIT last; failed verification is a rollback, not a discussion (protocol, proven on SD-1757).

P On the platform its shape changes, because no agent turn may span an uncommitted write: apply-verify-replay run inside one connector call, or the connector holds the transaction under a lease that rolls back on expiry (Failure and Recovery § 1). The human's approval happens before the write opens. The discipline is preserved; the open transaction across a model call is not.

F The first pass must be complete: recovery SQL includes the downstream transfer and registry repair, not just the row that looks wrong (rule). A half-repaired object is a second ticket.

UI-driven application

P Some fixes are not statements: a retransfer button, „Върни към предложение", „Enable login" (Case Studies G-10 — SD-1717, SD-1729, SD-1554). They are an application kind of their own — UI action.

F PROD IPAL holds no non-person platform identity: seven Ablera accounts, all EMPL, each bound to a person and Identity-Server-provisioned (verified 02.09.2026, Challenge Rounds § R2 § 3).

P Three acting identities, never impersonation:

P The record is a WRITE_LOG row with WRITE_PATH=ui_action; UI_ACTION is a display label, not a separate table or ledger kind:

• the control, and the target handle;
• the pre-state hash — DOM text through the handle substitution;
• the backend RequestIds observed;
• the records produced: SR_USER_NOTES, MIGR_LOG, the status triple, TRANSFERRED_ITEMS;
• a screenshot artefact hash — never sent to a model;
• outcome and duration.

P Effect classes per action: retransfer and return-to-application are compensable, with the consumed number named; „Enable login" is compensable too — an Identity Server publish, an external call.

P Dry-run = reach the control and record its state; preflight = the precondition read immediately before. A UI action on a customer-facing environment is gated like a write.

C LDAP provisioning of aisa.ui.<env> (Bulstrad IT); whether „Enable login" runs under a non-administrator role.

Customer-visible output

P Public comments, transitions and emails are drafted by the communicator profile and sent only through the gate. The customer plug-in's register rules and channel behaviour apply (register.*, channels.* — Whitelabel Catalogue); for Bulstrad: Bulgarian register rules, Pending-as-resolved with customer confirmation, one internal note per ticket, pre- and post-write status refresh.

P The send-gate packet lists every re-identified datum with its audience; drafts use handles by default until approved (D116).

P Gate roles are those of Gating § 1: H5 — a customer-facing environment, not production alone (environments.<env>.customer_facing, D114) — is answered by the Approver for that environment; H7 by an Approver; and a customer-visible send (a W7-class write) is gated at H5-send, answered by the Approver for customer-visible sends.

External owners and customer-performed actions

P A designated customer or external owner acts in their own session after a gated instruction. Persist target, stable step, actor, request reference, opening time and expected returned evidence. The task parks with its age visible. A scoped response wakes verification; it does not create a platform write. Instructions resolve only an instructions-only objective. A repair waits for declared proof across the family, and a temporary exception waits for restoration. Case journeys §§ 3–4 gives the complete protocol.

Held batches

P Work approved in principle but not yet applied stays visible with its age and scope, and applying it is a single decision under the original approval with a per-item preflight. Approval and execution are separate: a proposal waits at a gate; HELD_BATCHES execution states are held, applying, applied or abandoned — and an ordered batch (scripts that depend on each other, SD-1863) is preflighted ordinally, not sampled (Case Studies G-18). P Re-preflight by age (D66): a batch older than held_batches.repreflight_after (default 7 days — Whitelabel Catalogue) is re-preflighted at application time, not at approval time — an ordered batch re-runs the preflight ordinally from the first unapplied item; a precondition that no longer holds re-opens the item's gate rather than failing mid-batch. Why: v1's HDesk backlog sat at 39 items for twelve weeks precisely because approved-but-unapplied work was invisible between sessions F: [backlog].

2. Verification

P Family cases carry an explicit membership inventory and assertion matrix (Case journeys § 4). Local statement counts supplement the mapped family invariant. Cross-system partial results are reconciled before dependent work. A consuming test can itself require a gate; verification wording never grants permission to issue, print or send.

P Verification re-checks the customer's symptom on the customer's surface — not the object that was edited.

Why: the named v1 failure is replying "fixed" after confirming the row changed, when the customer's actual action still fails F: [rule]. A corrected row and a working screen are different claims.

P The case reports the level actually reached (Architecture CR-3). "The row is correct" is not "the symptom is gone", and the report says which one was established.

P S6 names the surface it exercises, and where re-checking the symptom on a customer-facing environment would itself consume a number, generate a document or send a notification (Case Studies G-11), that effect is named as irreversible in the packet and approved explicitly — verification is not exempt from the effect classes.

3. Reversal

P Every applied change carries its revert path from the moment it is proposed (CR-7). Executing it is gate H7 — a human decision, never an agent's recovery reflex.

F Teardown derives from the write log: the set removed is exactly the set written (artifact). Effects outside the transaction — documents generated, numbers consumed, messages sent, external registrations — are compensated, not rolled back, and are named as irreversible in the packet where they cannot be (Failure and Recovery § 2).

4. What resolves a case — and who closes it

P The platform moves the ticket to Pending (= resolved); the customer's confirmation completes and closes it (D49; Pending-as-resolved). The platform brings it to resolved when all four hold:

1. the symptom re-checked on the customer's surface;
2. the customer-visible reply sent through its gate;
3. the revert path recorded and still valid;
4. the precipitation task durably queued with a sanitised result package; consolidation does not delay customer delivery.

F A closed ticket does not close its known issue — the KI register is walked separately, and 56 entries are open (KNOWN_ISSUES.md).

Challenges

• P Replaying the customer's surface automatically — driving the real UI as the customer's role — needs the browser connector and the declared platform/test identities and target-specific permissions; no impersonation is assumed. Until then verification names what it could and could not exercise.
• P Batch preflight effort for large held batches: per-item preflight against a 39-item batch is not free; sampling rules need defining.