Skip to Content
EngineeringRunbooksPartner onboarding

Partner onboarding

Two connectors and one e-mail sender depend on things a partner or a vendor provides. The plan tracks them as named blockers with defaults, not as gates: the build does not wait for them, the fakes carry CI and the local demo, and the real connection goes live the moment credentials are stored. This runbook lists the order, the profiles to ask for and the checks that prove each step.

Everything the fakes return is labelled “Illustrative” and never appears in the pilot demo, which runs on real data or not at all. The pilot is “non-GxP decision support with a light validation package”; the onboarding asks the partner for minimal, read-only profiles and records who consented.

Week-0 preconditions (named blockers)

BlockerDefault until suppliedCleared when
ELN sandbox tenant and app credentials (partner-provisioned; no public developer tenant exists)connector built and contract-tested against api/scripts/fake_benchling.pyclient_id and client_secret stored on the connection and the health check passes
QMS sandbox user and API tokenconnector built against api/scripts/fake_vault.pyhealth check validates the template query, lifecycle map and ALLVERSIONS on the partner’s tenant
Production e-mail sending for notifications@trovensa.comdomain identity, DKIM and MAIL FROM records created in the dns stack; sandbox mode with verified recipient addressesproduction access granted, or the partner’s addresses verified for the demo
auth_time optional claim on the trovensa-console registrationset with the identity provider’s CLI in phase 0; development uses dev_token.py --reautha re-authentication round trip succeeds against the deployed API

ELN connection (order matters)

  1. In the program: Setup › Connections › Add connection, provider benchling, scope_rules.project_ids set to the projects the program may read. Copy hook_url.
  2. Partner administrator: create the app from the manifest with the canvas feature, webhook URL = hook_url, project access = the same projects. Ask for an app profile with read-only access to those projects and nothing else; every read runs under it.
  3. Store client_id and client_secret on the connection (secret store; the database keeps references).
  4. Check health, then Sync now; confirm connector_objects rows and a webhook_deliveries row with signature_ok = true after the administrator opens an entry.
  5. Record consented_by, consented_at, api_version (v2) on the connection; the consent is audited.

Verified vendor facts this step relies on (contract 10.10, 2026-09-14): 15-minute client-credentials tokens, ECDSA-signed webhooks with a 5-minute tolerance, canvas events answered within 3 s, 300 requests per 30 s per app. The organisation budget row is 900 per 30 s; each connection draws 250 per 30 s from it.

QMS connection

  1. Ask the partner for a dedicated read-only integration user whose profile covers the effective SOPs of the mapped document types only, plus its API credentials, the SOP document type (and subtype and classification if used) and the lifecycle labels their tenant uses.
  2. Add connection, provider veeva_qualitydocs, API host, api_version v26.2 unless told otherwise, scope_rules.document_types, lifecycle map.
  3. Store the credentials; Check health: tenant id verified, every template field valid, ALLVERSIONS available, every label mapped. Gaps are listed; do not run the first sync until the list is empty (R1c exit gate).
  4. Sync now; confirm sops with source_kind = connector and sop_versions with major.minor, lifecycle_state and effective_at (watch for effective_on_observed = true where the tenant has no effective-date field).
  5. Pilot reads: the sandbox tenant in R1c; production QualityDocs at R2 after partner sign-off, recorded on the connection.
  6. Requirement extraction stays disabled for the pilot until a measured result on one partner SOP (precision and recall against a QA-labelled set) is registered in CLAIMS-REGISTER.md.

E-mail

The dns stack holds the domain identity, DKIM and MAIL FROM records; the configuration set feeds bounce and complaint notifications into suppression. Until production sending is granted, verify the partner’s recipient addresses in the sandbox. E-mails carry the record type, the human-set program name, the record id and a link only: no titles, no agent text. The sender is notifications@trovensa.com in us-east-1.

Demo path without partners

Journey J1 (evidence question with live literature) runs on real open sources with platform keys from day one and needs no partner. J2 (SOP check on a notebook entry) and J3 (new SOP version, requirement set) run on the fakes, labelled “Illustrative”, until credentials arrive; they never appear in the R2 pilot demo.

Checklist before declaring a partner onboarded

  • Both connections connected, health written, consented_by recorded.
  • webhook_deliveries shows verified deliveries; unsigned test payloads were rejected without payload.
  • Re-authentication round trip succeeded for a QA user (auth_time present).
  • Recipient addresses verified or production sending granted.
  • Integration-user profiles reviewed with the partner and recorded in the connection’s health.notes.

Source: api/app/integrations/base.py, api/app/integrations/secret_store.py, api/app/db/models/connection.py, api/app/db/models/connectors.py, api/app/config.py (ses_sender), infra/k8s/base/SECRETS.md, PRODUCT-CONTRACT.md sections 10.7 and 10.10, PRODUCT-PLAN.md Part 3 (blockers), Part 4 sections 6.1, 6.2, 8 and 9, decisions/0015-read-only-connectors-and-agent-service-identity.md, decisions/0018-program-scoped-connections-and-pinned-api-versions.md

Role splitTenant offboarding