feat(isac): grant agents baseline data contribution access

docs/DESIGN_SYSTEM.md

@@ -531,3 +531,13 @@ data-navigation items. Proposal lifecycle states use text as well as color:
 pending is orange/actionable, approved is green/configured, and rejected or
 failed is red/archived. Review decisions always use the standard ISAC confirmation
 surface and must never apply a proposal from a table-row click alone.
+
+Audit History may use a five-column KPI filter rail when all durable operational
+domains need first-class visibility. It retains the standard compact KPI height
+and collapses through the shared dashboard breakpoints; do not increase card
+height or create a second row solely to accommodate the fifth domain.
+
+Inherent permissions that cannot be removed through role or user assignment use
+the compact blue information rail above the affected access controls. Always
+name the baseline and enumerate its capabilities so operators do not mistake an
+empty role assignment for an account with no effective access.

docs/architecture.md

@@ -128,6 +128,14 @@ Data Approver. Data Editor retains direct-write access for trusted operators;
 Data Approver combines direct-write access with queue review. New ISAC data
 modules must use the shared moderation interception path and audit both the final
 mutation and proposal lifecycle.
+
+Every authenticated, active registered agent receives `isac.access`,
+`data.view`, and `data.propose` as baseline permissions in the authorization
+layer. This baseline is intentionally implicit rather than a removable role
+assignment, so it applies consistently to existing users and every account
+creation method. Registered agents can inspect live source data and submit
+moderated proposals, but cannot directly mutate canonical records, review the
+queue, or access unrelated ISAC operations without additional permissions.
 7. A successfully reverted event cannot be reverted again.
 
 Unsupported destructive identity operations, account deletion, incomplete