Challenge rounds — 02.09.2026

The record of how the wiki's open items were worked down on 02.09.2026, in three passes, and what each pass left. Every settled conclusion is now a numbered decision in the decision register or a P statement on the design page that owns it; this page keeps the reasoning, the measurements and the items still open, because nothing else does.

Section ids are stable — § GA-3, § CS-2.2, § R2-9. The CH ids inside the sections are the register ids of 02.09.2026 and do not resolve against today's Challenges Register, which had been regenerated twice by 02.09.2026 and several times since; each section names the page that carries its conclusion instead. The decisions still waiting for a person are on Open Decisions, which is the page to decide from.

GA. The goals completeness audit

What this was. A read-only audit of 00 Goals/*, Home.md, the Requirements Register and the Glossary, with the architecture pages skimmed for behaviour they implemented that no goal stated. Method: for each of the five goal areas, twelve dimensions marked present / partial / missing, with the statement ids that carried them. "Arch only" counted as a gap, because the Requirements Register and the Metrics page are built from the goals, not from the architecture. It is the record the Requirements Register's G-16 cites.

Where its conclusions went. The audit produced 30 gaps, 12 contradictions, an orphan list and six undefined terms. All 30 gaps landed as goal statements — Platform PG-9…PG-22, Configuration CG-10…CG-13, Support SG-10…SG-14, Source DG-7…DG-9, and the three proposed non-goals as N-9…N-11 (of which N-9 was later withdrawn by D81 and replaced by N-12). All 12 contradictions are resolved (§ GA-3). Of the six undefined terms, five are now Glossary entries; one is not (§ GA-4).

One dimension was later redefined. The audit marked Economics against a cost-per-ticket target. D52 and D79 removed money as a metric of this platform: no figure on any page is expressed in currency, and the valid measures are hours, bus factor, people involved, knowledge domains involved, elapsed time and vendor dependency removed. The Economics marks below are therefore a record of what was audited on 02.09.2026, not of what is measured now.

GA-1 The twelve-dimension matrix, as marked on 02.09.2026

P present · p partial · M missing (behaviour existed in the architecture, no goal stated it). P/p = present for the module, partial in one respect.

GA-2 The scenario walk — ten scenarios, and what each exposed

Each scenario was walked against the goals only. Nine came back partial and one missing; every uncovered step became a gap in the list above.

GA-3 The twelve contradictions, and how each was resolved

GA-4 What the audit flagged that is still not closed

• "Deployer" was still undefined as of 02.09.2026. It is used as an agent name on the Configuration and Source Components pages and in Stage Test and Corrections, and D84 gives it a gate (the deployer merges under H4), but the Glossary did not name it and its authority against DG-8 — who prepares against who executes — was stated per stage rather than once. Closed since: the Glossary carries a Deployer row, and D130 (the deployment agent triggers the estate's pipeline job) and D104 (estate DDL through the write executor under HW-ddl) settle who executes. The other five flagged terms (protected target, retention rule, commercial counterpart, L1/L2/L3, case type) are Glossary entries.
• C-11's probe. As of 02.09.2026 the reach measurement that decides whether Support reads PROD directly or through a tunnel had not been taken; it is the six reach rows of the Challenges Register, all closed by one probe from the QA host on first deployment. Since D132 there is no tunnel option: the probe answers direct or unreachable per target, and an unreachable target is one specific network request.

CS. Round 1 — design proposals for the B, C and D rows

What this was. On 02.09.2026 every class B (decision), C (deferred by design) and D (build item) row of the then-current Challenges Register — 63 rows — was given a designed answer and the event that would confirm it, rather than being left as "decide later". The register held 64 such rows at the time; CH-75 went to the repository agent instead (Measurements § RE-6).

Where the conclusions went. Sixty of the 63 are settled: as a numbered decision in the decision register, as a P statement on the design page named in § CS-1, or withdrawn because a later decision removed the work. Three were still open on 02.09.2026 and are kept in full in § CS-2, because the register still pointed at them and no other page carried their text: the source/intentgpt domain, the production-simulation criteria, and the network request to Bulstrad IT. One is still open today — the source/intentgpt domain; CS-2.2 was settled by D107 and D127, CS-2.3 by D128 and D132. The register itself was regenerated after this work and carried 12 rows with different ids at that point; the CH numbers below are the ids as they stood on 02.09.2026 and do not resolve against today's register.

Money removed (D79). The verifier-tier proposal (CH-03 / CH-37) set its keep-or-narrow rule as a multiple of a per-ticket currency figure. The figure and the multiple are struck; the tier structure survives on Metrics and Stage Investigation, and the measure is disagreements and retractions per tier.

CS-1 The 60 settled rows — where each conclusion went

Pages are named as they are today; the pages these rows were written against were renamed and merged on 03.09.2026 (D88, D94, D96).

CS-2 Still open

CS-2.1 The source/intentgpt domain (CH-05, with CH-30 and CH-49)

Proposed solution P. The node is stubbed now and deepened on the first case, and repository access is a prerequisite of the Support/Source wave, not a first-case task. The stub source/intentgpt/AGENTS.md is written by hand from what the estate already knows: the Beth anatomy (master prompt → line-of-business → minibot per operation; SRD_INTEGR.BETH_OPERATIONS_FILES), the health-AI retirement manifest on the branch (which behaviours move to native C#), and the placement rule below. Before that wave the intentgpt repository is added to the GitLab connector scope with a project access token so a worktree can be taken; if the repository cannot be reached, the case opens with a MISSING entry and the summarizer works from the retirement dossiers alone. Placement rule for intentgpt: because the component is being retired, the default placement is the smallest patch that removes the symptom; any extension produces a core-change proposition routed to development, with the note that the health path is replaced by the AI program. The seam map — which files hold intents, minibot prompts, the Serdica calls — is the summarizer's first output and becomes the node's § 1.

Alternatives rejected. Building the node only when a case arrives (the case then pays for access negotiation). Reading the repository now in full (it is being retired; the summarizer's index depth is enough).

Closes when. The first Source case touching intentgpt boots from a node that already exists and adds its seam map; the repository was reachable at case open. Owner: source author; access request: platform team.

Where it is carried. Source Details DG-3 and Agents Memory § 4 keep one C each — "seams unmapped until the first case" — as the confirming event. Source Module § 5 records that the eight real changes cover no intentgpt case for the same reason.

CS-2.2 Production-simulation criteria and the H5-SIM gate (CH-54)

Superseded, 04.09.2026 (D107, D127). H5-SIM is held by two roles, not two named people — Approver(PROD, simulation) granted to Ablera support lead and Bulstrad system owner, who holds a role being onboarding data in the customer plug-in (D107). The countersignature ask is replaced by a data-administration agreement signed by operator and client, of which the five criteria (D42) and the two-role gate are clauses (D127). The text below is kept as the record of the reasoning — see Failure and Recovery § 5 for the state in force.

Proposed solution P — the text to put to Bulstrad. Exception criteria, all of which must hold: (1) the evidence cannot be obtained on any non-production target, shown by a recorded attempt or a data-dependency argument in the plan; (2) every step's effect class is transactional, or compensable with a compensation already written; (3) the blast radius is one policy, one product version, or one account; (4) the pre-state is captured as evidence before the first write; (5) reconciliation is verified the same business day, and the reconciliation query is in the plan.

Approver set. The gate is a distinct kind, H5-SIM, whose role Approver(PROD, simulation) is held by two named people — the Ablera support lead and a named Bulstrad owner (IT or business, per system) — and, as the organisation's role-set choice under D34, the platform is configured so that the role is not held by any operator, which makes it a two-holder gate without a platform-wide four-eyes rule. The record names both holders.

Alternatives rejected. No production simulation ever (some transfer defects reproduce only against production INSIS state). A platform-enforced four-eyes rule (contradicts D34; the same effect comes from role configuration).

The doubt in the proposal, as recorded on 02.09.2026. H5-SIM achieves four eyes by role configuration to stay inside D34, but it is a platform-defined gate kind whose whole purpose is to require two people; if Bulstrad reads that as a four-eyes rule imposed by the platform, the proposal contradicts the decision it claims to respect.

Closes when. The criteria and the two names are written down and signed off by Bulstrad, and the H5-SIM gate kind is configured. Owner: Vladimir + Bulstrad. Carried as C on Failure and Recovery § 5; the gate kind is in Gating § 1 (D42).

CS-2.3 Internet egress and database routing from the Bulstrad QA host (CH-59, with CH-61 and CH-62)

Superseded in part, 04.09.2026 (D128, D132). Reachability follows the customer's policies, so this is a rolling process rather than one request: every new reach is a specific, defendable request and its answer changes CONNECTOR_SCOPES rows, never code (D128). “Topology B” is dead: there is no tunnel and no Ablera-side model gateway — model calls go directly to the provider's EU endpoint, and an unreachable target parks the case on a capability gap (D132). The request text below is kept as the record of what was asked — see Software Architecture § 10.3 for the state in force.

One request to Bulstrad IT covers both, with a fallback per part.

The request to send (to Bulstrad IT, copy Ablera DevOps):

Subject: Network access for the Serdica AI Support service on the QA host serdicaqa.bulstrad.bg (10.239.82.105) The new compose unit serdica-ai-support on the QA host needs the following outbound connectivity. Please grant or state which items are refused. A. Internet, TCP 443: <resource>.openai.azure.com (Azure OpenAI, EU region — Sweden Central or West Europe; the exact resource name follows with the provisioning), login.microsoftonline.com, graph.microsoft.com, ablera.atlassian.net, api.atlassian.com, gitlab.ablera.dev, bulstrad-registry.ablera.dev, vault.ablera.dev. B. Bulstrad network: hdesk.bulstrad.bg TCP 443; Kibana 10.239.82.110 TCP 80; the ABACUS gateway per environment (ports as deployed). C. Database routing from 10.239.82.105: TCP 1521 to 10.239.82.122 (STAGING IPAL) and 10.239.82.109 (PROD IPAL); TCP 1522 to 10.239.82.123 (STAGING INSIS); TCP 1521 to 10.239.82.103 (PROD INSIS). The service authenticates to Azure OpenAI with an Entra identity, keeps customer data on the Bulstrad network until the EU-resident provider under the existing DPA, and holds no inbound ports beyond the nginx location already on the host. A connectivity probe (curl -sI per FQDN, tnsping per database) will be run from the host after the change and its output filed.

Fallback if A is refused — topology B: an Ablera-hosted model gateway over the VPN holds the provider keys and the EU endpoint; the Jira, mail and GitLab connectors run on the Ablera side as the v1 CLIs do today, recorded per connector in CONNECTOR_SCOPES; the path is named in the DPA record.

Fallback if C is refused — per-environment connector hosts: a small container running only the Oracle connector library, behind mTLS, on the STAGING (.112) and PROD compose hosts, called by the QA platform over whatever route exists between the compose hosts; if no such route exists either, the Oracle connector for that environment runs on the Ablera side over the VPN and the case's grant records that path. In every fallback the grant model, the ledger and the handle boundary are unchanged — only the connector's address book moves.

The doubt in the fallback, as recorded on 02.09.2026. "A connector host on the STAGING and PROD compose hosts" assumes those hosts can be reached from the QA host at all and that Ablera DevOps may place a container there; both are the same unknown the challenge names, one layer down.

Alternatives rejected. Deploying the platform on STAGING or PROD (old source layout). Waiting for the answer before the first wave (wave 1 runs on QA-internal reach; the answer gates the customer-environment work).

Closes when. The probe output from the QA host is filed as F on Software Architecture § 3, or the topology-B / connector-host decision is recorded as a dated P. Owner: Bulstrad IT (answer), platform team (probe). The reach rows themselves are data, not code (D46), so the answer changes CONNECTOR_SCOPES rows — see § R2-9.

R2. Round 2 — the rows nobody had investigated

What this was. The second challenge round of 02.09.2026: the register rows that no earlier pass had investigated — those whose "Investigation / proposed solution" column was empty (CH-10, CH-14, CH-15, CH-31, CH-46, CH-57, CH-81) and those whose pointer named a solution that did not address them. Read first, not repeated: § CS, Measurements § RE, Measurements § DB. Citations: path:line in the workspace, page § section in the wiki, and SELECT-only queries run that day (connections BST-PROD-IPAL-SRD_INTEGR, BST-PROD-INSIS-ABLERA_SUPPORT; both disconnected after use). Verdicts: F fact · P proposal · C still open, with what is missing.

Why it is still here. Eleven design pages cite a section of this report as the source of a F or a P. Each section below ends in Applied in, naming the page that now carries its conclusion; the page names are today's, not those of 02.09.2026 (D88, D94, D96). Two sections are superseded: § R2-7 (the S3b sub-stage) is withdrawn by D85, and the pointer-correction lists of the original §§ 11–13 were applied to challenges_triage.csv and the register regenerated — what survives them is in § R2-11. The register's CH ids below are the ids as they stood on 02.09.2026 and do not resolve against the twelve-row register that followed that regeneration, nor against today's.

Decisions in force when it was written: D39–D50 of the decision register — no Microsoft Agent Framework dependency unless it demonstrably saves work, the whitelabel renderer is a skill, one schema SRD_SUPPORT, the health branch's RabbitMQ libraries copied as libraries, reach as a platform capability through a tunnel connector, retention configuration with default "never expires", approval as a permission, POL only.

R2-1 CH-81 · Agent Skills — the HDesk and mail streams, counted

Challenge. The HDesk and mail streams (VIN corrections, framework onboarding) are under-counted; a title-level pass over hdesk/ and emails/ corrects the counts before the first Support eval set.

What I did. Read every hdesk/*/metadata.json (subject, queue, state; 52 folders), hdesk/_jira_map.json (77 OTRS→Jira mappings), hdesk/_history.json (13 status runs, last 19.06.2026), and the 38 ### Thread headings of emails/THREADS.md; classified each item into an Agents Memory and Skills § 9 shape, "Configuration-module intake" (a product change with no support skill shape), or "reference".

Finding F.

What the two archives actually are. hdesk/ is the OTRS queue "Ablera" — every one of the 52 cached tickets has queue = Ablera; states: очаква доработка 29 · обработва се 9 · нов 9 · затворен 3 · очаква потвърждение 2. It is the customer's product-change and CR queue, not the support stream. The OTRS support stream (VIN corrections, куха полица, ИП office onboarding) never enters hdesk/; it reaches the workspace as notification e-mails („Уведомление за нов билет", „Актуализация по резервиран билет") archived in emails/ — 30 of the 38 threads are OTRS-born and HelpDesk-only (no Jira ticket). The cache is also partial: _jira_map.json maps 77 OTRS tickets to Jira keys while only 52 are cached, and the last status run (19.06.2026) counted 32 on the dashboard against 40 in the cache.

Classification — HDesk "Ablera" queue (52).

Classification — emails/THREADS.md (38).

Overlap with the Jira archive is small and named: 1.27↔SD-1882, 1.13↔SD-1524/SD-1721, 1.34↔SD-1443, 1.18↔hdesk 00101947. Net new support cases from the mail stream: 34.

Proposed resolution P — the corrected counts.

Two rules follow. (1) The HDesk connector's intake is the OTRS queue, not the mailbox: the same ticket arrives twice (queue row + notification mail) — Stage Classification's origin-key dedup treats the OTRS ticket number as the key and the mail as a duplicate channel. (2) The "Ablera" queue is Configuration-module intake by default: a case opened from it starts at the configuration root's intake conversation (D35) — narrowed by D143: every client case opens on the Support root, and the queue's Configuration default is an S1 classification hint that leads to a handover (Hd), not a channel route — and the seven support-shaped exceptions above are re-routed by the root, not by the queue.

Caveat / C kept, reworded. The cache holds 52 of ≥ 77 queue tickets and the mail archive holds what an operator chose to file; the population is the live OTRS queue. The corrected counts above are the eval-set input; the first Support eval set re-counts on a full read-only export of the queue through aisa-hdesk (hdesk/scripts/gen_status.ps1, read-only mode) — owner: support author.

Applied in. Agents Memory and Skills § 8–9 — the two streams as rows, the corrected counts, #16 in build group 1 (D59); Support Module — intake rule (1). The open part survives in the Challenges Register against Agents Memory and Skills: the counts are re-taken on a full read-only export of the OTRS queue.

R2-2 CH-46 · Agents — consult latency: the consult queue

Challenge. A lateral consult is a spawned task on another profile; if that profile's domain is busy, the consult waits. Proposal named, not designed: per-domain queue, timeout, "no answer" as evidence.

What I did. Read Agent Runtime § 3–4, § 7 (parking, pool with fenced leases — Solutions CH-48), the agent-graph budgets (stage agent ≤ 4 concurrent sub-agents, 1 DB session per environment), the profile definition, Platform Details PG-12 (escalation intervals), Measurements § TT (median case 1.5–2 h), Support Case Studies Case 1 (consult to source.serdica-backend on a guard's semantics) and Case 7 (consult to configuration.abacus).

Finding F. "Busy" is not a worker: sub-agents run in-process in any pooled worker (Agent Runtime § 3, § 7; Solutions CH-48), so a consult on another profile can always be started. What it competes for is the owning profile's concurrency cap (≤ 4 sub-agents per stage agent; 1 DB session per environment; INSIS 6 sessions per user) and its budget slice. A consult is a Consult / ConsultReply message pair (Agent Runtime § 4) with no deadline, no priority and no defined "no reply" outcome today.

Proposed resolution P.

The queue is a view, not a table. A consult is a TASKS row with kind = consult, profile = <owning profile>, parent = <requesting task>, deadline, priority; the per-domain consult queue is TASKS WHERE kind='consult' AND state='open' ORDER BY priority, created per profile. Any pooled worker takes it under the fenced lease.

Capacity is reserved, not shared. Every profile that may be consulted declares budget.consult_concurrency (default 2) — a slice of its own cap that stage work cannot consume, so a long S2 run cannot starve a Support investigator's pricing question. A consult task never spawns (depth 1), never writes, and reads only through the requester's grant subset (grants ⊆ requester's — a consult cannot read what the asker may not).

Deadline. The requester sets it from its own budget: 10 minutes wall-clock for a memory-only consult (answered from the owning node and articles, no connector call); 30 minutes for a consult that needs reads; never more than the requester's remaining turn budget. Ten minutes is under a tenth of the median v1 case (1.5–2 h, Measurements § TT); thirty is the size of one investigation phase.

No answer is evidence. On expiry the runtime, not the consulted agent, writes ConsultReply {outcome: no_answer, reason: timeout | refused | budget, waited_s, queue_depth_at_request} with trust class absent. The requester continues with the question listed as open evidence; the verifier treats it as unsettled, never as settled-by-silence. The same question hash within one case returns the earlier reply (no second spawn).

Priority. Consult priority = the requesting case's SLA class (Sev 1 > Sev 2 > Sev 3/4; a configuration case ranks as Sev 3); within a class FIFO; a requester at ≥ 80 % budget or with a gate waiting on it gets one step up. No preemption of a running consult or of the owner's stage work — the reserved slice is the whole mechanism.

Escalation. After no_answer a Sev 1–2 case may re-ask once with priority urgent; any other case proceeds and emits a Finding to the owning domain: "question X went unanswered" — the dreaming pass reads unanswered consults as the signal that an article is missing.

Alternatives rejected. Consults on the requester's own profile (loses the owning domain's judgement — the reason consults exist). Preemption (a half-written stage plan is worse than a ten-minute wait).

Confirms it. T1 ledger per domain: consult wait p50/p95, no_answer rate. Targets: no_answer < 5 %, p95 wait < half the deadline. Above 10 % no_answer for a domain, raise its consult_concurrency before touching the deadline. Owner: platform team (T1).

Applied in. Agents § 5 — consult mechanics, and D92 which fixes the consult/handover distinction around them; Agent Runtime § 4 — Consult/ConsultReply with deadline, priority, outcome; Agents § 0 — budget.consult_concurrency. The wait and no_answer targets remain a first-wave measurement.

R2-3 CH-31 · Stage Application and Verification — the UI-action application kind: acting identity and audit record

Challenge. Some fixes are UI actions — retransfer, „Върни към предложение", „Enable login" (SD-1717, SD-1729, SD-1554). The acting identity (operator's own account, or a service account with an impersonation policy that does not exist yet) and the ledger record are undefined. Note: Solutions CH-31 answers the verification replay (test identities, register row CH-32); this row is the application side and was empty.

What I did. Read Support Case Studies Cases 1, 5, 8 and the G-10/G-11 gap rows; memory/feedback/insis_dml_executor_and_username.md; Trust and Data § 2–4 (grants, iteration grants, browser evidence); the service-identity list (now Software Architecture § 10); Failure and Recovery § 2, § 4. Ran on PROD IPAL: the column sets of SRD_SYS.USER_ACCOUNTS, SRD_SYS.USER_ROLES, SRD_CUST.SR_USER_NOTES; accounts with company = ABLERA or user_name/user_email like %ablera%/%underwr%; USER_TYPE distribution.

Finding F. - v1 performed the SD-1717 retransfer „Подпиши и трансферирай" as an Ablera staff account (abl_underwriter in the case study), the INSIS row then carried the transfer layer's username, not the operator's (SERDICA_ACCESS is what the IPAL→INSIS transfer writes — insis_dml_executor_and_username.md § 2); SD-1729's „Enable login" ran from the admin UI; SD-1554's fix is a four-step UI sequence with decisions between steps (Case Studies Cases 1, 5, 8). - PROD IPAL (02.09.2026): seven USER_ACCOUNTS rows with COMPANY = 'ABLERA', all USER_TYPE = 'EMPL', LOCK_ACCOUNT = 'N', CURRENT_BRANCH = 1915213, roles UR_OPERATIONS, UR_UNDERWRITER, each bound to a person (SR_CUST_ID set) and Identity-Server-provisioned (USER_GUID set), USER_NAME empty (the login key is the e-mail). No non-person platform identity exists in IPAL today. USER_TYPE population: EMPL 8 063 · AGENT 999 · NULL 4 155. - SR_USER_NOTES(SR_USER_NOTE_PK, USER_ACCOUNT_ID, SR_CUST_ID, SR_POLICY_ID, SR_CLAIM_ID, AUDIENCE, NOTE, TSTAMP, IS_READ) — every UI action leaves rows keyed by the acting account and the policy; this is the natural write-log record of a UI action. USER_ROLES(USER_ACCOUNT_ID, USER_ROLE).

Proposed resolution P. Three acting identities, chosen by action kind and environment class. The platform never acts under the reporter's user and never holds a person's credentials; impersonation is rejected (Authority has no impersonation grant, the audit could not separate person from platform, and a person-tied account is personal data in the ledger).

The audit record. A UI action is a write-log row of kind UI_ACTION: {case_id, plan_step_id, grant_id, environment, actor_account, control (route + control label, e.g. «Подпиши и трансферирай»), target (handle), pre_state_hash (the state fields' DOM text through the connector's handle substitution), request_ids (the backendfields.RequestIdvalues observed — Kibana-correlatable), produced_records: SR_USER_NOTES pks by actor_account after t0 · MIGR_LOG rows for the policy after t0 · the C_POLICIES status triple after · TRANSFERRED_ITEMS row, screenshot_artefact_hash (a customer-identifying artefact under evidence retention, never sent to a model — Trust and Data § 4), outcome, duration}. The ledger keeps handles; the write log keeps identifiers (PG-13).

Effect classes per action (Failure and Recovery § 2, § 4). Retransfer: compensable (return-to-application) with the irreversible parts named when the transfer issues (INSIS numbering, documents, ГФ registration for 4710); return-to-application: compensable (re-transfer) but a consumed number is named; „Enable login": compensable (disable) — it publishes the Identity Server profile, an external call. Dry-run of a UI action = navigate to the control and record its enabled/disabled state without acting (the "reach" test). Preflight = the action's precondition read immediately before (the status triple, SR_USER_NOTES tail, INSIS state) — a mismatch re-opens the gate with the diff. A correction series (SD-1554) runs under an iteration grant bound to object set + day (Trust and Data § 4 G-17), one preflight per iteration.

INSIS attribution. Whatever IPAL identity clicks, the INSIS rows carry SERDICA_ACCESS (the transfer layer). The record therefore does not claim INSIS attribution; it links the MIGR_LOG trace and the INSIS POLICY_ID that resulted.

Alternatives rejected. Impersonating the reporter (above). A shared human account for the platform (the v1 shape: a person is on the hook for what a program did; and it is personal data in SR_USER_NOTES forever).

Still C. (a) Bulstrad IT provisions the LDAP entry for aisa.ui.<env> — request text = the CH-59 pattern; (b) whether „Enable login" (Identity Server publish) can run under a non-administrator role — one look at the admin route's AllowedRoles; (c) confirmed on the first T3 UI action: the UI_ACTION row and its produced records present, the actor never a person.

Applied in. Stage Application and Verification — the UI-action kind with the identity table and the UI_ACTION record; Software Architecture § 10 — the IPAL UI actor aisa.ui.<env>; Failure and Recovery § 4 — the UI-action effect classes. The open part survives in the Challenges Register against Stage Application and Verification: the browser connector and the impersonation policy for UI actions are a build item, and (a)–(c) above are its confirmations.

R2-4 CH-44 · Agent Framework — framework versioning

Challenge. A framework change (loop, pipeline) alters every agent's behaviour without any profile changing; the eval sets of all published profiles re-run on a release and the ledger records the framework version per turn. Whether that is affordable is the eval-cost question. Register pointer wrongly names the profile-inheritance solution.

What I did. Read Agent Framework § 1–5, the ledger record fields (now Architecture § 1, the ledger), the prompt-governance sections (now Agent Framework § 6), Solutions CH-71 (eval budget: nightly dirty domains, weekly module corpus, 20 % of case spend), Agent Runtime § 9.2 patterns 18–19 (replay tests), the image-tag deployment model (now Software Architecture § 10), and the ≈ 30 profile rows across the three modules.

Finding F. The ledger record already carries "profile, prompt and adapter versions" but not the framework's; eval sets re-run on domain, skill or route change (CR-4) and no framework trigger is named; the deployable is one image per release, so a framework version is an image tag by construction.

Proposed resolution P. 1. The framework version is a record field. framework_version = the webservice assembly's informational version + git sha, stamped on every turn record and COST_LEDGER row beside profile/prompt/adapter versions, and on every OpenTelemetry invoke_agent span as serdica.framework.version. A case resumed under a newer framework writes a FRAMEWORK_CHANGED ledger event; checkpoints carry a schema version and release n must read release n−1's checkpoints. 2. What re-runs is decided by the release's own manifest. Every framework release names the § 1 services it touches (affects ⊆ {loop, tools, memory, gates, records, spawning, governance, operations}). Re-run rule: replay tests always (recorded sessions, no API keys — the framework's own regression, in CI); the eval sets of profiles whose declared services are in affects plus a canary set (one root and one stage profile per module, in full); a full re-run of every published eval set only when affects includes loop or tools — context assembly, compaction and the permission pipeline are the two services that change every agent at once. 3. Budget and cadence. A framework release is scheduled like a publish — the pre-release run is mandatory and outside the weekly 20 % envelope of Solutions CH-71; releases are at most monthly in T3. Size: ≈ 30 published profiles × 20–50 graded cases = 600–1 500 gradings per full run — affordable monthly, not per commit. 4. Rollback is redeploying the previous image tag; sessions are not migrated (checkpoints are data).

Alternatives rejected. Full re-run on every release (patterns 18–19 already cover the loop mechanically; the eval sets measure agent judgement, which a records change does not touch). No re-run below loop (a tools change to the permission pipeline changed every write path in dsh's own history).

Confirms it. The first framework release after a publish: the delta report (sets run, regressions found). If two consecutive loop releases show zero regressions in the full run, the canary rule replaces the full run. Owner: platform team.

Applied in. Agent Framework § 6 — framework versioning and the release trigger; Architecture § 1 — the framework version in the ledger's record list. The first-release delta report remains the measurement.

R2-5 CH-82 / CH-83 · Software Architecture — memory store shape; the handles table in SRD_SUPPORT

Challenge. Git bodies + Oracle metadata versus Oracle CLOBs; and whether the pseudonym map may live in SRD_SUPPORT at all. Register pointers name the backup and the pseudonym solutions, neither of which decides these two.

What I did. Read Software Architecture § 3, § 6; the memory tree and its publication states (now Agents Memory § 1–2, § 5, § 7.4b — states, version pinning, immutability); Measurements § RE-8 (retrieval alternatives run over bodies); Measurements § DB-6 (QA has no working backup); Solutions CH-34 (CASE_HANDLES), CH-80 (no person pseudonym), CH-02 (15-minute export to a place the DB account cannot reach); Platform Details PG-13 (retention is configuration; default never expires; only the customer closes).

Finding F. Four facts decide the store: articles are immutable once active and versioned (Memory § 7.4b); retrieval is measured over bodies (Repo evidence § 8 — the grep alternatives index full articles); the platform already owns a GitLab repository for the PL/SQL mirror (Software Architecture § 6); and the "one backup domain" argument for CLOBs is void today — QA has no valid backup (DB evidence § 6), so an Oracle-only store would have no durable copy while a GitLab-mirrored repository has one. For handles: today's decision is one schema, no separate runtime principal, so "a separate more restricted schema" contradicts the decision; and the write log already carries identifiers in SRD_SUPPORT by decision (PG-13), so a second identifier-bearing table in the same schema changes nothing about the schema's classification.

Proposed resolution P — memory store. Git is the store; Oracle is the projection. Repository aisa-memory on the QA host volume, mirrored to gitlab.ablera.dev by push (project token, push-only); layout = the tree of Memory § 1; one file per article <domain>/<slug>.md with frontmatter {id, version, state, owner_profile, provenance[], verify{}}; AGENTS.md per node. States live in the frontmatter too, so a state change is a commit. SRD_SUPPORT.MEMORY_ARTICLES (id, domain, slug, version, state, git_sha, body_hash, owner_profile, created_case, activated_by, retired_by) is an index rebuildable from the repository, and memory reads/writes are ledger events as today. Write order: commit first, row second; verify-memory.sql + git log at start reconcile the row side to HEAD. Search: ripgrep over the working tree (the measured baseline's medium); a vector index is a rebuildable projection over the same files. Reasons: history and diff for free; the PII scan and the writing-practice checks are file tools; the durable copy exists today; the cross-case join key (Solutions CH-80, decided as D44) is a frontmatter field, not a column.

Alternatives rejected. CLOBs (no durable copy on QA today; diff and history re-implemented; file-based tooling lost). Git only (no queryable state, no join to the ledger's article-version pins).

Confirms it (wave 1). Every row's git_sha resolves and body_hash matches (100 %); the retrieval measurement runs over the working tree; a rehearsal drops MEMORY_ARTICLES and rebuilds it from frontmatter with zero differences. Owner: Vladimir (decision), platform team.

Proposed resolution P — handles table. CASE_HANDLES lives in SRD_SUPPORT, and the boundary is cryptographic, not schematic. CASE_HANDLES (case_id, handle, kind, value_enc RAW, key_id, created, destroyed_at); value_enc is AES-GCM under a per-case data key wrapped by a Vault transit key — Oracle never holds plaintext, a DBA's SELECT * and every backup carry ciphertext, and the key material is not in the database. Re-identification = decrypt inside the connector process + ledger event REIDENTIFY. Destruction when the customer closes the case (PG-13) = delete the rows and destroy the case data key in Vault — crypto-shredding, so backup copies become unreadable too. Grants: the platform account only; no view, no synonym, no DB link exposure. Retention rows for the class handles default to "at customer close", editable like every retention row.

Alternatives rejected. A separate restricted schema (contradicts today's one-schema decision; protects one of two identifier-bearing tables). Oracle TDE alone (protects the file, not the DBA's SELECT).

Confirms it. The data-boundary fixture (Solutions CH-34): ten identifiers → zero plaintext in any SRD_SUPPORT column except WRITE_LOG.statement; SELECT * on CASE_HANDLES shows ciphertext; a shredded case's rows cannot be decrypted. Owner: platform team (T3).

Applied in. Software Architecture § 6 — the memory store and the SRD_SUPPORT rows; Architecture § 1 — CASE_HANDLES in the SRD_SUPPORT evidence group with the encryption note; Trust and Data § 4 — handles crypto-shredded at customer close. The wave-1 rebuild rehearsal remains the measurement.

R2-6 CH-36 / CH-45 · Which investigator leads a cross-system symptom — the two-phase rule and its measurement

Challenge. Investigators are profiled by symptom (D11); most cases span systems; the lead rule is "set on the first ten cases". Solutions CH-35 already proposes a symptom-vocabulary precedence (transfers → printing → pricing → access → master data → health) and flags its own doubt (Solutions § b-5): a printing symptom caused by a transfer defect would be led by the wrong investigator for its first hour — the rule may need the mechanism hypothesis.

What I did. Read Stage Investigation § 1–3 (mechanics 0–8; the verifier), the support agent graph, Support Case Studies Cases 1, 3, 7, 8 (which domains produced evidence), Agents Memory and Skills § 8 (transfer 22 %, corrections 32 % — most corrections are transfer consequences), Solutions CH-35.

Finding F. The symptom vocabulary is available at S1 at zero model cost; the mechanism hypothesis is better but exists only after mechanics 0–2 have run (Case 7: the transfer/pricing question was decided by the invocation evidence, not by the customer's phrase). The two are not alternatives; they are two moments.

Proposed resolution P — the two-phase lead. 1. Provisional lead at S1 by the CH-35 precedence — deterministic, so no case starts with a routing argument (D11). 2. Hypothesis checkpoint after mechanics 0–2 (cross-channel scan, id decode, invocation evidence) or at 20 % of the investigation budget, whichever first: the provisional lead emits mechanism_hypothesis {layer, system, domain, confidence} as a required phase output. If domain differs from its own, the root reassigns the lead to that domain's investigator with the evidence so far — recorded as plan revision 2 with reason hypothesis_reassignment; the first investigator becomes a consult. At most one reassignment per case; a second disagreement is a DeadEnd → H6 ("cross-system mechanism unclear"), never ping-pong. 3. The lead owns the mechanism sentence; every other domain is a consult whose reply is evidence (unchanged).

Measured on the first ten cross-system cases (a case is cross-system when ≥ 2 domains produced evidence). Per case: provisional lead · final lead · reassigned? at which minute · mechanics run before reassignment · spend before reassignment · verifier verdict. Decision thresholds: reassignment ≤ 2/10 keeps the precedence as is; 3–5/10 rewrites the precedence from the observed final leads; > 5/10 drops the provisional lead — triage then produces the hypothesis itself with one cheap model call. Secondary: spend before reassignment as a share of case spend (target < 15 %); per domain, consulted-but-never-leads count (a merge candidate).

Alternatives rejected. Hypothesis-only routing (a model call before any evidence, at S1). Vocabulary-only (the b-5 failure: the wrong lead for an hour with no correction step).

Confirms it. The ten-case table above, in the ledger. Owner: support author.

Applied in. Stage Investigation — the two-phase lead and its thresholds. Read with D83: investigation is entered from the take, so a case reaches S2 only when S3 finds no ready solution; the two-phase lead governs the cases that do enter it. The ten-case table remains the measurement.

R2-7 S3b · The INSIS sub-stage — withdrawn by D85

Status. This section designed the INSIS sub-stage S3b: an insis specification section, an oracle-insis connector catalogue of six write operations, a grant scope of its own, environment pairing, a teardown checklist and a transferred proof rung. D85 removed all of it. The INSIS side of a dual-system product is not configuration work: it is one PL/SQL script, run once per product, recorded as a named deliverable with an owner — the script, who runs it, on which environment, and the date. A change to the script is Development work reached at gate Hd. The configuration proof ladder ends at issued; arrival in the incumbent system is proved by the Support module, which owns transfer investigation. The design in this section is therefore not planned work, and any page that still describes S3b, the insis specification section, the INSIS teardown or a transferred rung is out of date, not ahead.

What survives — the measurements taken on PROD, 02.09.2026 F.

• Seam sizes per product — SRD_INTEGR.CFG_MAPPING_COVERS: 1100 = 69 · 1101 = 67 · 1102 = 69 · 1103 = 69 · 3607 = 6 · 2215 = 31. CFG_MAPPING_LIMITS: 2215 = 14, cargo 0, 3607 0. CFG_MAPPING_COVERS_COMM: no rows for any of the six. CFG_MAPPING_FLFLD: 874 rows, columns PRODUCT_CODE, INSIS_TAB, INSIS_FLD, IPAL_TAB, IPAL_FLD, DEFAULT_VALUE, MSG_INFO, QST_ORDER, STMT, QUEST_LEVEL, VALUE_MAX_LEN.
• INSIS contract sizes — CFG_GEN_COVERS@insis: 1100 = 188 · 1101 = 6 · 1102 = 187 · 1103 = 187 · 3607 = 17 (the framework carries clauses only; the children carry the peril decomposition); CFG_GEN_CONDITIONS: exactly 1 row per product; CFG_GEN_PREMIUM_TAXES: 1100 = 83 · 1101 = 80 · 1102/1103 = 83 · 3607 = 6.
• ABLERA_SUPPORT can write the INSIS contract tables — it holds roles INSIS_DBA, INSIS_USR, INSIS_STAFF, GF_ADMIN, XMLP_* and the system privileges SELECT ANY TABLE, CREATE TABLE, CREATE ANY SYNONYM, UNLIMITED TABLESPACE; INSIS_DBA grants INSERT/UPDATE/DELETE/ALTER on HT_INSR_TYPE, CFG_GEN_COVERS, CFG_GEN_CONDITIONS, CFG_GEN_PREMIUM_TAXES, CFG_GEN_RISK_LIMITS, CFG_PRINT_DOC and the transactional tables. The credential is far wider than any grant the platform would issue; whoever runs the script runs it under that credential, which is why the script is a named human deliverable and not a connector operation.

Applied in. Stage IPAL § The INSIS side; Configuration Module § 7; Stage Normalization § WS-3.

R2-8 CH-28 · The product schema — v1 shapes for the v0 gaps

Challenge. Known shape gaps of v0 (Configuration Module § 8 cases D, M, P, S): conflict groups; LBRR object scoping; LB_COVERS_DEF dimension and currency; loading rating file / formula / cap / per-LD combination; ld_constraints; top-level limit_restrictions; documents; annex_types; tariff_constraints.kind lacks bonus-term and group-size gating; level-variant covers and consumption modes (8000); tariff required although cargo has no ABACUS tariff; rating_owner. Register pointer wrongly names the rule-combination testing solution.

What I did. Read contracts/product.schema.json in full; the configuration cases CS-3–CS-7 and the gap rows D, M, P, S (Configuration Module § 8); knowledge/product_config_new_product.md § 4 (the LB_*/LBRR_* shapes); Measurements § DB-2 (PR_PRICING_FACTOR_ANNEX = per-product annex change-sensitivity list); Solutions CH-01 (versioning: additive = minor), CH-20 (meta.lifecycle).

Proposed resolution P — schema 1.1, additive, all additionalProperties: false. Field names follow the existing vocabulary (key, source, dim ∈ V|P, currency ^[A-Z]{3}$).

schema_version → "1.1"; validate_product.py gains: cross-reference of every cover_rules.*.cover, depends_on, dependent_on, ld_constraints.ld_codes, annex_types.change_sensitive_factors and documents.gates.param against covers[], ld[], factors[]; the rating_owner conditional requirement; the two cover counts. The broken fixture gains one violation per new rule. Every S2–S5 prompt declares the major it reads (1.x).

Alternatives rejected. A free extensions{} bag (four stages read four things); top-level limit_restrictions (it is a cover rule, and S4 reads one object).

Confirms it. The three-export gap pass of Solutions CH-01 (4704 family, 1101/1102, 8000) round-trips with zero "no field for this" entries; the fixture rejects every new rule. Owner: S1 author.

Applied in. Stage Normalization § WS-3 — cover_rules, ld_constraints, documents, annex_types and the meta.rating_owner gate, as product.schema.json 1.1. The insis section is not part of it (D85); § R2-7 above says why.

R2-9 The SSH-tunnel connector — reach as a grant-scoped, data-declared platform capability

Superseded in part, 04.09.2026 (D132, closing A-8). Every connection is direct; the tunnel connector, the via host, route.kind = ssh_tunnel and the TUNNEL_* ledger events below are not built. What survives of this round: reach as data in CONNECTOR_SCOPES (now route.kind ∈ {direct, unreachable}), the probe, the host operations (exec_readonly/exec_privileged), credentials in Vault, and the hygiene item. The text is kept as the record of the reasoning — see Software Architecture § 10.3 for the state in force.

Challenge. Decision today: connectivity to the customer network (LDAP, BI Publisher, SOAP, INSIS) is a platform capability through SSH tunnels and connector tooling, not a request to Bulstrad IT. v1 seed: memory/reference/ssh_mcp_cli.md and the ssh-* servers in .mcp.json. Design the connector.

What I did. Read .mcp.json (one entry ssh-prod-insis: npx ssh-mcp to 10.239.82.103, key auth, placeholders for user and key), ssh_mcp_cli.md (exec + sudo-exec, not read-only, secrets via env expansion), memory/reference/eisoukr_mtpl_status_service.md (SOA host soaserver21p.bulstrad.bg:7030 reachable only through an SSH tunnel via a Bulstrad production server; hosts-file reroute to 127.0.0.1; diagnosis ladder DNS → tunnel), kat_getkatdata_soap_pull.md (same host, /AdminServices/GetKATDataPS), knowledge/policy_print_recipe.md (BI Publisher PROD/TEST endpoints on the same SOA hosts, HEAD → 500 = alive; credentials in plaintext in the knowledge file), identity_server_ldap_authentication.md (Bulstrad_LDAP 10.250.10.140:389, AD failover 10.8.40.17:389), the network-reach and identity sections (now Software Architecture § 3, § 10), Trust and Data § 2, Failure and Recovery § 4, the Source cases G22 (a host connector seeded from ssh-mcp) and G31 (operations actions).

Finding F. Every customer-network target the modules need already has a named path in v1: direct TNS to the IPAL/INSIS databases from the office/VPN; an SSH tunnel through a Bulstrad server for the SOA host (BI Publisher, EISOUKR, GetKATData — three services, one host, one tunnel); LDAP/AD reached today only by the Identity Server. None of it is declared as data; the one .mcp.json server is unscoped (exec, sudo-exec, any command).

Proposed resolution P.

One library, two operation families. AI.Support.Connectors.Ssh: tunnel — open_tunnel(reach_id) → handle, close_tunnel(handle), probe(reach_id); host — exec_readonly(host_id, command ∈ allow-list) and exec_privileged(host_id, command) as a gated write (G31; H5-equivalent on a customer host). sudo is never enabled on the platform's key.

A tunnel is a grant-scoped resource that has no grant of its own. Opening a tunnel requires the grant of its target: a tunnel to BI Publisher PROD is used under PROD / BI_PUBLISHER / read; to INSIS PROD under PROD / INSIS / read|write. The check runs per use (each operation names its tunnel_handle), not per socket; a tunnel closes at case close, at its target grant's expiry (4 h write / 7 d read, Solutions CH-84), after 30 minutes idle, or on the hard kill switch (PG-18). Tunnels to one reach row are pooled and reference-counted across cases (one process resource); at most 2 open tunnels per case.

Reach is data — CONNECTOR_SCOPES rows of kind reach, one per environment × system:

{ "environment": "PROD", "system": "BI_PUBLISHER",
  "target": { "host": "soaserver21p.bulstrad.bg", "port": 7030, "paths": ["/Bulstrad_BIPublisher_Mediator/ReportService"] },
  "route":  { "kind": "ssh_tunnel", "via": "bst-prod-app", "local_bind": "127.0.0.1:17030" },
  "modes": ["read"], "credential_ref": "vault:kv/aisa/prod/bip", "health": "HEAD → HTTP 500" }
{ "environment": "PROD", "system": "EISOUKR_SOAP", "target": { "host": "soaserver21p.bulstrad.bg", "port": 7030,
  "paths": ["/gf-eisoukr-integration/mtpl-service/v1.0.0", "/AdminServices/GetKATDataPS"] },
  "route": { "kind": "ssh_tunnel", "via": "bst-prod-app" }, "modes": ["read"] }
{ "environment": "PROD", "system": "LDAP", "target": { "host": "10.250.10.140", "port": 389 },
  "route": { "kind": "ssh_tunnel", "via": "bst-prod-app" }, "modes": ["read"], "failover": { "host": "10.8.40.17", "port": 389 } }
{ "environment": "PROD", "system": "INSIS", "target": { "host": "10.239.82.103", "port": 1521, "service": "INSISDB" },
  "route": { "kind": "direct" }, "modes": ["read", "write"], "credential_ref": "vault:kv/aisa/prod/insis-ablera_support",
  "operation_allowlist": "insis-v1" }
{ "environment": "TEST", "system": "BI_PUBLISHER", "target": { "host": "soaserver21t.bulstrad.bg", "port": 7030 }, "route": { "kind": "ssh_tunnel", "via": "bst-test-app" }, "modes": ["read"] }

plus via hosts as rows: { "id": "bst-prod-app", "host": "…", "user": "aisa", "key_ref": "vault:ssh/aisa-prod", "sudo": false }. The Bulstrad IT answer to B-1 changes route.kind from ssh_tunnel to direct on rows — never code: that is what makes reach a capability rather than a request. Unverified addresses (10.239.82.108, 10.239.82.101 — CH-67) are rows with "verified": false and are refused for writes.

Credentials stay in Vault. SSH keys through the Vault SSH engine (signed certificates with TTL = tunnel lifetime; no long-lived key on the host volume) or key_ref to kv; service credentials (BI Publisher ABLERA, EISOUKR, INSIS ABLERA_SUPPORT) as kv references resolved per operation (Agent Runtime § 9.2 pattern 20), never rendered into a prompt, passed to the tunnel process through a scrubbed environment. Immediate hygiene item: the BI Publisher credentials printed in knowledge/policy_print_recipe.md § 2 move to Vault and the file keeps the reference.

Ledger. TUNNEL_OPEN {case, task, grant_id, reach_id, via_host, local_bind, credential_ref, handle, opened_at} · TUNNEL_CLOSE {handle, reason: case_close | grant_expiry | idle | error | kill_switch, duration_s, ops_count} · TUNNEL_REFUSED {reach_id, reason}; every operation envelope carries tunnel_handle; probe results feed the Connectors screen (UI screen 7). Effects: open_tunnel → effects: [{kind: external_call, reversibility: rollback}] (closing it undoes it); exec_privileged per command; a BI Publisher runReport renders and registers nothing (document effect only if saved as an artefact).

Alternatives rejected. Keeping ssh-mcp as is (unscoped exec, personal key, sudo). Asking Bulstrad IT for routes first (D46; and topology B is the same tunnel drawn the other way).

Still C. (a) Which Bulstrad host is via — the v1 memo says "one of the Bulstrad production servers", the user's own tunnel; name it from Vladimir's tunnel configuration; (b) a platform SSH user on that host (the personal key is not acceptable for a service) — a small Bulstrad IT item that the decision does not remove, only shrinks to one account; (c) confirmed at T1 by the probe from the QA host: HEAD ReportService → 500 and a TNS ping through the tunnel, with TUNNEL_OPEN/CLOSE pairs in the ledger.

Applied in. Software Architecture § 3 — "Reach is data", the reach-row shape, the rule that the Bulstrad IT answer changes rows and not code, and AI.Support.Connectors.Ssh in the connector list; Failure and Recovery § 4 — tunnel effects; Trust and Data § 2 — "tunnel open" as a side effect. The probe itself survives as the six reach rows in the Challenges Register against Software Architecture — all closed by one probe from the QA host on first deployment.

R2-10 CH-10 / CH-09 · Value and ROI — the switch cost on ten interruptions; the 25 % rule per ticket type

Challenge. Two numbers nobody has: the switch cost per interruption (D-2) and whether the 25 % rule — true time is a quarter of the analysis card's estimate — holds for all ticket types (D-3). A third, the hourly rate (D-1), was struck: money is not a metric of this platform (D52, D79), so the unit is hours throughout.

What I did. Read Value and ROI § 1, § 2b, § 5; Measurements § TT (method, reliability, the ratio table); Metrics § Measurement log.

Finding F. The timing data cannot test the 25 % rule by itself: both sides are agent-written (agent elapsed vs the agent's own financial card), and the per-type ratio human_true / agent (reliable subset) already varies threefold — access/account 0.09, master data 0.13, data correction 0.28, transfer 0.29, configuration 0.29, incident 0.40 — which means either the agent's elapsed time is inflated for the low-ratio types (waiting on LDAP / Bulstrad IT is inside "elapsed") or the card over-estimates them. Only a human-measured handling time separates the two.

Proposed resolution P — one protocol, two numbers.

Sample. Ten consecutive real interruptions, across at least three developers, both channels (Jira and OTRS mail), excluding scheduled support slots (a batch is not an interruption). Same ten tickets feed the CH-09 measurement (ten tickets timed by hand alongside the platform).

Four timestamps per interruption, written by the developer into a one-line CSV as they happen (the tool appends to 90 Reference/Switch Cost <date>.md; nobody edits by hand): T0 interruption noticed · T1 work on the ticket starts · T2 ticket work ends · T3 back in flow on the previous task = first meaningful edit, test run or commit. Recorded with each: ticket key, request type, severity, DB write yes/no, what was interrupted (debugging / review / meeting / configuration).

Derived. Switch cost = (T1 − T0) + (T3 − T2) (context save + re-immersion); handling = T2 − T1. Report medians and p75 per component; the model uses the median switch cost. Cross-check T3 against git/IDE (last save before, first save after) — the objective trace where it exists.

The 25 % check per type. For each of the ten tickets, true/est = (T2 − T1) / human_est_h from the same analysis card; group by request type; the rule holds for a type when the median ratio is inside 0.15–0.35; outside it the flat factor is replaced by the per-type factor in Value and ROI § 2b and the Agents Memory and Skills saving is recomputed per type. Because a ten-ticket sample cannot cover nine types, the check runs first on the three largest (data correction, transfer, incident = 71 % of tickets) and the rest keep the flat factor with the caveat named.

Agent comparator. The agent's active window for the same tickets (the 43-ticket timeline_span median 0.95 h, and post-T3 the platform ledger's case clock minus parked time) — never elapsed.

Alternatives rejected. Self-reported percentages ("about a quarter") — the number under test. Literature values for re-immersion (15–25 min) — a prior, not a measurement.

Confirms it. The CSV with ten rows and the two derived numbers, filed as F in Value and ROI § 1 (switch cost) and § 2b (per-type factor). Owner: development manager. Two calendar weeks.

Applied in. Value and ROI § 5 — the protocol; § 2b — the per-type test. D52–D54 then set the surrounding rules: hours only, switch cost 20 % plus a fogginess risk, and a ± 25 % adjustment on both sides with the note that times vary by domain and person. The open part survives in the Challenges Register against Value and ROI: the ten-interruption CSV does not exist yet.

R2-11 What the pointer sweep left open

The original §§ 11–13 were a pointer-correction list for challenges_triage.csv and a summary of §§ R2-1 to R2-10. The corrections were applied and the register regenerated, so both are gone. Two items in them were substance rather than bookkeeping, and one of the two is still open.

• Open — the QT obsoletion state on the target branch. The data side is settled: no SALE_STAGE='QT' row exists on STAGING or PROD (Measurements § DB-1a). The code side is not: whether the quotation path is obsoleted on the branch a production-bound product will run on needs git grep -n -i "SaleStage\|\"QT\"" origin/bulstrad-staging -- src/ and a look at the UI wizard bucketing in field-generator.ts on that branch. One grep, not yet run. Carried in the Challenges Register against Stage Abacus.
• Settled — the DBA in the threat model. The challenge was carried by no register row. Resolution: the DBA is in the threat model for detection, not prevention — the periodic seal exported to a store the database account cannot reach is the anchor, and verify-ledger.sql compares the chain head against the last exported seal, so a database-side rewrite is detectable within one seal interval. Countersigning by an external service is not built. Applied in Architecture § 1, the ledger.

Queries run 02.09.2026 (SELECT only, disconnected after). PROD IPAL — ALL_TAB_COLUMNS for USER_ACCOUNTS, USER_ROLES, SR_USER_NOTES; USER_ACCOUNTS filtered by company and e-mail pattern with USER_ROLES aggregated; USER_TYPE counts; CFG_MAPPING_COVERS/_LIMITS/_COVERS_COMM counts for 1100/1101/1102/1103/2215/3607; CFG_MAPPING_FLFLD shape and count; CFG_GEN_COVERS/_CONDITIONS/_PREMIUM_TAXES@insis counts. PROD INSIS as ABLERA_SUPPORT — USER_TAB_PRIVS_RECD, USER_ROLE_PRIVS, ROLE_TAB_PRIVS, USER_SYS_PRIVS.