TUASESOR Ecosystem

This document is the authoritative ecosystem-level reference for the TUASESOR web repository. It describes current product, platform, provider, organizational, data, trust, contractual, and operational boundaries. It does not define repository layout, enumerate APIs or tables, or turn possible future integrations into current architecture.

When evidence conflicts, current application behavior and active database controls take precedence. Broader Cortexa strategy is relevant only where TUASESOR actually consumes a module or an approved decision establishes a future boundary.

Purpose

This document answers the following questions:

• Why does TUASESOR exist as an independent vertical product?
• Which customer outcomes, workflows, authorization decisions, and data responsibilities remain with TUASESOR?
• Which horizontal capabilities are supplied through Cortexa packages?
• Which capabilities and authoritative records belong to Supabase, Google, or another provider?
• What data and trust cross each boundary?
• What remains TUASESOR's responsibility when execution or custody is delegated?
• Which relationships are implemented, inactive, superseded, or only external possibilities?
• Which contracts permit the participants to evolve without blurring ownership?

It defines responsibility and relationship boundaries. Use ARCHITECTURE.md for internal architecture, DATABASE.md for persistence and database authorization, and REPOSITORY.md for code organization.

TUASESOR Product Role

TUASESOR is a vertical SaaS and business-system boundary for small and medium-sized organizations and the professionals who support them. The current server-backed product scope centers on authenticated profile admission, profile-owned My Space authorization and live Google Drive browsing, authorized workspace discovery, and a workspace expense-report domain with listing, detail, initial draft creation, catalog reads, item totals, and secure item create/update/delete operations while reports remain draft. The Rendiciones backend additionally supports explicit workspace-owned Google authorization, an expense_receipts workspace source, authenticated preflight, validated PDF/JPEG/PNG receipt upload through the Cortexa Google Drive connector, recoverable provider-result persistence, controlled document metadata finalization, and expense-item association. Formal later report lifecycle and broader document-processing capabilities remain incomplete.

TUASESOR exists independently because the complete customer outcome requires product-specific decisions that do not belong in a generic horizontal platform:

• the user experience and communication presented to customers and users;
• TUASESOR profile admission and lifecycle rules;
• the meaning of a workspace, membership, business role, and product permission;
• financial and operational workflow behavior, including expense-report rules;
• the purpose for connecting an external account and the data shown in My Space;
• which information is profile-owned, workspace-owned, provider-owned, or locally persisted;
• product-specific authorization, retention, deletion, support, and incident decisions.

Cortexa can provide reusable OAuth, connector, and contract capabilities without owning these vertical decisions. Supabase and Google can operate infrastructure or authoritative external services without deciding TUASESOR's product purpose. TUASESOR therefore remains accountable for the product experience and customer impact of the assembled system, even when a provider or shared package performs part of the work.

Planetta is the organizational owner of Cortexa. This ownership context does not create a runtime dependency, data flow, authorization relationship, or technical integration between TUASESOR and Planetta. The legal entity that contracts with TUASESOR customers, operates the service, or assumes specific contractual and regulatory responsibilities must still be confirmed through approved corporate and contractual sources.

Ecosystem Overview

The current ecosystem contains the following supported participants:

Participant	Current ecosystem role
Customer organizations	Supply the business context in which workspace records may be processed and authorize their people according to contractual and organizational rules. The repository does not establish their legal classification or a complete administration workflow.
End users and workspace members	Authenticate, receive TUASESOR profile status, may participate in workspaces, may connect a profile-owned Google account for My Space, and may act in authorized workspace workflows. Workspace-owned Google receipt authorization exists at the backend boundary; complete workspace connection/source administration UX remains pending.
TUASESOR	Owns the vertical product, customer-facing orchestration, product authorization decisions, application records, and the purposes for which providers and platform packages are used.
Cortexa	Supplies reusable in-process package capabilities and contracts. Only @cortexa/auth, @cortexa/connectors-google-drive, and the connector's @cortexa/contracts boundary are current TUASESOR relationships.
Supabase	Provides application authentication, sessions, managed PostgreSQL, PostgREST, and database roles. It has technical custody but does not own TUASESOR's business records or processing purposes.
Google	Provides the identity provider selected through Supabase for application login, a separate OAuth authority for the Drive connection, and the authoritative Google Drive resource service.
Next.js runtime operator	Executes the TUASESOR application. The repository identifies the runtime technology but not a production hosting provider, region, or operational contract.
Planetta	Organizational owner of Cortexa. No implemented runtime dependency, configuration, contract, authorization relationship, or data flow exists between TUASESOR and Planetta. Planetta's ownership of Cortexa provides governance context only and does not make Planetta part of TUASESOR's technical architecture.

No current connector, API call, or configuration supports SII, Google Calendar, non-Google document providers, government systems, or other external business systems. SII and calendar references in local or mock UI are INACTIVE. Provider names in schema comments are examples, not integrations. No PLANNED or EXPERIMENTAL ecosystem integration is evidenced by an approved repository decision.

Material capability status is:

Capability or relationship	Status	Current interpretation
Supabase-backed application authentication and session handling	IMPLEMENTED	Google is selected as the login provider; Supabase establishes the TUASESOR application session.
TUASESOR profile admission	IMPLEMENTED	Product entry requires an existing profile with email and active status on the page flow.
Google connection runtime with explicit owner context	IMPLEMENTED	The hardened runtime supports explicit profile or workspace ownership. Profile-owned integrations back My Space; workspace-owned integrations can authorize the Rendiciones receipt workflow with drive.file. Single-use OAuth transactions, exact owner/integration lookup, encrypted server-only credentials, multiple provider accounts, reconnect, refresh, and disconnect semantics are implemented at the backend boundary. Complete workspace connection/source administration UX remains pending.
Live Google Drive metadata browsing	IMPLEMENTED	My Space reads provider resources live through the Cortexa connector.
Authorized workspace discovery	IMPLEMENTED	WorkspaceProvider loads the authenticated profile's available workspaces through a TUASESOR API backed by self-readable memberships and membership-scoped workspace reads. The selected workspace remains browser-held request context, not authorization proof.
Workspace expense-report listing and detail	IMPLEMENTED	The API, services, repositories, UI, and database controls load workspace-filtered reports, individual report detail, expense items, totals, and applicable catalogs.
Expense-report draft creation	IMPLEMENTED	The UI and application API create an initial workspace-owned draft header through the service, repository, and invoker-rights database function.
Expense-item management	IMPLEMENTED	owner, admin, and member may create, update, or delete items only while the parent report remains draft. viewer and client remain read-only. Parent immutability and same-workspace catalog consistency are enforced in the database.
Formal expense-report lifecycle	INACTIVE	Submission, review, approval, rejection, reimbursement, cancellation, and action-specific lifecycle authorization are not implemented. The narrow draft receipt upload/association path is implemented and does not imply completion of the broader lifecycle.
Workspace receipt-source integration	IMPLEMENTED	The Rendiciones backend configures and resolves an explicit active expense_receipts source bound to an exact eligible workspace-owned Google integration. General source-administration UI remains pending.
Operational receipt document metadata	IMPLEMENTED	The narrow Rendiciones path persists recoverable upload state, provider-neutral receipt metadata, and expense-item association through controlled boundaries while the binary remains owned by Google Drive.
Normalized and derived-content processing	INACTIVE	normalized_documents remains closed and unused. OCR, parsing, extraction, normalization, embeddings, semantic retrieval, knowledge processing, and derived summaries are not implemented.
My Space Drive metadata synchronization into local documents	SUPERSEDED	My Space continues to read Google resources live and does not create a local Drive-resource index. The separate receipt workflow persists only the minimum operational source/recovery/document metadata required by Rendiciones.
Generic document listing or management APIs	SUPERSEDED	Older documentation describes generic document APIs that are absent from the current product. The implemented receipt-upload endpoint is a workflow-specific Rendiciones boundary, not a general document-management API.
Cortexa SDK, knowledge, capabilities, agents, and cloud consumption	EXTERNAL POSSIBILITY	The platform reference describes these modules, but TUASESOR has no current dependency, import, call, or approved integration.

Responsibility Model

Ecosystem responsibility is allocated by concern rather than by the location of code or data:

Responsibility category	Current allocation
Product responsibility	TUASESOR owns vertical product behavior, prioritization, product responses, and the complete customer outcome.
Customer-experience responsibility	TUASESOR owns login, admission, consent entry, My Space, workspace, error, reconnect, and support-facing behavior.
Business-workflow responsibility	TUASESOR owns expense-report and workspace workflow semantics. Cortexa and providers do not decide these rules.
Domain-rule responsibility	TUASESOR owns profile status, workspace membership meaning, expense classifications, statuses, and validation. Database and application controls implement portions of those rules.
Data-purpose and business-ownership responsibility	The applicable customer organization and TUASESOR must allocate purposes and instructions contractually. The repository cannot decide controller, responsible-party, or processor classifications.
Processing or service-provider responsibility	Supabase operates authentication and database infrastructure; Google operates identity/OAuth and Drive; Cortexa packages perform reusable logic inside the TUASESOR runtime.
Platform-capability responsibility	Cortexa owns the behavior and compatibility of the reusable auth, connector, and contract packages assigned to it.
Infrastructure responsibility	Supabase operates its service. TUASESOR configures and uses it safely. The production Next.js hosting operator and its responsibilities are not identified in the repository.
Provider-authoritative responsibility	Supabase is authoritative for Auth identity/session state. Google is authoritative for Google accounts, OAuth grants, Drive resources, permissions, and current provider metadata.
Operational responsibility	TUASESOR retains responsibility for dependency monitoring, configuration, access review, customer impact, provider coordination, recovery decisions, and customer communication. Implemented operational tooling is limited.
Contractual responsibility	The contracting organization must maintain suitable customer, provider, subprocessor, transfer, support, incident, retention, and exit terms. The repository does not evidence those contracts.
Legal or regulatory responsibility	Role allocation and obligations under Chilean privacy, labor, financial, contractual, or other law require validation by a Chilean lawyer or the designated legal/privacy responsible role.

Technical delegation does not automatically transfer accountability. In particular, using Supabase, Google, Cortexa, or a hosting service does not by itself satisfy TUASESOR's security, privacy, retention, deletion, evidence, incident, or contractual obligations.

TUASESOR-Owned Capabilities

TUASESOR owns the following durable capabilities and retained responsibilities:

• Product experience and outcome. TUASESOR owns its pages, workflows, product messages, failure handling, and what users may do with provider or business information.
• Application profile admission. Supabase authenticates; TUASESOR owns the profile record, its status, and the rule that normal page admission requires an active profile with an email.
• Workspace and domain behavior. TUASESOR owns workspace, membership, role, permission, expense-report, expense-item, workflow-state, and accounting-classification meaning. Membership-scoped discovery and coarse role enforcement are implemented for the current expense-report workflow. Migration 043 implements the granular permission database contract, evaluators, controlled mutation RPCs, delegation rules, and transactional permission audit events; broad product wiring, workspace administration, and formal expense-report lifecycle authorization remain incomplete.
• Product authorization. TUASESOR must translate identity, profile status, profile ownership, workspace membership, role, permission, and purpose into access decisions. It cannot delegate those decisions implicitly to provider possession or a client-selected identifier.
• External-account orchestration. TUASESOR decides when and why Google access is requested, configures scopes and callbacks, establishes the explicit product owner context, persists connection state through its adapter boundary, and decides which returned metadata reaches the user. Profile-owned authorization supports My Space; workspace-owned authorization supports the Rendiciones receipt workflow. Complete workspace connection/source administration UX remains pending.
• Data ownership and persistence decisions. TUASESOR owns the purpose, schema intent, ownership keys, grants, RLS design, retention expectations, and deletion behavior for application records in the tuasesor schema.
• Provider selection and configuration. TUASESOR selects Supabase, Google, and Cortexa packages for the current product and remains responsible for appropriate configuration, version compatibility, least privilege, and provider review.
• Credential protection in the product boundary. TUASESOR owns product authorization and credential-storage behavior. Migrations 044–046 separate durable integration ownership from credential metadata and store OAuth access/refresh material encrypted in Supabase Vault. The application runtime consumes that boundary through a server-only service-role client, an owner-scoped integration repository, and a dedicated credential secret store for both explicit profile and workspace owner contexts. Credential-access auditing, operational key management, rotation procedures, and complete workspace connection-management UX remain incomplete.
• Customer support and operational handling. TUASESOR owns user-facing reconnect, retry, support, and incident impact. Repository evidence supports error dispositions but not a complete support or incident-management system.
• Audit and evidence requirements. TUASESOR must decide what evidence is required for business, security, and legal purposes. The current database provides timestamps and limited logs, not a comprehensive audit trail.
• Customer communication and incident response. Providers may notify TUASESOR about their service; TUASESOR remains responsible for assessing product impact and communicating with affected customers according to approved procedures and contracts.

Ownership of a responsibility does not imply that its implementation is complete. The tenant-administration, retention, deletion, audit, token-governance, and incident procedures described later remain material gaps.

Shared Platform Capabilities

@cortexa/auth

• Status: IMPLEMENTED.
• Purpose: Provide reusable Google OAuth provider behavior, account/session orchestration, token expiry handling, refresh, and a provider-neutral storage interface.
• Responsibility owned by the platform: Cortexa owns the package API, provider implementation, error classifications, session refresh behavior, and storage-adapter contract.
• Responsibility retained by TUASESOR: TUASESOR owns the product routes, requested scopes, provider configuration, callback behavior, product-owner resolution, persistence adapters, access rules, client responses, and connection purpose.
• Contract or integration boundary: TUASESOR constructs the Google provider and AuthService with an explicit storage-flow context. Its storage adapter composes an owner-aware integration repository and a separate credential secret store, and supports runtime lookup, connect, reconnect, refresh/update, and disconnect without exposing infrastructure privilege to the browser.
• Data access or processing: The package receives the authorization code, Google client configuration, stored provider account information, access and refresh credentials, scopes, and expiry. It calls Google directly from the TUASESOR runtime. No separate Cortexa-hosted service or Cortexa data store is evidenced.
• Failure and dependency impact: Provider exchange, refresh, or revocation failures can prevent connection or Drive access. Storage failures prevent credential lifecycle operations. TUASESOR translates package errors into retry, reconnect, or support outcomes. Disconnect revokes provider access before local credential removal; nonterminal revocation failure prevents local deletion, while provider outcomes that already represent an absent or invalid grant are treated as successful revocation semantics.
• Evidence of current usage: Direct package dependency and imports in the Google provider, controller, service factory, storage adapter, and Drive route.

@cortexa/connectors-google-drive

• Status: IMPLEMENTED.
• Purpose: Isolate Google Drive SDK usage and expose provider-neutral operations for live file/folder listing and controlled file upload.
• Responsibility owned by the platform: Cortexa owns connector construction, Google Drive API calls, listing/upload behavior, provider-specific mapping, and compatibility of its exported connector surface.
• Responsibility retained by TUASESOR: TUASESOR resolves the authorized product owner and exact durable integration, obtains the corresponding server-side session, selects the approved product operation, resolves My Space parent/root context or the explicit workspace receipt source, validates product authorization and receipt constraints, and decides what provider result becomes product or persisted business metadata.
• Contract or integration boundary: TUASESOR supplies an authorized provider session plus operation-specific listing or upload input. The connector returns provider-neutral file metadata/results. My Space performs a live non-recursive list; Rendiciones performs controlled upload to the resolved external folder root.
• Data access or processing: The package processes the provider token in memory, sends listing queries or the validated receipt binary to Google as required by the selected operation, and receives provider file/folder metadata or upload results. It does not persist TUASESOR application data or credential material.
• Failure and dependency impact: Connector or Google API failure can make live My Space browsing unavailable or interrupt receipt upload. TUASESOR owns product-specific retry, reconnect, recovery, and business-finalization behavior; no alternate provider path is implemented.
• Evidence of current usage: Direct dependency and active TUASESOR usage for My Space listing and the Rendiciones receipt-upload workflow.

@cortexa/contracts

• Status: IMPLEMENTED as an indirect connector contract boundary; not directly imported by TUASESOR application source.
• Purpose: Define shared connector file and download shapes used by the Google Drive connector.
• Responsibility owned by the platform: Cortexa owns shared type/schema compatibility and the meaning of its cross-package contracts.
• Responsibility retained by TUASESOR: TUASESOR owns product-specific response shapes and must explicitly promote a contract only when cross-product reuse is real.
• Contract or integration boundary: The root package is declared locally, while the Google Drive connector imports ConnectorFile and DownloadedFile contracts. TUASESOR consumes the connector's typed return boundary indirectly.
• Data access or processing: Contract definitions do not independently receive, store, or transmit data.
• Failure and dependency impact: Incompatible contract changes can break connector builds or product mapping even without a direct TUASESOR import.
• Evidence of current usage: Root dependency declaration plus active imports from the connector package source. No broad direct use of document, extraction, event, or AI contracts is evidenced.

The repository does not consume @cortexa/sdk or a Cortexa knowledge, capability, agent, cloud, hosted processing, or remote data service. Their presence in references/CORTEXA_PLATFORM.md is platform context, not a TUASESOR current-state relationship.

Cortexa Boundary

The durable Cortexa boundary is:

• TUASESOR owns vertical workflows, product purpose, customer experience, authorization, and customer outcomes.
• Cortexa owns only the reusable behavior and contracts exposed by the packages TUASESOR consumes.
• TUASESOR decides when and why an OAuth or connector capability is used and which product context is valid.
• TUASESOR must enforce its profile, workspace, membership, role, permission, and purpose rules before and after calling a shared module.
• A Cortexa package must not bypass TUASESOR's database or product authorization boundaries.
• Tokens, metadata, provider identifiers, logs, errors, and derived information remain potentially sensitive even when handled through a shared module.
• Package execution inside the TUASESOR runtime does not make Cortexa the business owner of the processed information.
• Adapters and connector contracts provide a substitution boundary, but replacement is not automatic; compatibility, data handling, and failure semantics must be preserved.
• A future hosted Cortexa service would create a new recipient, processing location, credential, contract, and incident boundary and must be documented before use.

The storage-adapter boundary demonstrates the intended division: Cortexa defines the account-storage interface, while TUASESOR owns persistence, authorization, and infrastructure implementation. The current application adapter implements explicit owner context, owner-scoped integration lookup, durable integration lifecycle, and separated credential storage. The profile-scoped behavior of My Space is a product-flow decision rather than a persistence assumption. The connector follows the same ownership principle: Cortexa hides Google SDK details while TUASESOR owns product orchestration and disclosure.

External Providers And Systems

Supabase

• Status: IMPLEMENTED.
• Business purpose: Establish TUASESOR application identity and sessions, host PostgreSQL application data, expose PostgREST access, and apply database roles, grants, and RLS.
• TUASESOR capability enabled: Login, session refresh, profile admission, owner-aware integration persistence, workspace authorization inputs, encrypted OAuth credential custody, expense-report persistence, controlled workspace receipt-source configuration, receipt-upload preflight, recoverable upload state, operational receipt document metadata, and expense-item association.
• Data sent, accessed, generated, or received: Authentication identifiers and selected Google identity metadata; session cookies; TUASESOR profile, workspace, membership, integration, expense, workspace-source, receipt-upload recovery, operational document, and foundational records; database queries and errors. Durable non-secret integration and receipt metadata is stored in the TUASESOR schema, while OAuth access and refresh token material is encrypted at rest in Supabase Vault under the migration 046 server-only credential boundary. Receipt binaries are not stored by Supabase through the implemented workflow.
• Authoritative source: Supabase Auth is authoritative for the authenticated identity and session. TUASESOR is authoritative for profile status and business records in its application schema. Supabase custody does not make it the business owner.
• Credential or authorization model: Browser and ordinary user-context server clients use the public project URL and anonymous key with the user session. Database access depends on Auth identity, grants, RLS, and controlled functions. Migration 046 defines narrow credential RPCs executable only through the privileged server boundary. The application additionally uses narrowly scoped service-role operations for integration persistence and receipt-upload recovery/finalization only after TUASESOR has resolved the authorized owner, workspace, source, report, item, and integration required by the operation.
• TUASESOR responsibilities: Configure authentication, validate users and profiles, define migrations and schema purpose, protect ownership predicates, review grants/RLS, minimize access, manage credentials and secrets, define retention/deletion, monitor service impact, and maintain provider contracts.
• Provider responsibilities: Operate Auth, session, PostgreSQL, PostgREST, platform roles, service availability, and contracted infrastructure controls.
• Storage and processing location evidence: The repository does not identify the Supabase project region, backup locations, subprocessors, recovery arrangement, or production environment. These require provider-console and contractual evidence.
• International transfer considerations: The repository cannot determine whether personal or confidential information is transferred outside Chile. Project region, support access, backups, telemetry, and subprocessors require review.
• Failure, revocation, and exit impact: An outage can prevent login, session validation, and application data access. Exit requires preserving application schema semantics, RLS/grants, Auth-to-profile identity mapping, business data, credentials, and deletion obligations. No provider failover is implemented.
• Retention and deletion implications: Foreign-key actions provide technical cascades, but no complete retention schedule or user-facing export, correction, blocking, or deletion process exists. Provider backup retention and post-termination deletion require contractual confirmation.
• Contractual or legal review needs: Service terms, data-processing terms, security controls, incident notice, support access, subprocessors, region, international transfers, backup/deletion, and legal role allocation require organizational review and, where material, Chilean legal validation.

Google Identity, OAuth, And Drive

• Status: IMPLEMENTED.
• Business purpose: Provide the selected login identity through Supabase and, through separate purpose-bound Google authorization, allow a profile to browse authorized Drive resources in My Space or allow an authorized workspace Rendiciones flow to upload expense receipts to its configured external folder.
• TUASESOR capability enabled: Application sign-in, profile identity synchronization, profile-owned My Space authorization, workspace-owned Rendiciones authorization backend, single-use OAuth transaction state, secure credential persistence, exact integration selection, multiple provider accounts, token refresh, reconnect, disconnect, live My Space browsing, and controlled receipt upload. Complete workspace connection/source administration UX remains pending.
• Data sent, accessed, generated, or received: For application login, Google identity data flows through Supabase according to provider configuration not fully represented here. Profile-owned My Space authorization requests openid, email, profile, and read-only Drive access. Workspace-owned Rendiciones authorization requests identity scopes plus drive.file. OAuth codes, provider account identifiers, access/refresh credentials, scopes, and expiry are handled server-side. My Space sends listing/root queries and receives file/folder metadata; receipt upload sends a validated PDF/JPEG/PNG binary to the resolved Google Drive folder and receives provider upload metadata.
• Authoritative source: Google is authoritative for the Google account, OAuth grant, credential validity, Drive files/folders, sharing, permissions, current metadata, and source removal. Google identity does not replace TUASESOR profile status or workspace authorization.
• Credential or authorization model: Application login uses Supabase Google OAuth. External Drive authorization uses a distinct server-side OAuth client configured by TUASESOR, offline consent, explicit owner context, and purpose-specific scopes: read-only Drive access for profile-owned My Space and drive.file for workspace-owned receipt upload. The runtime uses the migration 045 single-use OAuth transaction contract and migration 046 secure credential boundary through owner-aware server-only persistence adapters.
• TUASESOR responsibilities: Explain and limit purpose, keep the two flows separate, request least privilege, bind each connection to the resolved product owner, protect and refresh credentials, validate product access, minimize response data, handle revocation, provide disconnect/deletion behavior, assess incidents, and communicate with customers.
• Provider responsibilities: Authenticate the Google account, display and enforce consent, issue/revoke credentials, enforce Drive permissions, operate the APIs, retain authority over source resources, and perform contracted provider security and incident duties.
• Storage and processing location evidence: The repository does not identify Google processing regions, account residency, support access, logging, or subprocessor arrangements. Provider and customer-account documentation must be reviewed.
• International transfer considerations: OAuth and Drive operations may cross jurisdictions, but the repository provides no evidence sufficient to identify the transfer path. Contractual and provider-region review is required.
• Failure, revocation, and exit impact: Login-provider failure can block new application authentication. Drive outage prevents live My Space browsing and can interrupt receipt upload. Expired or revoked authorization produces retry or reconnect behavior according to the product flow. For receipts, acknowledged provider uploads are represented separately from completed TUASESOR association so business finalization can recover without blindly uploading a duplicate. Cortexa implements provider revocation; TUASESOR preserves durable integration lifecycle state while credential material is removed according to the disconnect contract. No alternate provider is implemented.
• Retention and deletion implications: My Space Drive metadata is read live and held transiently in the response/browser rather than copied into a local resource index. The Rendiciones receipt path deliberately persists only its configured source, recoverable upload state, provider-neutral document metadata, and expense-item association; the receipt binary remains Google-owned. Provider-account connection state is durable TUASESOR data, non-secret metadata remains separated from credentials, and OAuth token material is encrypted in the secret store. Complete retention, source-removal propagation, and workspace administration policies remain pending.
• Contractual or legal review needs: OAuth verification and branding, API terms, authorized scopes, data-use restrictions, security, incident notification, user/customer authority to connect resources, retention after revocation, support access, subprocessors, transfers, and Chilean legal role allocation require review.

Other Providers And External Business Systems

No other provider or business/government system has an IMPLEMENTED relationship. A Next.js production host is necessary to operate the application, but the repository does not identify one; no provider responsibility, region, data flow, or contract can be assigned without external evidence. SII, Google Calendar, Dropbox, OneDrive, automation, and other provider references are INACTIVE UI/schema examples or EXTERNAL POSSIBILITY, not approved active dependencies.

Authentication And Identity Responsibilities

Four identity and authorization layers must remain separate:

1. Application authentication. Supabase Auth validates the session and supplies the user identity. The selected login provider is Google.
2. TUASESOR profile resolution and admission. TUASESOR stores a one-to-one profile with product-specific status and metadata. Normal page entry requires a profile with an email and active status.
3. Workspace membership and product authorization. TUASESOR decides whether a profile may act in a workspace and, where required, which role or permission applies.
4. External-provider authorization. A separate Google OAuth grant permits Drive access for an explicitly resolved product owner and purpose. Profile-owned authorization backs My Space; workspace-owned authorization backs the Rendiciones receipt source. Provider account identity, integration identity, or possession of a token never substitutes for TUASESOR profile/workspace authorization.

The Google identity used for login, the Supabase Auth identity, the TUASESOR profile, a workspace membership, and the Google provider account are related identifiers but are not interchangeable authorities.

The current Drive application source validates the Supabase user, resolves the profile owner, lists active Google integrations for that owner, and requires an exact integration when more than one account is available rather than selecting an arbitrary connection. Credential retrieval occurs through the server-only hardened persistence boundary. Possession of a provider account ID, infrastructure credential, integration ID, or token never replaces TUASESOR product authorization.

Infrastructure credentials and provider credentials have a different boundary. Public Supabase configuration may be used by the browser, but Google client secrets, authorization codes, access tokens, refresh tokens, credential-bearing sessions, and privileged Supabase credentials remain server-side. The application has dedicated server-only privileged boundaries for narrow integration/credential operations and receipt-upload recovery/finalization after ordinary TUASESOR owner, workspace, source, report, item, and integration authorization has been resolved; infrastructure privilege is never treated as product authority.

Admission is not yet uniform: page middleware and the application callback check active profile status, while API routes validate the Auth user but do not repeat the profile-status gate. Database RLS also uses auth.uid() rather than profile status. Disabling a profile is therefore not proven to block every API and database operation for an existing valid session.

Data Ownership And Processing Boundaries

The following terms are distinct:

• Business ownership means authority to determine why business information is used, subject to contracts and law.
• Technical custody means operating infrastructure that stores or transmits information.
• System-of-record authority means which system is authoritative for a fact or resource.
• Processing responsibility means performing a defined operation on information.
• Access-control responsibility means deciding and enforcing who may perform that operation.

Provider custody or a Cortexa type does not transfer business ownership.

Data category	Subject and purpose	Authority and current processing	Ownership, access, retention, and legal implications
Auth identity and session data	TUASESOR users; authentication	Google supplies the selected identity to Supabase; Supabase Auth is the identity/session system of record; selected identity metadata is synchronized to TUASESOR.	TUASESOR owns admission rules. Supabase has technical custody. Profile correction may be resynchronized from Auth. Auth-user deletion cascades to the profile. Legal role and retention terms require validation.
TUASESOR profile data	Users; admission, display, product role/type	TUASESOR profile is the system of record for product status and application metadata; stored in Supabase.	Profile-owned application data. Current authenticated users can select all profiles because profile RLS is absent, creating an exposure risk. TUASESOR owns access, correction, and lifecycle decisions.
Workspace, membership, role, and permission data	Users and customer organizations; collaboration and authorization	TUASESOR schema is the system of record; Supabase stores the records and evaluates applicable grants, RLS policies, role-aware functions, and migration 043 granular permission functions.	Ordinary authenticated callers can read only their own memberships and discover only workspaces in which they participate. They cannot mutate memberships through the current ordinary database path. Coarse expense-report roles and the granular permission database contract are implemented; workspace administration, broad product consumption of granular permissions, and formal lifecycle authorization remain incomplete. Retention and removal effects require product and contractual decisions.

| OAuth credentials and provider connection metadata | Connected profiles/workspaces and Google accounts; Drive access | Google is authoritative for grant and credential validity; TUASESOR integration state is the product system of record for the durable connection; Supabase has infrastructure custody. Cortexa auth processes credentials in the TUASESOR runtime. | Durable integration ownership supports explicit profile or workspace scope. Profile-owned integrations back My Space; workspace-owned integrations can back the Rendiciones receipt source. Non-secret metadata is separated from OAuth access/refresh material stored encrypted in Supabase Vault. Credential-access auditing, operational key management, rotation procedures, and complete workspace administration UX remain incomplete. | | Live Google Drive resource metadata | File owners, users, counterparties, clients, beneficiaries, or other people represented in names and structure; My Space browsing | Google is authoritative. Cortexa connector reads live; TUASESOR maps a transient My Space response; no My Space local document/resource-index write occurs. | Provider-owned resource; TUASESOR controls product disclosure. Metadata can be personal or confidential. Google permissions limit provider access; TUASESOR must also enforce profile and purpose boundaries. | | Expense reports, items, classifications, and receipt associations | Workspace members, employees, contractors, suppliers, clients, beneficiaries, and receipt counterparties; expense operation | TUASESOR is the business-system record for reports/items and the operational association to externally stored receipts; Supabase stores and enforces the implemented access and integrity model. | Workspace-owned. Membership/write-role checks, draft restrictions, preflight validation, controlled receipt finalization, and same-workspace integrity are implemented. Formal later lifecycle authorization, comprehensive auditability, retention, correction, export, blocking, deletion, and legal-role allocation remain incomplete. | | Operational receipt document metadata | Receipt subjects and counterparties; Rendiciones evidence | TUASESOR persists the narrow provider-neutral metadata and recovery/business association needed by the receipt workflow; Google remains authoritative for the binary file. | Controlled workspace/source path. Ordinary direct document-table access remains closed. Metadata can be financially, commercially, or personally sensitive. | | Normalized and derived document information | Potential document subjects; no current active derived-processing purpose | normalized_documents exists but remains closed and unused. | INACTIVE. OCR output, extracted text, classifications, summaries, embeddings, and other derived information require separate ownership, authorization, retention, source-removal, and incident decisions before use. | | Workspace receipt-source data | Connected organizations/accounts; Rendiciones provider-root configuration | TUASESOR stores an explicit workspace-owned external root tied to an exact workspace-owned integration and purpose expense_receipts. | Active only through controlled backend boundaries; general source-administration UX remains pending. Provider/source identifiers remain potentially confidential. | | Transactions | Potential financial actors; historical/transitional model | Persisted foundation exists without an active application path. | INACTIVE but security-relevant because historical grants remain broader than current use justifies. | | Logs and audit evidence | Users, operators, and affected records; operations and security evidence | TUASESOR emits limited server logs, and audit.events records the implemented granular permission mutation and role-change delegation lifecycle events. Supabase, Google, and hosting logs may also exist but are not configured or verified here. | TUASESOR must define evidence purpose, access, retention, redaction, and incident use. Current permission audit coverage is deliberately narrow and is not a comprehensive cross-domain audit trail. |

The repository cannot conclusively identify the data controller, responsible party, processor, subprocessor, or owner under law. Customer agreements, provider contracts, actual operating entity, and processing purpose must be reviewed. Material conclusions require the appropriate responsible role and, where Chilean law is implicated, a Chilean lawyer.

Live External Resources Versus Local Persistence

The current Google Drive relationship has two distinct product paths:

• TUASESOR stores durable provider connection state and non-secret integration metadata under explicit profile or workspace ownership. My Space remains profile-scoped; Rendiciones receipt authorization is workspace-scoped.
• The My Space route requests a current, non-recursive provider listing, optionally scoped to a configured root or selected parent.
• For My Space, the connector maps provider metadata to an in-memory contract. For Rendiciones, it also performs controlled upload of the already validated receipt to the resolved external folder.
• TUASESOR returns a transient product projection to the browser.
• The My Space route does not write documents, workspace_sources, normalized_documents, or another local Drive-resource index. The separate receipt workflow persists only its explicit source, recovery state, operational document metadata, and expense-item association.
• Google remains authoritative for the resource, permissions, sharing state, metadata, and deletion.

TUASESOR is therefore not a secondary system of record for My Space Drive files or their live metadata. The Rendiciones workflow is a deliberate exception only for the minimum operational metadata required to recover and associate a receipt upload; Google remains authoritative for the receipt binary and provider-side file state.

Profile metadata is different: selected Supabase Auth identity data is copied into the TUASESOR profile, where TUASESOR status and application fields are locally authoritative. Expense reports, workspace receipt-source configuration, upload-recovery state, and receipt associations are likewise TUASESOR operational records even though the underlying receipt binary remains externally owned.

Beyond the narrow receipt workflow, any persistence of additional external files, broader provider metadata, extracted text, classifications, summaries, or other derived information requires an approved:

• product purpose and minimum data set;
• business owner and system-of-record rule;
• profile/workspace ownership key;
• authorization and tenant-isolation model;
• correction, deduplication, and source-removal behavior;
• retention, blocking, export, and deletion rule;
• audit and support-access requirement;
• incident-impact and provider-exit assessment.

Existing broader document and normalized-content schema surfaces do not supply these decisions by themselves, and the narrow receipt path must not be generalized into an unrestricted document platform.

Integration And Contract Boundaries

Contract or boundary	Owner and consumer	Compatibility and sensitive data	Failure or revocation behavior
Supabase application-auth contract	Supabase owns Auth/session behavior; TUASESOR consumes it and owns profile admission.	TUASESOR depends on server-validated user identity, session cookies, callback exchange, and synchronized identity metadata.	Auth failure blocks application entry. TUASESOR rejects missing/inactive profiles on normal page admission.
Auth-to-profile synchronization	TUASESOR owns the database trigger; Supabase Auth events are the source.	Same UUID links identity and profile; selected email/name/avatar/provider metadata crosses the boundary. TUASESOR fields remain local.	Missing or invalid profile data blocks page admission; the migration history for profile creation is not fully replayable.
Cortexa auth package API	Cortexa owns provider/session orchestration; TUASESOR consumes and configures it.	Authorization codes, tokens, scopes, expiry, and provider identifiers cross the in-process boundary. Package API changes require TUASESOR adapter compatibility.	Exchange/refresh errors become retry, reconnect, or support outcomes.
Cortexa storage-adapter contract	Cortexa defines account-storage operations; TUASESOR owns their persistence implementation and product authorization.	TUASESOR supplies explicit owner and flow context; durable integration identity and credentials are resolved separately and credentials cross only server-side.	Storage failures stop connection or refresh. Exact reconnect/disconnect targets are validated against owner/provider/account identity; provider revocation precedes local credential removal.
Google Drive connector contract	Cortexa owns the connector; TUASESOR consumes it; Google owns the API.	An authorized provider session plus operation-specific listing or upload input crosses the in-process boundary; provider-neutral metadata/results return. The validated receipt binary crosses to Google only for the approved upload operation.	Provider/connector failure stops live My Space browsing or receipt upload. TUASESOR owns retry, reconnect, and recovery semantics; no alternate provider exists.
Supabase/PostgREST database contract	TUASESOR owns schema, grants, RLS, queries, and RPC meaning; Supabase executes them.	Profiles, credentials, memberships, and business data cross the managed-service boundary.	Grant/RLS drift can expose data or break flows. Outage blocks persistence.
Expense-report application contract	TUASESOR owns authorized workspace discovery, listing, detail, initial draft creation, catalog reads, item totals, secure item mutations, services, repositories, and product responses.	Workspace IDs, report and item identifiers, dates, amounts, supplier and document metadata, notes, profile attribution, and accounting classifications cross application layers. The selected workspace is request context, never authorization proof.	Authentication, membership-scoped reads, coarse writer roles, draft enforcement, invoker-rights RPC authorization, grants, RLS, constraints, triggers, and uniqueness rules reject invalid or cross-workspace operations. Formal lifecycle operations remain incomplete.
Google OAuth and Drive API contract	Google owns authorization and resource APIs; TUASESOR/Cortexa consume them.	Purpose-specific scopes cross the boundary: read-only Drive access for profile-owned My Space and drive.file for workspace-owned receipt upload. Codes, credentials, provider account identity, metadata, and validated receipt bytes are handled only for the authorized operation.	Revocation requires reconnect; upload/provider failures require product-specific retry or recovery; provider changes may require package/product updates and renewed consent.
Product response contract	TUASESOR owns what reaches the browser.	Returned Drive metadata and expense information must be minimized and authorized. Raw credentials must never cross.	TUASESOR owns stable error codes, safe messages, and customer-facing behavior.

Versioned Cortexa package dependencies create an explicit build and release contract with their owning repositories and the configured private registry. TUASESOR depends on published compatible artifacts pinned through its package manifest and lockfile rather than on sibling source availability. Package owners may change their implementations, but breaking API, error, or data-contract changes require coordinated compatibility work.

Workspace, Profile, And Tenant Boundaries

TUASESOR currently has distinct ownership domains:

• Integration-owned resources: Durable external connection state may be explicitly profile-owned or workspace-owned. Credential metadata belongs one-to-one to the concrete integration; OAuth secret material is stored through the server-only secret-store boundary rather than being a separate user-owned domain entity.
• Workspace-owned resources: Expense reports, report items through their parent, and workspace accounting catalogs.
• Provider-owned resources: Google Drive files, folders, sharing, permissions, and current metadata.
• Application-owned resources: Profile status, product responses, domain rules, and persisted TUASESOR business records.
• Shared-platform processing: In-process Cortexa behavior using only the token, account, options, or metadata required by its contract.
• Infrastructure-level access: Supabase service roles, database ownership, provider consoles, support access, hosting credentials, and other privileged operations outside ordinary product permission.

My Space remains deliberately profile-scoped: switching the displayed workspace does not change which profile-owned Google integrations are eligible for My Space, and My Space does not bind its live Drive listing to a workspace. Separately, the Rendiciones receipt workflow deliberately uses workspace-owned Google authorization and an explicit expense_receipts source bound to the authorized workspace. Neither flow may infer provider ownership from browser workspace state, provider account identity, or credential possession.

The application discovers the authenticated profile's available workspaces through self-readable memberships and membership-scoped workspace reads. The selected workspace is stored in the browser as presentation and request context, but it cannot create authorization.

The implemented expense-report boundary combines:

• membership-scoped workspace, report, item, and catalog reads;
• repository filters using the intended workspace;
• coarse writer-role enforcement for owner, admin, and member;
• read-only access for viewer and client;
• item mutations restricted to parent reports in draft;
• supplied-workspace and parent-report consistency checks;
• immutable item parent relationships;
• same-workspace validation for workspace-owned classifications.

Complete tenant administration is still not established because:

• the application does not maintain a server-owned active-workspace session;
• no ordinary product workflow creates workspaces or administers memberships;
• granular permission evaluation and controlled mutation exist in the database contract, but current product workflows do not yet broadly consume or administer that capability;
• formal lifecycle actions lack operation-specific authorization;
• API paths do not uniformly enforce active-profile admission;
• some inactive or historical persistence surfaces retain broad grants or unresolved ownership.

The stable requirements are:

• a caller must never receive connection or credential material belonging to another profile or workspace owner; infrastructure privilege must not replace that owner authorization;
• one workspace must never receive another workspace's protected business data;
• provider and shared modules receive only the context required for the approved purpose;
• infrastructure privilege must never be exposed as an ordinary product role;
• provider account identifiers and client-selected workspace identifiers never replace TUASESOR ownership and authorization keys;
• cross-tenant or cross-profile processing requires an explicit product purpose, authorization design, and audit decision.

Security, Privacy, And Trust Boundaries

Trust boundary	Implemented controls	Retained gaps or required confirmation
Browser to TUASESOR	Supabase session cookies, server-side getUser(), page middleware, product API validation, sanitized Google-flow responses.	APIs bypass blanket middleware and do not uniformly check active profile status. Expense-report server logging can include underlying causes.
TUASESOR to Supabase	User-context clients, schema selection, grants, RLS, controlled RPCs, explicit integration ownership, and encrypted Vault-backed OAuth credential storage.	Membership administration, profile visibility, dormant-table grants, FORCE RLS, privileged-access operations, backups, region, credential-access auditing, operational key management, and support controls remain incomplete or unverified.
TUASESOR to Cortexa packages	In-process APIs, explicit storage-flow context, owner-aware TUASESOR persistence adapters, provider-neutral connector, and narrow construction points.	Package compatibility, release governance, dependency provenance, security response, and any future hosted processing require explicit controls.
TUASESOR/Cortexa to Google	Separate consent, server-side credentials, read-only Drive scope, provider permissions, migration 045 single-use OAuth transaction state, encrypted credential persistence, exact reconnect semantics, and provider-aware disconnect/revocation.	Credential-access auditing, operational rotation/key management, provider-region evidence, transfer analysis, workspace-owned Google administration, and an alternate provider remain incomplete.
Profile to workspace	Distinct identifiers, membership-based RLS on implemented workspace surfaces, coarse writer-role enforcement, and migration 043 granular permission evaluators/mutation controls.	Client workspace state is not authoritative; workspace and membership administration remain incomplete; granular permission product wiring is partial; formal lifecycle-specific authorization remains incomplete.
Provider resource to product response	Live read, no local document copy, product-side mapping, credentials omitted.	Metadata may still be personal/confidential. Purpose, disclosure, browser handling, support access, and logging must remain controlled.
Operations and support	Limited error categorization and timestamps.	No comprehensive audit history, access review, incident runbook, breach-notification configuration, evidence-retention rule, recovery objective, or verified provider failover.

The repository supports the following limited claims:

• application authentication and provider authorization are separate;
• external Drive authorization uses purpose-specific least-privilege scopes: read-only Drive access for profile-owned My Space and drive.file for workspace-owned receipt upload;
• OAuth access and refresh tokens are encrypted at rest in Supabase Vault behind narrow server-only credential RPCs; ordinary anonymous/authenticated credential access and direct integration_credentials table access are closed;
• current Drive resource metadata is read live rather than copied into document tables;
• current product source keeps provider credentials out of client responses;
• selected expense and catalog reads use membership policies;
• document and normalized-document user surfaces are closed.

It does not support claims of complete least privilege, tenant isolation, encryption governance, auditability, disaster recovery, provider-region control, international-transfer compliance, or legal compliance. Provider security features and certifications do not automatically satisfy TUASESOR's product-specific obligations.

Metadata, filenames, folder structure, provider identifiers, logs, extracted text, summaries, classifications, and derived information may identify people or disclose confidential activity. They require proportional controls even when they are not source-document contents.

Responsibility Matrix

Capability or concern	TUASESOR	Shared platform	External provider	Customer organization	Notes
Product workflow	OWNS; ORCHESTRATES	PROVIDES reusable components	PROVIDES external services	AUTHORIZES organizational use	TUASESOR REMAINS ACCOUNTABLE for the product outcome.
Application identity	CONFIGURES; validates profile admission	NOT APPLICABLE	Supabase PROVIDES identity/session; Google PROVIDES selected login identity	AUTHORIZES users under its own governance	Legal identity roles REQUIRE VALIDATION.
Product authorization	OWNS; AUTHORIZES through profile, workspace, membership, role, and workflow-state rules	MUST NOT bypass	Enforces only provider or infrastructure authorization	AUTHORIZES membership and business roles where contractually applicable	Membership-scoped access and coarse role enforcement are implemented for the current expense-report workflow; granular permissions and lifecycle-specific authorization remain incomplete.
External-provider authorization	ORCHESTRATES; CONFIGURES scopes; resolves product owner and exact integration	Cortexa auth PROVIDES OAuth/session/revocation behavior	Google AUTHORIZES and issues/revokes credentials	User grants consent; organizational authority REQUIRES VALIDATION	Current product flow is profile-owned; durable ownership also supports workspace scope.
Data purpose	OWNS product purpose; REMAINS ACCOUNTABLE	PROCESSES only by contract	PROCESSES for contracted service purposes	OWNS or AUTHORIZES business purpose as allocated by contract	Controller/responsible-party allocation REQUIRES VALIDATION.
Data ownership decisions	OWNS application schema and ownership model	NOT APPLICABLE	Owns authoritative provider resources, not TUASESOR business data	Business authority depends on customer contract	Technical custody is not business ownership.
Infrastructure operation	CONFIGURES; monitors impact	Packages execute in TUASESOR runtime	Supabase PROVIDES managed service; hosting provider unknown	NOT APPLICABLE	Hosting/operator allocation REQUIRES VALIDATION.
Provider processing	ORCHESTRATES; minimizes; reviews	Cortexa auth/connector PROCESSES in process	Supabase and Google PROCESS under service contracts	AUTHORIZES use where applicable	Region, transfer, and subprocessors REQUIRE VALIDATION.
Credential protection	OWNS product authorization, storage rules, lifecycle, and access design	PROCESSES tokens in server runtime	Google issues/revokes; Supabase Vault currently stores encrypted token material	Users protect their accounts; organization governs authorized connections	Encryption at rest, server-only credential access, owner-aware runtime adoption, reconnect, and profile disconnect are implemented. Rotation procedures, credential-access audit, operational key management, and workspace-owned administration remain incomplete.
Workspace isolation	OWNS; REMAINS ACCOUNTABLE	MUST preserve supplied context and must not bypass TUASESOR authorization	Supabase PROVIDES RLS and database-function execution	AUTHORIZES memberships	Authorized workspace discovery, self-readable memberships, membership-scoped reads, coarse writer roles, and the migration 043 granular permission contract are implemented. Workspace administration, broad granular-permission product wiring, formal lifecycle authorization, and uniform isolation across all persistence surfaces remain incomplete.
Retention and deletion	OWNS product rules and orchestration	Must honor contract	PROVIDES service deletion/retention under contract	Specifies business needs where applicable	Current schedule/workflows and provider deletion evidence are incomplete.
Audit evidence	OWNS requirements and product evidence	May provide package errors only	May PROVIDE platform logs under contract	May require business evidence	Comprehensive audit is not implemented.
Customer communication	OWNS	NOT APPLICABLE	PROVIDES upstream notices	Receives and coordinates with its users	TUASESOR REMAINS ACCOUNTABLE for product-impact communication.
Incident handling	OWNS product assessment and coordination	PROVIDES dependency remediation for package defects	PROVIDES service incident response under contract	Coordinates affected operations	Notification duties and legal thresholds REQUIRE VALIDATION.
Legal/regulatory classification	REQUIRES VALIDATION	REQUIRES VALIDATION if role changes	REQUIRES VALIDATION through contracts	REQUIRES VALIDATION	Repository evidence is insufficient for definitive classifications.

Dependency Summary

Dependency	Status	Purpose	Owner	TUASESOR responsibility	Data or trust boundary
Supabase Auth and SSR clients	IMPLEMENTED	Application identity, session, and server/browser client context	Supabase service; TUASESOR configuration	Configure login, validate identity/profile, protect cookies and callbacks	Identity and session data cross to a managed provider.
Supabase PostgreSQL/PostgREST	IMPLEMENTED	Application persistence and user-context data access	TUASESOR schema intent; Supabase runtime	Migrations, grants, RLS, ownership, lifecycle, monitoring, exit	Personal, credential, membership, and business data are in provider custody.
Google login through Supabase	IMPLEMENTED	Selected application sign-in method	Google identity plus Supabase orchestration	Explain use, configure provider, maintain profile admission	Google identity is not TUASESOR authorization.
@cortexa/auth	IMPLEMENTED	External Google OAuth and token lifecycle	Cortexa	Configure scopes/callbacks, resolve product owner, implement persistence adapters, handle reconnect/disconnect and failures	Codes and credentials are processed server-side in the app runtime.
@cortexa/connectors-google-drive	IMPLEMENTED	Google Drive listing and mapping	Cortexa	Supply authorized session, purpose/scope query, authorize disclosure	Token crosses in-process boundary; metadata crosses Google boundary.
@cortexa/contracts	IMPLEMENTED indirectly	Connector file/download contract	Cortexa	Preserve compatible product mapping; avoid claiming unused contracts	Contract compatibility, no independent data transfer.
Google OAuth and Drive APIs	IMPLEMENTED	Provider consent, credential issuance, live files/folders	Google	Least privilege, credential protection, authorization, reconnect, deletion, customer impact	External authoritative resources and possible international processing.
Production hosting/operations provider	EXTERNAL POSSIBILITY	Execute Next.js in production	Not identified	Select, contract, configure, secure, monitor, and document before relying on it	Region, logs, secrets, support, incident, and transfer boundaries are unknown.

Ecosystem Diagram

flowchart LR
    C[Customer organization] -->|business context and authorized users| U[End user]
    U -->|use product| T[TUASESOR]

    U -->|application sign-in with Google| SA[Supabase Auth]
    SA -->|validated identity and session| T
    SA -->|selected identity metadata| DB[(Supabase PostgreSQL<br/>tuasesor schema)]

    T -->|profiles, integrations,<br/>memberships, expense/receipt state| DB
    DB -->|grants, RLS, and controlled RPCs| T

    U -->|separate Drive consent| T
    T -->|OAuth orchestration| CA[Cortexa auth package]
    CA -->|code exchange and refresh| GO[Google OAuth]
    GO -->|provider credentials| CA
    CA -->|provider account/session data| T

    T -->|owner-aware credential persistence adapter| DB
    DB -->|migration 046 secret operations| V[(Supabase Vault)]

    T -->|authorized provider session<br/>and operation input| CD[Cortexa Google Drive connector]
    CD -.->|connector types| CC[Cortexa contracts]
    CD -->|live My Space listing| GD[Google Drive]
    CD -->|validated receipt upload| GD
    GD -->|authoritative metadata<br/>or upload result| CD
    CD -->|provider-neutral result| T
    T -->|authorized product response| U

The diagram shows the implemented credential-persistence boundary. TUASESOR resolves product authorization and explicit profile/workspace owner context before using its server-only integration repository and credential secret store; migration 046 persists encrypted OAuth material in Supabase Vault behind narrow RPCs. Cortexa packages execute inside the TUASESOR runtime and do not constitute a separate hosted processor. Planetta is omitted because its ownership of Cortexa is organizational context rather than an implemented TUASESOR runtime relationship. The workspace-owned Rendiciones authorization backend is current; complete workspace connection/source administration UX, alternate secret-store providers, and other future Cortexa modules remain outside the current diagram.

Operational Dependency And Exit Considerations

Supabase

Authentication and persistence share one provider dependency, so a Supabase outage can affect both application entry and business data access. No failover, recovery objective, or alternate identity/database path is evidenced. Exit planning must preserve:

• Auth identity to TUASESOR profile mapping;
• application data, schema, constraints, functions, grants, and RLS semantics;
• integration credentials and their secure migration or deletion;
• workspace ownership and membership relationships;
• retention, export, deletion, and backup obligations;
• customer communication and cutover behavior.

The migration sequence has replayability gaps, so a provider exit cannot assume clean reconstruction from migrations alone. See DATABASE.md for the persistence detail.

Google

Application login and external Drive use create separate Google dependencies. Login-provider failure affects new or renewed sign-in. Drive failure affects live My Space browsing and can interrupt Rendiciones receipt uploads. Revoked or expired Drive authorization can require reconnect. My Space has no offline resource copy; for receipts, TUASESOR retains only the operational metadata and recovery state required by the workflow while Google remains authoritative for the binary and provider-side file state.

Removing Google Drive support requires revoking or deleting stored grants and credentials, addressing durable integration and workspace-source metadata, resolving any receipt-upload recovery state and existing external receipt references, changing the user experience, and deciding whether another connector preserves equivalent consent, listing/upload, metadata, error, recovery, and source-authority semantics. The backend disconnect lifecycle is implemented for explicit integration ownership; complete workspace connection/source administration and end-user multi-account management UX remain pending.

Cortexa Packages

Versioned Cortexa dependencies decouple TUASESOR builds from sibling source and worktree availability. Auth error semantics, adapter interfaces, connector results, and contract types remain operational compatibility points. A missing, unpublished, defective, or incompatible package version can break authentication, live My Space browsing, or Rendiciones receipt upload even when Google and Supabase are healthy.

The narrow factories, owner-aware repository, secret-store port, and Cortexa adapter boundary make replacement practical in principle, but no tested alternate implementation is present. Replacement must preserve explicit profile/workspace owner authorization, credential isolation, exact account and integration identity, lifecycle semantics, purpose-specific least privilege, My Space live-list behavior, receipt-upload semantics, recoverable provider-result behavior, error handling, and provider-neutral mapping.

Hosting And Operations

The repository does not identify a production Next.js host, centralized observability service, backup executor, secret manager, support-access model, incident runbook, or recovery target. Those omissions do not remove the responsibilities; they leave the operational and contractual owner unverified. A production deployment must document these boundaries outside or inside the repository as appropriate before ecosystem claims are made.

Current Limitations And Unresolved Boundaries

Current implemented reality

• Google is the only implemented external identity/Drive provider.
• My Space Drive metadata is read live and is not synchronized into local document tables; the separate Rendiciones receipt workflow persists only its explicit source, recoverable upload state, provider-neutral document metadata, and expense-item association.
• Expense-report listing, detail, initial draft creation, catalog reads, item totals, secure item creation/update/deletion, and the narrow receipt upload/association workflow are active while the parent report remains draft. Submission, review, approval, rejection, reimbursement, cancellation, broader document management, and later lifecycle operations remain incomplete.
• My Space remains profile-scoped, while the Rendiciones receipt workflow uses explicit workspace-owned Google authorization and an expense_receipts source; the durable integration contract supports both profile and workspace ownership, and workspace selection never substitutes for explicit authorization;

Security and product decisions pending

• Workspace membership rows are self-readable and closed to ordinary mutation, and coarse roles are enforced for the implemented expense-report workflow. Migration 043 provides granular permission evaluation and controlled mutation at the database boundary; workspace/membership administration, broad product wiring of those permissions, and lifecycle-specific authorization remain incomplete.
• Workspace choices are loaded from authorized memberships, but the selected workspace remains browser-held request context rather than a server-owned authorized session.
• Active-profile admission is not uniformly enforced on API/database paths.
• Profiles and several inactive tables have overly broad access in the current database export.
• Broader document-platform and derived-data ownership, authorization, source-removal, retention, and lifecycle remain unresolved; the narrow Rendiciones receipt path is implemented with explicit workspace/source ownership, recoverable upload state, provider-neutral document metadata, and controlled expense-item association.
• Credential-access auditing, operational rotation/key management, complete workspace connection/source administration UX, and the user-facing multi-account management experience remain incomplete. Workspace-owned Google authorization for the Rendiciones receipt workflow is implemented at the backend boundary, while migration 045 transaction state, migration 046 secure credential persistence, exact reconnect semantics, and the current disconnect lifecycle are adopted by the runtime.
• A comprehensive audit trail, retention schedule, export, correction, blocking, deletion, incident, and evidence-retention workflow is not implemented.

Organizational and contractual review pending

• Planetta's organizational ownership of Cortexa is established as governance context. The legal and operational relationship among Planetta, TUASESOR, customer organizations, and any entity that contracts with customers or operates the service still requires approved corporate and contractual confirmation.
• Supabase, Google, and production-host processing regions, support access, subprocessors, backups, international transfers, deletion, incident terms, and exit support require contractual confirmation.
• Customer authority to connect external resources and legal role allocation require product, contract, privacy, security, and Chilean legal validation where material.

Non-current ecosystem claims

• SII, Google Calendar, non-Google connectors, automation, Cortexa SDK/knowledge/capabilities/agents/cloud, generic document ingestion and management, OCR, extraction, normalization, embeddings, semantic retrieval, and derived summaries are not current integrations. The narrow Rendiciones receipt-upload workflow is the implemented exception and must not be generalized into a document platform.
• No relationship is classified as PLANNED or EXPERIMENTAL without an approved repository decision.
• Older README and repository-guide statements about document APIs or Drive synchronization are superseded by current implementation and the current architecture/database documents.

These limitations are evidence, not a roadmap or promise of remediation.

Documentation Relationships

ARCHITECTURE.md

Use ARCHITECTURE.md for TUASESOR internal architectural responsibilities, system boundaries, integration contracts, security invariants, dependency direction, and design intent.

DATABASE.md

Use DATABASE.md for persistence architecture, detailed ownership, grants, RLS, tenant-isolation limits, credential storage, retention/deletion implications, and migration/export evidence.

REPOSITORY.md

Use REPOSITORY.md for repository organization, module placement, conventions, and code-location guidance. Its older implementation descriptions do not override current code.

references/CORTEXA_PLATFORM.md

Use references/CORTEXA_PLATFORM.md for broader Cortexa platform context and module ownership. Its production or strategic module labels do not make a module an active TUASESOR dependency.

README.md

Use README.md for introductory context, setup, commands, and documentation navigation. Its older current-status statements do not override implementation.

The generated project tree may help locate files but defines neither ownership nor ecosystem status. Publication copies under documentation/ are synchronized derivatives and are not canonical.

Guidance For Developers And AI Agents

Contributors and AI agents should:

1. verify active dependency usage, runtime calls, adapter behavior, configuration names, migrations, and current security controls before describing an ecosystem relationship;
2. read this document before moving capability or data responsibility between TUASESOR and a shared platform;
3. read ARCHITECTURE.md before changing internal responsibility boundaries;
4. read DATABASE.md before changing ownership, storage, grants, RLS, retention, deletion, or tenant isolation;
5. use REPOSITORY.md for placement and navigation, not for overriding current behavior;
6. preserve TUASESOR's vertical ownership of product workflows, customer experience, authorization, and customer outcomes;
7. avoid moving TUASESOR business rules into generic Cortexa modules without an explicit ownership and compatibility decision;
8. pass only the provider, profile, workspace, token, metadata, and business context necessary for the approved purpose;
9. preserve the distinction among Supabase identity, TUASESOR profile, workspace membership, provider account, and external resource;
10. ensure one profile cannot receive another profile's connection and one workspace cannot receive another workspace's protected data;
11. treat client-selected identifiers as request context, never authorization proof;
12. avoid persisting external or derived information without purpose, ownership, authorization, retention, deletion, correction, export, source-removal, audit, and incident decisions;
13. treat metadata, logs, extracted text, classifications, summaries, and derived information as potentially personal or confidential;
14. distinguish provider capability and technical custody from TUASESOR accountability and business ownership;
15. document a new provider, hosted platform service, subprocessor, region, credential model, and exit impact when it materially changes data or trust boundaries;
16. classify capabilities as IMPLEMENTED, PLANNED, EXPERIMENTAL, INACTIVE, SUPERSEDED, or EXTERNAL POSSIBILITY, and never present non-implemented relationships as current;
17. verify that a Cortexa package is actually imported or transitively required before assigning it an active TUASESOR role;
18. preserve stable adapters and contracts where practical, but reassess authorization and data handling when replacing a provider or package;
19. do not assume Supabase, Google, Cortexa, a host, or another service satisfies legal, privacy, security, contractual, retention, deletion, or evidence obligations;
20. request product, security, privacy, operational, contractual, or Chilean legal validation when responsibility allocation is material or uncertain.

Update this document when product/platform ownership, providers, shared packages, integration contracts, systems of record, data-processing relationships, trust boundaries, tenant ownership, retained operational responsibility, or material contractual dependencies change. Routine code, schema-field, UI, and package-version changes that preserve these boundaries do not require an ecosystem rewrite.