📖About

Gaps 3 and 5 of CAROL-INI-3521, under Ninad's ruling of 2026-07-31 (CLI-190). THREE RECORDS NO APP READS: an agent's access grants, the actions its roles permit, and the model ringfence that decides which engine it may call are held in stores nothing surfaces, so an agent learns each constraint by hitting it. Ninad's ruling: extend Heimdall's existing access app rather than build a new one, and put the agent's OWN constraints into what it carries. THE ENGINE: the stored model field is blank for 20 agents and states a retired engine for 19. Ninad's ruling: read it live from the same source the intelligence screen uses, because model assignments change several times a day, and an agent must name the service and the track it is working in alongside the model. THE ROW-LEVEL FENCE: CAROL-INI-3526 fenced a store only when every app reaching it is confidential, leaving four shared stores where a confidential app's records sit beside ordinary ones. Ninad's confidential rule is own-records-only for every agent including the owner, so those tables need a row-level fence, enforced deterministically rather than by trusting a model's WHERE clause.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• Current state at filing (Elrond validity check): The access app and app-access classification from the parent initiatives exist, but the three constraint records for agents are still not surfaced and the engine field is blank or retired for many agents. CAROL-INI-3526 fenced only stores reached exclusively by confidential apps, leaving four shared stores without row-level fencing. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• The fence moved one level finer; the test did not change — CAROL-INI-3526 could only fence a data store when EVERY app reaching it was confidential, because fencing on a single confidential reader would have taken the build record and the org catalogue away from all 39 agents. The row-level residual is now closed with the SAME test applied to the table: a table is fenced when every app that READS THAT TABLE is confidential. Derived by reading each app's own source and intersecting with the tables that really exist, so a new confidential app is fenced the day it is classified and there is no list to remember. Four tables in Carol's operating record and both tables of the visit log are now closed; the whole visit log therefore leaves the free-query surface, because everything it had to offer was fenced. (orion)
• A carve-out must carry a reason, and one does — The derivation named service_tracks, read only by two confidential money apps. That is org structure, not a party's records — a row names a track and points at its owner. Closing it would also have contradicted the same ruling that asked for the fence, which requires every agent to name the service and track it works in. It is exempted BY NAME with the reason written into the module, and the check asserts every exemption still has one. (orion)
• MY OWN DEFECT, caught by the check: a name fenced in one store was fenced everywhere — The first cut flattened the fence into a single set of table names. `apps` is a table in the sign-in store that only confidential apps read — and it is ALSO the estate's app catalogue in the registry. The flat set therefore took the app catalogue away from every agent, the exact failure CAROL-INI-3526 caught in itself. The fence is now per store, and the check asserts a name fenced in one store stays readable in another. (orion)
• The stored model column is no longer read anywhere, and the engine is derived per service and track — Ninad's ruling of 2026-07-31: read the engine live from the same source the intelligence screen uses, because assignments change several times a day; an agent holds a SET, not a field; and it must name the service and the track alongside the model. Resolution follows the CALL path (lane first, then a written pin, then the active provider), NOT the provider map's own per-worker helper — that helper reads only the written pins, so it put every chat worker on the fleet engine while the map placed the chat lane on its own subscription two hundred lines later. Following it would have made this module contradict the very screen it is required to agree with. The check drives both and fails if they part company again. (orion)
• A stale engine name does not only live in the model column — Stripping the column alone still had Athena telling people she thinks with Claude Opus 4.6, because her doctrine field holds a pasted specification that names it in prose — a consequence of gap 1 of CAROL-INI-3521, where 14 agents carry an inventory where their mission should be. Any remembered engine claim is now removed from the free text before it is handed over; the derived line is the only authority. Found by the check, not by reading. (orion)
• FINDING, not fixed here: Albus's chat is still pinned to Kimi — Every other agent's chat moved to gpt-5.6-sol under Ninad's ruling of 31 July (CAROL-INI-3470); albus-chat is still pinned to kimi/k3 in the provider config. A worker's own pin outranks the lane at call time, so the call uses Kimi while the intelligence screen — which places every chat worker under the chat lane — shows GPT. Both Albus and the screen have therefore been stating an engine he does not use. Deliberately NOT changed here: re-routing a lane is a cost decision and hiding one inside a display fix is the over-reach recorded in CLI-171. The conflict is instead NAMED, in the agent's own words and on the screen, until Ninad rules. (orion)
• FINDING: Scriber owns apps but holds no access grant — 38 of 42 agents hold standing grants, seeded from ownership by Heimdall's nightly reseed. Scriber owns apps and workers and holds none, so asked what he may reach he now answers, truthfully, that he holds no grant at all. Per the constitution's self-knowledge principle the defect is in the records, not in the agent. Raised for Heimdall. (orion)
• The grants come from the live store, not the copy still sitting in the registry — The same ac_ tables exist in two places: the gated access store (418 grants) and an abandoned copy in the registry (381), left behind when CAROL-INI-2057 moved them and never dropped. Reading the wrong one would have told every agent a slightly false story about itself. The check asserts the two still differ, so it cannot pass by accident once the copy is finally removed without someone noticing. (orion)
• [status-router] executing -> reviewing | event=dispatcher_transition | dispatcher state change (ds-s1)
• Two of Ninad's rulings meet at the fence, and the later, narrower one wins on its own ground — CAROL-INI-3432 (28 Jul) ruled that a supervisor sees EVERYTHING below — the reporting line IS the containment. CAROL-INI-3526 (31 Jul) ruled that a confidential app is own-records-only for EVERY agent 'including the owning agent'. A confidential store is therefore not a reporting-line question at all, and a boss is no more entitled to it than anyone else. Both checks were RECONCILED rather than weakened: the two assertions were INVERTED and BOUNDED, so the estate now proves that the only thing withheld from a supervisor is confidential and nothing else, and the exception cannot quietly widen. For the record, the sign-in half of that failure predates this session — it left the supervisor's reach with 3526 itself at run 157 and was never reconciled; only the visitor log is mine. (orion)
• An agent that owns nothing but confidential apps reaches no free-query source, by rule — Heimdall owns the sign-in app, the agent access app and user management — all three classified confidential — so under the row-level fence he reaches only the baseline every agent carries. CAROL-INI-3421 asserted that no app-owning agent is left with nothing to read; that assertion has been made STRICTER rather than relaxed: an agent whose apps are all confidential must be shown to actually receive its own records deterministically, which is precisely what own-records-only means and what this initiative built. CONSEQUENCE WORTH NAMING: Heimdall can no longer answer a free-form question about site traffic or sign-ins from his own apps in chat; he gets his own records instead. That is Ninad's rule applied literally, and it is reversible by reclassifying an app. (orion)
• Triaged against the previous runs rather than assumed — Run 158 vs 155-157: test_ini3421 was clean through run 157 and is mine; test_ini3432 carried one failure at run 157 and now two, so one is mine; test_ini3429 went red at run 157, before this session; test_ini3434, test_ini3423 and test_ini3424 have been red since run 155. Only the two that changed at run 158 were touched, and both are now green. (orion)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• Asked what limits it operates under, any agent can state its own access grants, the actions its roles permit, and the engines it is allowed and refused, without having to hit the limit to find out. (must_have)
• Asked what it thinks with, an agent names the service and the track it is working in and the engine that track actually uses today, read live at the moment of asking rather than from a stored value that can go stale. (must_have)
• No agent can read another agent's records out of a store shared between a confidential app and ordinary ones; each sees only its own rows there, and an attempt to reach the rest is refused rather than quietly emptied. (must_have)
• An operator can see the same three records for any agent on one screen in the existing access app, with no new app to own. (must_have)