📖About

Ninad ruling (2026-08-14): app access is declared in a closed vocabulary of access policy TYPES, held in the registry as first-class citizens, and every app MUST carry an owner agent and exactly one access policy type. The starting vocabulary (improvise where reality demands): confidential (no access except the owner and named exceptions), default (owner agent and their supervisors), global (all agents), public (all agents and all humans), classified (every agent sees only its own data), limited (named agents only).

Scope: (1) a registry table of access policy types with plain-language definitions; (2) a mandatory access_policy declaration on every app record plus the existing mandatory owner -- registration refuses an app missing either; (3) the shared app access gate derives its verdict from the declared type, still failing CLOSED; (4) a behavior-preserving backfill: every existing app is mapped to the type that matches its CURRENT posture (public set stays public, employee+mapping stays need-basis), no app's effective access widens or narrows silently; (5) the data dictionary carries a registered definition for each type; (6) the app-building guidance (pattern library path, handbook/runbook as appropriate) tells a new app to declare owner + access policy; (7) SST rescan reflects the new field; (8) regression tests: registration without owner or policy is refused, and the gate's verdict per type is proven.

⚖️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)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 7 pending must-have criteria stamped met at bypass_end on live re-performance evidence (CAROL-INI-3020): test test_ini3817.py: PASS (6 passed in 0.45s) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [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

• A registry table holds the access policy types (at least: confidential, default, global, public, classified, limited) each with a plain-language definition (must_have)
• Every app record carries exactly one access_policy referencing a registered type, and an owner agent; app registration refuses an app missing either (must_have)
• The shared app access gate derives its allow/deny verdict from the app's declared type and still fails closed on missing/unknown data (must_have)
• Backfill maps every existing app to the type matching its current effective posture, with no silent widening or narrowing of any app's access (must_have)
• The data dictionary carries a registered definition for each access policy type (must_have)
• App-building guidance (pattern-library build path and handbook/runbook as appropriate) requires declaring owner + access policy for a new app (must_have)
• Regression tests prove: registration refusal without owner/policy, and per-type gate verdicts (must_have)