Implement a universal integration foundation for this new application. GOAL Build the app so its features depend on stable internal identities and versioned feature contracts. Each connected system implements those contracts through its own adapter or workflow. A feature describes the required outcome; its implementation may use one API call, several calls, or other features. The foundation must work before any external system is connected. Keep it framework and vendor agnostic, with domain-specific modules where needed. Healthcare examples below are illustrative; do not add patient or appointment models to unrelated apps. 1. Inspect and fit the application Read repository instructions, applicable Mock2/PRO standards, existing architecture, authentication, permissions, persistence, testing, and release process. Reuse those systems and approved dependencies. Verify current official documentation for any vendor integration you actually implement. Do the implementation and appropriate verification; do not stop at a proposal. Start with modules in the existing application. Do not introduce microservices, a visual workflow designer, a new identity provider, or a separate workflow engine merely to create this foundation. 2. Separate internal identity from external records and login accounts Give relevant entities stable internal identifiers. Keep a person, a patient/customer record, a contact/representative, an employee/provider record, and a login account distinct. Use explicit relationships where appropriate. Map external records to internal entities using a key that includes tenant, connection, source namespace/organization, resource type, and external ID. Treat external IDs as scoped strings, never globally unique identifiers. One person may have records in multiple practices or systems. A contact is not necessarily the subject of the record. Record link provenance, verification state, and timestamps. Linking, merging, or unlinking identity records must be authorized, audited, and recoverable. Similar names, dates of birth, or email addresses may suggest candidates; they must not automatically establish identity. Do not make identity linkage grant access or cross tenant boundaries. 3. Define a registry of connections Each connection represents a specific authorized instance, practice, account, or organization, not just a vendor name. Include tenant/organization ownership, provider type, external namespaces, environment, credential references, configuration, lifecycle state, and health. Keep secrets in existing secure storage. Support multiple connections to the same vendor and different capabilities per connection. Disconnection must preserve identity mappings and history while preventing execution through that connection. 4. Create versioned feature contracts Define contracts for the app's actual integration-related outcomes. Examples are appointments.list, person.summary.get, or contacts.list. Separate the reusable core from domain schemas; avoid a single universal object with every vendor's fields. Each contract must specify: - Meaning of success and the required result fields. - Inputs, entity references, tenant/connection scope, and authorization requirements. - Preconditions, side effects, validation, and applicable time-zone/status semantics. - Pagination, date/filter boundaries, ordering guarantees, freshness, and completeness. - Errors, permitted partial results, and behavior when required data is unavailable. - Version and compatibility rules; breaking semantic changes require explicit version handling. Preserve source identifiers and provenance. Optional fields may be absent with a documented reason. Do not invent missing values or silently substitute a weaker outcome. 5. Implement adapters, workflows, and feature composition Keep vendor URLs, payloads, credentials, and call sequences inside integration modules. Each implementation maps source behavior into the declared contract. One system might need two requests for a person summary and another only one. That difference belongs in their implementations. Features may compose other features when those outcomes are independently meaningful; private API helpers need not become public features. An appointments list can return identifiers, times, statuses, and source context. A roster requiring names can compose appointments.list with person.summary.get. Do not fetch full demographics for every appointment query by default. Preserve the authorized connection scope across dependent calls. Prevent dependency cycles, bound calls/time, and batch or cache appropriately without leaking data across tenants. Use ordinary application services for simple workflows; durable orchestration is justified only by long-running, asynchronous, or recoverable work. 6. Track capabilities honestly Maintain capability records per connection and feature contract version. Distinguish verified full support, partial support, unsupported, and unverified. Track configuration, current authorization, and connection health separately from semantic support. Record limitations, required permissions, evidence, verification date, and implementation version. Vendor discovery metadata is evidence, not proof that a workflow meets the contract. Partial support is usable only where the contract and caller explicitly allow that result. 7. Route and execute safely The app calls a feature with explicit tenant, actor, scope, and internal references. The runtime checks permission, resolves mappings, selects compatible implementations for the requested connections, executes, validates, and returns normalized results. Do not choose a source solely from a person ID. If multiple sources are possible, require an explicit connection or an authorized aggregation policy. For 'all appointments,' define authorized connections, date range, filters, pagination, and a completion policy. Report source-specific failures and overall completeness; a failed source must not look like an empty successful result. Deduplicate only using established identity/event evidence. Enforce access through the app and the applicable source permissions. Broad integration credentials must not broaden employee access. Add appropriate timeouts, rate-limit handling, safe retries, and write idempotency. Do not retry an uncertain write blindly. Multi-system writes need explicit recovery/compensation; do not imply a shared transaction. 8. Make the foundation usable without integrations Provide the identity-map interfaces, connection registry, contract definitions, adapter interface, capability registry, dispatcher, and documentation. Persist configuration and mappings where appropriate using the existing datastore. Keep local features working through existing application services; an app-owned implementation may satisfy relevant contracts. An empty connection registry is valid. External features return a clear not-configured result when no source exists. Keep mock data explicitly confined to development/tests. Do not require a vendor account or build speculative integrations. 9. Verify and deliver Use meaningful tests for namespaced identity collisions, tenant/permission isolation, per-connection routing, contract validation, composition, missing mappings, partial support, pagination, empty connections, and applicable write safety. Include conformance checks reusable by future adapters. Document the actual modules/data model, initial contract catalog, capability matrix, execution flow, and how to add an adapter or compose a feature. Trace executions with source, contract/implementation versions, correlation ID, timing, and sanitized outcomes. Reuse existing audit/Relay observability if present; keep credentials and sensitive payloads out of routine logs. Report implemented functionality, validation evidence, limitations, and remaining integrations. Distinguish verified implementations from scaffolding. The result should be a small working foundation that future connections extend without forcing a redesign of application features.