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 external account connection, live access to a connected user's Google Drive metadata, 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.

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, and may connect a profile-owned Google account.
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.
Profile-owned Google connection	IMPLEMENTED	A separate OAuth flow stores and refreshes credentials for the authenticated profile.
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, document handling, and action-specific lifecycle authorization are not implemented.
Workspace source integration	INACTIVE	Persistence exists, but the current Google path does not use it.
Document and normalized-content processing	INACTIVE	Persistence surfaces exist but are closed and have no active application workflow.
Drive metadata synchronization into local documents	SUPERSEDED	Earlier documentation describes it, but the current route reads live and performs no local document write.
Document listing or creation APIs	SUPERSEDED	They are described by older documents but absent from the current application.
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. Granular permission semantics and formal lifecycle authorization remain unimplemented.
• 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, binds the connection to a profile, persists it through its adapter, and decides which returned metadata reaches the user.
• 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 keeps provider credentials server-side, scopes integration records to a profile, and must control logging, support access, rotation, revocation, and deletion. Several lifecycle controls 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, profile binding, database adapter, access rules, client responses, and connection purpose.
• Contract or integration boundary: TUASESOR constructs a Google provider and an AuthService; its Supabase adapter implements find, save, update, and delete operations for a constructor-supplied profile.
• 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 or refresh failures prevent connection or Drive access. Storage failures prevent credential lifecycle operations. TUASESOR translates package errors into retry, reconnect, or support outcomes. The package exposes disconnect orchestration, but its current Google revoke operation is not implemented, so it is not a complete revocation path.
• 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 map provider file/folder responses to the connector contract.
• Responsibility owned by the platform: Cortexa owns connector construction, Google Drive API calls, listing options, provider-specific mapping, and compatibility of its exported connector surface.
• Responsibility retained by TUASESOR: TUASESOR obtains the correct profile-owned session, chooses root/parent and recursion options, decides whether shared resources are requested, maps results to the product response, and enforces product authorization.
• Contract or integration boundary: TUASESOR supplies an access token and listing options; the connector returns provider-neutral file records. The current My Space route performs a live, non-recursive list.
• Data access or processing: The package processes the provider token in memory, sends Drive listing queries to Google, and receives file/folder metadata. It does not persist TUASESOR data.
• Failure and dependency impact: Connector or Google API failure makes live Drive browsing unavailable. There is no local resource copy or alternate connector path.
• Evidence of current usage: Direct dependency, connector factory import, and active listFiles call in the Drive route.

@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 current storage adapter demonstrates the intended division: Cortexa defines the account-storage interface; TUASESOR binds it to profile-owned records and current database controls. The current connector demonstrates the same pattern: Cortexa hides Google SDK details; 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, profile-owned integrations, workspace authorization inputs, and expense-report persistence.
• Data sent, accessed, generated, or received: Authentication identifiers and selected Google identity metadata; session cookies; TUASESOR profile, workspace, membership, integration, expense, and foundational records; database queries and errors. OAuth tokens are stored in the TUASESOR schema.
• 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 server clients use the public project URL and anonymous key with the user's session. Current product source does not construct a service-role client. Database access depends on Auth identity, grants, and RLS.
• 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 a separate consent flow, allow a profile to browse its authorized Drive resources.
• TUASESOR capability enabled: Application sign-in, profile identity synchronization, profile-owned provider connection, token refresh, and live My Space file/folder browsing.
• Data sent, accessed, generated, or received: For application login, Google identity data flows through Supabase according to provider configuration not fully represented here. For Drive authorization, TUASESOR requests openid, email, profile, and read-only Drive access; sends an authorization code for exchange; receives a provider account identifier, access token, possible refresh token, scopes, and expiry; and sends listing queries and parent/root identifiers to Drive. The connector receives file/folder identifiers, names, MIME type, parent relationships, sizes, and provider response metadata needed for the listing.
• 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's Google OAuth flow. Drive connection uses a distinct server-side OAuth client configured by TUASESOR, requests offline consent and read-only Drive scope, and persists credentials in the profile-owned integration record.
• TUASESOR responsibilities: Explain and limit purpose, keep the two flows separate, request least privilege, bind the connection to the authenticated profile, 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 browsing. Expired or revoked Drive authorization produces retry or reconnect behavior. Because no local file copy exists, loss of provider access also removes product access to the source. No alternate provider is implemented, and the current Cortexa Google revoke operation is not implemented.
• Retention and deletion implications: Drive resource metadata is read live and held transiently in the response/browser, while tokens and provider-account connection data persist locally. Source deletion should disappear on a later provider listing, but revocation does not automatically delete the integration row. The storage adapter can delete it and profile deletion cascades it; no current end-user disconnect route coordinates provider revocation and local deletion.
• 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 the profile-owned connection.

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 implemented Drive path validates the Supabase user, selects an integration by that user's profile identifier, uses a profile-scoped storage adapter, and relies on integration-owner RLS. Possession of a provider account ID or token does not grant access to TUASESOR records. Similarly, a TUASESOR session alone does not grant Drive access without the separate connection.

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, and credential-bearing sessions must remain server-side. Current source does not use a service-role credential in the product flow; if introduced, it must not silently bypass ordinary product authorization.

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, and role-aware 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 roles are enforced for the implemented expense-report workflow, while workspace administration and granular permission evaluation remain unimplemented. Retention and removal effects require product and contractual decisions.

| OAuth credentials and provider connection metadata | Connected user and Google account; Drive access | Google is authoritative for grant and credential validity; TUASESOR integration record is the product system of record for the connection; Supabase has custody. Cortexa auth processes credentials in the TUASESOR runtime. | Explicitly profile-owned. TUASESOR owns RLS, adapter scoping, lifecycle, logs, support access, and deletion. No complete disconnect, encryption-at-application-layer, rotation, or access-audit process is evidenced. | | 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 response; no active local document 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, and classifications | Workspace members, employees, contractors, suppliers, clients, or beneficiaries; expense operation | TUASESOR is the business-system record; Supabase stores and enforces the implemented access and integrity model. The application supports listing, detail, draft creation, catalog reads, item totals, and secure item mutations while the parent remains draft. | Workspace-owned. Membership-scoped reads, coarse writer roles, draft restrictions, parent immutability, and same-workspace catalog validation are implemented. Formal lifecycle authorization, comprehensive auditability, retention, correction, export, blocking, deletion, and legal-role allocation remain incomplete. | | Documents and normalized/derived information | Potential document subjects; no current active purpose | Tables exist but are closed and unused. Ownership fields are nullable and lifecycle is unresolved. | INACTIVE. Extracted text, classifications, summaries, and metadata would remain potentially personal or confidential. Opening or populating these surfaces requires a new ownership, authorization, retention, source-removal, and incident decision. | | Transactions and workspace-source data | Potential financial actors and connected organizations; no current active workflow | Persisted foundations exist without an active application path. | INACTIVE but security-relevant because current exported grants are broad. Their presence does not establish an approved business purpose or safe tenant boundary. | | Logs and audit evidence | Users, operators, and affected records; operations and security evidence | TUASESOR emits limited server logs; Supabase, Google, and hosting logs may exist but are not configured or verified here. The audit schema is empty. | TUASESOR must define evidence purpose, access, retention, redaction, and incident use. Current logs are not a comprehensive audit trail; expense errors may include sensitive underlying causes in server logs. |

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 is live access:

• TUASESOR stores the profile-owned provider connection and credentials.
• The My Space route requests a current, non-recursive provider listing, optionally scoped to a configured root or selected parent.
• The connector maps provider metadata to an in-memory contract.
• TUASESOR returns a transient product projection to the browser.
• The route does not write documents, workspace_sources, normalized_documents, or another local resource index.
• Google remains authoritative for the resource, permissions, sharing state, metadata, and deletion.

TUASESOR is therefore not a secondary system of record for current Drive files or metadata. Labels such as sync_status in the response and synchronization fields in inactive tables do not change that reality.

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 are native TUASESOR records, not external-resource copies.

Any future persistence of external files, 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 inactive document tables do not supply these decisions by themselves.

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 operations; TUASESOR owns the Supabase implementation.	Profile ownership is supplied by constructor context and must remain present on every read/write. Credentials cross only server-side.	Storage failures stop connection or refresh. Adapter deletion exists; end-user disconnect does not.
Google Drive connector contract	Cortexa owns the connector; TUASESOR consumes it; Google owns the API.	Access token and listing scope go in; provider-neutral metadata comes out. Contract and Google API compatibility both matter.	Provider/connector failure stops live browsing; no cached copy or 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.	Identity scopes, Drive read-only scope, codes, credentials, provider account ID, and resource metadata cross the boundary.	Revocation requires reconnect; 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.

The local file: Cortexa dependencies also create a build and release contract with sibling repositories. TUASESOR depends on compatible package output being present during installation/build. 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:

• Profile-owned resources: Google integration credentials and connection lifecycle.
• 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.

The implemented Google connection is profile-scoped. Switching the displayed workspace does not change which Google integration is selected, and the current My Space path does not bind Drive resources to a workspace. A future workspace-owned source model must be designed explicitly rather than inferred from the inactive workspace_sources table.

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 records are not evaluated;
• 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:

• one profile must never receive another profile's connection or credentials;
• 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 public-key clients, schema selection, grants, RLS, profile-owner and membership policies on selected surfaces.	Membership administration, profile visibility, dormant-table grants, FORCE RLS, privileged access, backups, region, encryption, logging, and support controls are incomplete or unverified.
TUASESOR to Cortexa packages	In-process APIs, profile-scoped adapter, provider-neutral connector, narrow construction points.	Local 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, reconnect/retry handling.	Request-state/callback correlation is not evidenced for the separate Drive OAuth flow. There is no complete disconnect flow, token rotation/access audit, provider-region evidence, transfer analysis, or alternate provider.
Profile to workspace	Distinct identifiers and membership-based RLS on expense reports/catalog reads.	Client workspace state is not authoritative; membership data itself is not securely administered; role/permission semantics are absent.
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;
• the Drive connection uses read-only scope;
• current credentials are stored in profile-owned integration rows with owner RLS and no anonymous grant;
• 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; binds profile	Cortexa auth PROVIDES OAuth/session behavior	Google AUTHORIZES and issues/revokes credentials	User grants consent; organizational authority REQUIRES VALIDATION	Separate from application login.
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 handling, storage rules, and access design	PROCESSES tokens in server runtime	Google issues/revokes; Supabase stores	Users protect their accounts; organization governs authorized connections	App-layer encryption, rotation, access audit, and disconnect are incomplete.
Workspace isolation	OWNS; REMAINS ACCOUNTABLE	MUST preserve supplied context and must not bypass TUASESOR authorization	Supabase PROVIDES RLS execution	AUTHORIZES memberships	Authorized workspace discovery, self-readable memberships, membership-scoped reads, and coarse writer roles are implemented for Rendiciones. Workspace administration, granular permissions, 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, bind profiles, implement storage, handle 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 data| DB
    DB -->|grants and RLS under user context| T

    U -->|separate Drive consent| T
    T -->|OAuth orchestration| CA[Cortexa auth package]
    CA -->|code exchange and refresh| GO[Google OAuth]
    GO -->|profile-owned credentials| CA
    CA -->|store through TUASESOR adapter| DB

    T -->|profile-owned access token<br/>and listing purpose| CD[Cortexa Google Drive connector]
    CD -.->|connector types| CC[Cortexa contracts]
    CD -->|live listing| GD[Google Drive]
    GD -->|authoritative file/folder metadata| CD
    CD -->|transient provider-neutral metadata| T
    T -->|authorized product response| U

The diagram shows only implemented technical relationships. Cortexa packages run within the TUASESOR application runtime; this does not imply a separate Cortexa-hosted data processor. Planetta is omitted because its ownership of Cortexa is organizational context rather than an implemented TUASESOR runtime relationship. Future Cortexa modules are omitted because they are not current TUASESOR dependencies.

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 Drive browsing create two separate Google dependencies. Login-provider failure affects new or renewed sign-in; Drive failure affects My Space only. Revoked or expired Drive access can require reconnect. Source access is live, so the product has no offline resource copy to use during an outage or after exit.

Removing Google Drive support requires revoking or deleting stored connections, addressing residual tokens and provider metadata, changing the user experience, and deciding whether another connector preserves equivalent consent, metadata, sharing, error, and source-authority semantics. A current end-user disconnect workflow is absent, and the shared Google provider's revoke operation is not implemented.

Cortexa Packages

Local file: dependencies couple TUASESOR builds to sibling package availability and compatible compiled output. Auth error semantics, adapter interfaces, connector results, and contract types are operational compatibility points. A package defect or incompatible change can break authentication or Drive browsing even when Google and Supabase are healthy.

The narrow factories and adapter boundary make replacement practical in principle, but no tested alternate implementation is present. Replacement must preserve profile scoping, credential handling, read-only purpose, error behavior, 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.
• Drive metadata is read live and is not synchronized into local document tables.
• Expense-report listing, detail, initial draft creation, catalog reads, item totals, and secure item creation, update, and deletion are active while the parent report remains draft. Submission, review, approval, rejection, reimbursement, cancellation, document handling, and later lifecycle operations remain incomplete.
• Google integrations are profile-owned; expense reports are workspace-owned; My Space is not workspace-scoped.

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. Workspace and membership administration, granular permission evaluation, 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.
• Document and derived-data ownership, authorization, source-removal, and lifecycle are unresolved; those surfaces remain closed.
• Drive OAuth request-state/callback correlation, token application-layer encryption, rotation, access auditing, a complete provider-revocation/disconnect flow, and automatic deletion after revocation are not evidenced.
• 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, document ingestion, OCR, extraction, normalization, embeddings, semantic retrieval, and derived summaries are not current integrations.
• 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.