Settings Guardrails
Source-static proofIntegration Governance Console
No tokens / OAuth / webhooksProvidersAirbnbNo guest PII, messages, access codes, payouts, or channel writebacksAI/MCPClaude GitHub validatorOwner activates review; human approves any suggested code or design changeAuditReview channel connector scopeHold until platform data model and account readiness are approved
Integrations & AI governance
Scoped providers, AI validator posture, and audit-ready access in one admin console.
Integrations keeps provider scope, denied capabilities, developer surfaces, and AI/MCP access readable before any provider activation exists. Every card stays synthetic-only, review-only, and no-live.
Provider not configuredAirbnb
No guest PII, messages, access codes, payouts, or channel writebacks
Connected scopes6
AI / MCP actors4
Developer surfaces4
Audit events4
Provider not configuredAirbnb
6 synthetic occupancy rows, calendar context, payout matching candidate
No guest PII, messages, access codes, payouts, or channel writebacksProvider not configuredVrboCalendar hold context and payout matching candidate
No external availability updates or guest messagesProvider not configuredBooking.comUnmatched import and reconciliation placeholder
No live booking, payout, or payment dataAI Validator and MCP accessClaude GitHub validator
Allowed and denied scopes are visible together so AI review remains advisory. No live model call, provider auth, external send, payment action, or autonomous tool execution is available.
Claude GitHub validatorAllowed: Docs repo, platform repo, synthetic fixtures, review commentsDenied: Secrets, production data, live customer records, external account changesApproval: Owner activates review; human approves any suggested code or design changeDesign ferry via Claude DesignAllowed: Synthetic UI prompts, design directives, redacted wireframe feedbackDenied: Real tenant/guest/property/payment records and source-system private dataApproval: Codex validates usability, IA, data safety, and build impact before platform adoptionOperations AI assistantAllowed: Account-scoped synthetic records and approved knowledge snippetsDenied: Autonomous send, late fees, payment capture, lock-code release, vendor paymentApproval: Human approval required before anything external or financially materialMCP integration bridgeAllowed: Explicitly granted read-only tools inside the active account/workspaceDenied: Unscoped tenant access, production writes, secrets, and live payment actionsApproval: Scope review required before enabling any MCP server or tool
Provider not configured. No token exchange, OAuth flow, webhook delivery, MCP tool call, provider sync, external message, customer-data bridge, Supabase write, or production credential is present in this route.
Integration Guardrails
Provider not configuredSection 1 overview carry-throughStart with tenant-safe integration metrics so provider posture, AI governance, and audit readiness stay visible before table review.Integrations remain synthetic-only, review-only, source-static, and provider-not-configured.
Connected scopes6
AI / MCP actors4
Developer surfaces4
Audit events4
Account/workspace tenant boundary from day oneIntegration scope derives from active synthetic POC fixtures only; denial tenant integration rows render as zeroNo live tokensNo secretsNo production credentialsNo OAuth, API key creation, provider API calls, channel writeback, provider sync, or live AI model callsNo webhook deliveryNo webhook endpoints, signing secrets, external messages, MCP tool calls, autonomous actions, or repository/customer-data bridgeNo external writesNo real tenant, guest, owner, property, payment, or source-system recordsNo Supabase writes, database migrations, seed execution, storage writes, deployments, exports/downloads, payment/provider setup, or real-data migrationFuture owner real data must use a separate second tenant after migration, security, and tenant-isolation approvalEvery integration scope requires approval, audit, and revocation before activation
Connected App Scope Register
Section 2 connected-scope carry-throughUse provider, area, allowed scope, safety boundary, and next action as the first arrival scan so integration review stays tenant-safe and no-live.Connection review remains synthetic-only, review-only, source-static, and provider-not-configured.
| Provider | Area | Status | Allowed Scope | Mapped Records | Last Sync | Safety Boundary | Next Action |
|---|---|---|---|---|---|---|---|
| Airbnb | Short-Term channel context | Provider not configured | 6 synthetic occupancy rows, calendar context, payout matching candidate | Account -> workspace -> property -> listing -> reservation | Never connected | No guest PII, messages, access codes, payouts, or channel writebacks | Define read-only reservation and payout import scope |
| Vrbo | Short-Term channel context | Provider not configured | Calendar hold context and payout matching candidate | Account -> workspace -> property -> listing -> reservation | Never connected | No external availability updates or guest messages | Confirm synthetic field map before connector work |
| Booking.com | Short-Term channel context | Provider not configured | Unmatched import and reconciliation placeholder | Account -> workspace -> property -> listing -> reservation -> money event | Never connected | No live booking, payout, or payment data | Keep as sample reconciliation source |
| Turnover / cleaner system | Work and cleaner payments | Deferred | Task import, assignment context, evidence, payment approval placeholder | Account -> workspace -> property -> work item -> cleaner/vendor payable | Never connected | No phone, address, pay rate, or live assignment delivery | Use synthetic cleaner/vendor queue only |
| Smart lock provider | Access and devices | Deferred | Device inventory and access-code status placeholder | Account -> workspace -> property -> unit/listing -> device | Never connected | No real lock codes, no code generation, no code delivery | Design approval gate before any device connector |
| Direct booking payment provider | Money and direct bookings | Provider not configured | External collection status only | Account -> workspace -> property -> reservation -> money event | Never connected | Stripe and live payment processing are deferred | Represent Imported, Pending, Received, Paid externally, and Reconciled only |
AI / MCP Access Governance
Section 3 AI-governance carry-throughRead allowed scope, denied scope, approval rule, and audit trail first so AI and MCP review stays explicitly bounded.No live tool execution, auth flow, or provider authorization is available here.
| Actor | Purpose | Status | Allowed Scope | Denied Scope | Approval Rule | Audit Trail |
|---|---|---|---|---|---|---|
| Claude GitHub validator | Review plans, PRs, design prompts, and implementation deltas | Available later by owner activation | Docs repo, platform repo, synthetic fixtures, review comments | Secrets, production data, live customer records, external account changes | Owner activates review; human approves any suggested code or design change | Every review maps to repo, branch, issue/PR, and timestamp |
| Design ferry via Claude Design | Produce visual prototypes and return standalone HTML for review | Active workflow, manual ferry | Synthetic UI prompts, design directives, redacted wireframe feedback | Real tenant/guest/property/payment records and source-system private data | Codex validates usability, IA, data safety, and build impact before platform adoption | Prompt version, returned file version, assessment, and accepted changes |
| Operations AI assistant | Draft messages, summarize work, suggest next actions, and flag risk | Draft-only placeholder | Account-scoped synthetic records and approved knowledge snippets | Autonomous send, late fees, payment capture, lock-code release, vendor payment | Human approval required before anything external or financially material | Source records, draft, reviewer, approval/decline, final visibility |
| MCP integration bridge | Future scoped tool access for source-system and build validators | Disabled placeholder | Explicitly granted read-only tools inside the active account/workspace | Unscoped tenant access, production writes, secrets, and live payment actions | Scope review required before enabling any MCP server or tool | Tool, scope, caller, input class, redaction result, and outcome |
Developer Surface Placeholders
Section 4 developer-surface carry-throughUse capability, blocked actions, tenant boundary, and safe next action first so platform-surface review stays no-live and tenant-scoped.Developer surfaces remain placeholders only.
| Surface | State | Capability | Blocked Actions | Tenant Boundary | Safe Next Action |
|---|---|---|---|---|---|
| API Access | Disabled placeholder | Future tenant-scoped API keys with account/workspace/property limits | No key creation, no secret display, no production API calls | Keys must bind to account_id, workspace_id, role, scopes, and expiry | Document key metadata and revocation requirements |
| MCP / AI Agent Access | Review-only placeholder | Future Claude/GitHub validator, design validator, and scoped ops assistant | No broad repository write, no customer data, no external messages, no payment actions | Agent reads only approved synthetic fixtures and scoped repo files | Create approval checklist for validator activation |
| Email Routing | Disabled placeholder | Future inbound parsing and account-scoped communication routing | No mailbox connection, no outbound send, no resident/guest contact import | Messages must map to account, workspace, property, source record, and visibility | Model internal draft and approval states first |
| Webhooks | Disabled placeholder | Future event delivery for work, reservation, ledger, and payment status changes | No webhook endpoints, no signing secrets, no external delivery | Each event must include account_id and source record but no private payload by default | Define event types, redaction rules, retry policy, and audit log |
Integration Audit Queue
Section 5 audit carry-throughRead source, status, evidence, tenant safety, and next action first so integration review stays internally supervised and fail-closed.Audit review remains synthetic-only and no-live.
| Event | Source | Status | Evidence | Tenant Safety | Next Action |
|---|---|---|---|---|---|
| Review channel connector scope | Airbnb placeholder | Needs owner decision later | Short-Term calendar requires read-only reservation and payout import scope | No live credentials or writeback | Hold until platform data model and account readiness are approved |
| Prepare Claude validator rules | GitHub review workflow | Ready for checklist | Owner confirmed Claude can be activated for GitHub review once plan is ready | Repo-only review; no production data | Write validator checklist before first PR activation |
| Define webhook event classes | Developer surface placeholder | Deferred | Needed later for work, reservation, ledger, and payment workflow events | No webhook delivery; no signing secret | Document event names and redacted payload policy |
| Model email routing safety | Messaging and AI workflow | Deferred | Messaging AI is strategic, but external sending remains approval-gated | No mailbox connection and no outbound messages | Build internal draft queue before connecting any mailbox |
Route Closure
Source-static route closureAdmin Integrations now carries supervisory continuity, provider-not-configured posture, bounded table readability, and tenant-safe governance through the full receiving surface.Connection, AI governance, developer-surface, and audit review stay synthetic-only, review-only, source-static, and no-live.
Boundary rules summaryRead-only integrations review only; no provider connection, auth flow, token exchange, webhook activation, external sync, or provider execution.The receiving surface stays source-static, review-only, and ready for later no-live validation routing only.