Settings Guardrails
Source-static proofPermission Governance Matrix
Fail-closed reviewMatrixPermission rows8 access checks ready.VisibilityMoney and ledger reviewNo checkout, payout, charge, refund, or ledger exportTestsReview denial casesOpen expected outcomes and evidence rows.
Permissions & visibility
Role visibility, denied tenants, and finance permission checks in one bounded matrix.
Permissions keeps owner summary-only, field-denied, and admin explicit-finance-permission evidence visible. The surface is read-only and cannot grant, revoke, mutate roles, invite users, or activate tenants.
Permission rows8
No checkout, payout, charge, refund, or ledger export
Permission rows8
Denied tenants0
Finance evidence rows4
Owner summary candidates1
Permission rowsFinance, ledger, property, and internal visibility
Each row shows Manager, Owner, Field, and Admin posture before any permission-write surface exists.
account.manageManager: NoOwner: NoField: NoAdmin: Yesproperty.readManager: Assigned accountOwner: Owner-visible assignedField: Assigned work onlyAdmin: Configuration contextwork.manageManager: YesOwner: NoField: Assigned checklist onlyAdmin: No by defaultmoney.view_operationalManager: YesOwner: Summary-onlyField: NoAdmin: Explicit finance permission onlyresident.ledger.readManager: YesOwner: NoField: NoAdmin: Explicit finance permission only
Field opens MoneyZero financial rows render
Role-filtered financial views deny 4 active POC money rows to Field and exclude denial tenants
Owner opens Long-Term delinquencyOwner-visible summary only, no resident ledger rowsOwner summary-only publication gate over 1 active POC report rows
Admin opens billingEntitlements visible, Stripe/payment setup remains deferredAdmin configuration view does not grant operational finance rows without explicit finance permission
Permission Review Metrics
Synthetic evidence onlyPermission rows8
Denied tenants0
Finance evidence rows4
Owner summary candidates1
Permission Matrix
Account scopedSection 1 permission-matrix carry-throughRead permission scope, role visibility, and guardrails together first so tenant-safe access review stays readable and fail-closed.Permission review remains synthetic-only, account-scoped, and no-live.
| Permission | Manager | Owner | Field | Admin | Guardrail |
|---|---|---|---|---|---|
| account.manage | No | No | No | Yes | No external account changes or invitations yet |
| property.read | Assigned account | Owner-visible assigned | Assigned work only | Configuration context | All reads require account_id and property assignment |
| work.manage | Yes | No | Assigned checklist only | No by default | No live dispatch or external messages |
| money.view_operational | Yes | Summary-only | No | Explicit finance permission only | Provider-agnostic rows only; no live payments |
| resident.ledger.read | Yes | No | No | Explicit finance permission only | Private resident ledger rows never render to Owner or Field |
| owner.statement.publish | Approval only | Read published | No | No by default | No email, export, or external sharing |
| integrations.manage | No | No | No | Placeholder only | No tokens, webhooks, credentials, or external writes |
| ai.review | Draft review | No | No | Scope configuration | AI cannot send, publish, charge, pay, or release access |
Visibility Rules
Section 2 visibility-rules carry-throughRead operating area, per-role scope, safety boundary, and next action first so visibility review stays account-scoped and fail-closed.Visibility rules remain synthetic-only and review-only.
| Area | Manager | Owner | Field | Admin | Safety Boundary | Next Action |
|---|---|---|---|---|---|---|
| Property and work review | Assigned account review | Published owner-visible context only | Assigned work and checklist only | Configuration boundary only | No dispatch, invite, or tenant-bypass action | Keep route review read-only |
| Money and ledger review | Operational read | Summary-only | Denied | Explicit finance permission only | No checkout, payout, charge, refund, or ledger export | Confirm finance scope before any future provider work |
| Owner publication and reports | Approval review | Published artifacts only | Denied | No by default | No publish, send, export, or external sharing | Require owner-visible flags and publication gate |
| Platform and integration governance | Denied | Denied | Denied | Placeholder-only review | No tokens, secrets, credentials, or external writes | Keep provider setup deferred |
Permission Test Cases
Section 3 permission-tests carry-throughUse the bounded test cases to confirm denial, visibility, and evidence expectations before anyone assumes a permission write surface exists.All scenarios remain review-only and synthetic-safe.
| Scenario | Expected | Evidence | Next Action |
|---|---|---|---|
| Field opens Money | Zero financial rows render | Role-filtered financial views deny 4 active POC money rows to Field and exclude denial tenants | Keep denial test before database migrations, Supabase writes, or real-data migration |
| Owner opens Long-Term delinquency | Owner-visible summary only, no resident ledger rows | Owner summary-only publication gate over 1 active POC report rows | Require approved report/statement source and owner-visible flags |
| Admin opens billing | Entitlements visible, Stripe/payment setup remains deferred | Admin configuration view does not grant operational finance rows without explicit finance permission | Owner decides future payment provider later; no provider setup in Gate A |
| AI validator reads project context | Repo/synthetic fixture review only | Integration and role guardrails stay account-scoped to the synthetic POC tenant | Activate through GitHub review only when owner is ready |
| Denial tenant report requested | No rows render from denial tenant accounts | Permissions route evidence carries denialTenantCount 0 and active POC account only | Keep cross-account denial before any real-data import |
| Future owner real-data migration requested | Blocked until separate second tenant is approved | Account Settings tenant gate requires migration, security, and tenant-isolation approval | Do not mix owner real data into the synthetic POC tenant |
Audit Queue
Section 4 audit carry-throughRead event, status, evidence, tenant safety, and next action first so denied-access review stays auditable without exposing hidden rows.Audit review remains synthetic-only and no-live.
| Event | Status | Evidence | Tenant Safety | Next Action |
|---|---|---|---|---|
| Field finance denial review | Passes fail-closed review | Field cannot see 4 finance evidence rows | POC account only; denial tenants excluded | Keep denial case in synthetic regression coverage |
| Owner summary visibility check | Publication-gated | 1 owner-summary candidates remain bounded | Owner never receives resident ledger detail | Require published and owner-visible state before release |
| Admin finance scope review | Explicit permission required | 4 scoped role rows remain account-bound | No global tenant bypass or hidden ledger backdoor | Preserve explicit-finance-permission requirement |
Permission Guardrails
Permission checks must run after account membership and before rows renderClient-provided account ids are hints onlyRoles are scoped to the active synthetic POC account and never grant global tenant bypassDenial tenant records are excluded from permission-route evidenceFinancial access requires role plus explicit permission where applicableAdmin financial rows require explicit finance permission and never bypass tenant isolationOwner visibility depends on publication state and owner-visible flagsField, cleaner, vendor, and inspector roles cannot see financial report rows, owner statements, source rows, private messages, resident ledgers, platform payouts, or private contact dataNo auth setup, Supabase writes, database migrations, seed execution, invitations, provider setup, or real-data migrationFuture owner real data must use a separate second tenant after migration, security, and tenant-isolation approvalEvery denied case should be auditable without exposing hidden row contents
Route Closure
Source-static route closurePermissions now carries supervisory continuity, bounded access readability, denial-test continuity, and tenant-safe role visibility through this receiving surface.All permission behavior remains synthetic-only, no-live, and review-only.
Boundary rules summaryRead-only permission review only; no grant, revoke, invite, role mutation, tenant activation, or provider execution.The receiving surface stays source-static, review-only, and ready for later no-live validation routing only.