Q3 E2E Cross-System Dependency Contracts

Purpose

This runbook defines what LTI needs from each external workstream before a cross-system scenario can be called acceptance-ready. It records confirmed surfaces separately from owner confirmations that remain open. Production writes and production credentials are outside these contracts.

Cristian Silva owns orchestration and evidence in LTI. Each linked Asana task is the approval route for the external system owner. A contract remains pending_owner_confirmation until that owner confirms the fields marked pending.

Common Execution Contract

Every scenario must:

1. declare lti-dev and the acceptance/sandbox systems it may mutate;
2. use a unique synthetic run identifier and immutable cleanup policy;
3. use synthetic identities from the restricted internal test audience;
4. preserve redacted request, response, database, provider, and reporting evidence under one LTI run;
5. use bounded polling with explicit timeouts for asynchronous systems;
6. fail closed when a requested target resolves to production;
7. leave exact run-owned cleanup evidence or a manual_review result.

SBN WebApp API and Workflow

• Approval task: Asana 1216410130917800
• Status: partially_confirmed
• Confirmed surfaces: staging.citizengo.org, staging.hazteoir.org, and the acceptance backend listed in q3-e2e-environments.md.
• Required journey: load a seeded acceptance petition, submit one synthetic signature, verify the success/share state, follow the no-share continuation, and confirm that a HazteOir journey remains on HazteOir-owned staging and sandbox donation domains.
• Required evidence: browser URL and status, backend correlation identifier, acceptance member/signature identifiers in redacted form, redirect target, and cleanup result.
• Owner confirmation needed: canonical health/read/signature route names, required request fields, stable correlation key, expected response states, and any workflow endpoint that is safe for deterministic reset.
• Pass gate: one CitizenGO and one HazteOir scenario complete without a production hostname, production database write, or personal identity.

ACP MODB Schema and Queries

• Approval task: Asana 1216410161185886
• Status: partially_confirmed
• Confirmed surface: development Cloud SQL operational_db through the acceptance backend or an approved read-only verifier.
• Required assertions: the run-owned member/signature event is present; event subscription/type references are valid; timestamps fall within the bounded run window; repeated validation does not mutate rows.
• Query safety: parameterized reads only from LTI. Any write must occur through the acceptance application and must use the synthetic run identifier. No truncate, reset, wildcard delete, or production fallback.
• Owner confirmation needed: authoritative table/view names, join keys, event-arrival SLO, duplicate semantics, and the approved read-only database identity.
• Pass gate: validation returns exactly the expected run-owned event set after bounded polling and produces no MODB mutation.

AAA Salesforce Removal and FRAPI Database Adaptation

• Approval task: Asana 1216410130843500
• Status: pending_owner_confirmation
• Confirmed surfaces: FRAPI acceptance and Salesforce sandbox only.
• Required assertions: donation response, FRAPI acceptance row, provider test identifier, and any Salesforce sandbox record agree on run identity, amount, currency, payment provider, donation type, and terminal status.
• Source-of-truth rule: the owner must identify which FRAPI/database fields replace each removed Salesforce assertion. LTI must not infer parity from a successful HTTP response alone.
• Compatibility gate: scenarios must run without Salesforce when removal is enabled and must use sandbox-only assertions when Salesforce validation is enabled.
• Owner confirmation needed: removal milestone, replacement fields and tables, sandbox object/key mapping, synchronization latency, and read/write permissions.
• Pass gate: the same synthetic donation produces deterministic evidence in the enabled source of truth without querying or writing production.

RC BigQuery Synchronization

• Approval task: Asana 1216410161122874
• Status: blocked_on_data_contract
• Allowed behavior: read-only validation after ingestion.
• Required assertions: the run-owned signature or donation appears once in the designated acceptance dataset with matching correlation key, list, campaign/fundraising identifier, amount/currency where applicable, outcome, and event timestamp.
• Owner confirmation needed: Google Cloud project, dataset, tables/views, partition field, correlation key, expected ingestion latency, freshness SLO, duplicate/backfill behavior, restricted query identity, and approved sample query.
• Pass gate: bounded polling succeeds inside the documented latency and includes query job/evidence identifiers without storing row-level personal data.

AM Iterable Journeys and Snippets

• Approval task: Asana 1216860419874164 (owner-confirmation follow-up created from completed planning task 1216410130911271)
• Status: partially_confirmed
• Confirmed surface: EU Data Ingestion project with the restricted internal test audience and acceptance credentials.
• Required journey: create/update a unique synthetic profile through the acceptance backend, verify expected list/event/subscription changes, render approved snippet behavior, exercise unsubscribe only for that profile, and verify the acceptance webhook result when enabled.
• Required evidence: hashed synthetic identity, Iterable project/list or journey identifiers, event names and timestamps, redacted API status, webhook correlation, and cleanup/manual-review result.
• Safety rule: no production audience, campaign send, personal employee profile, or broad list removal. Test sends require an explicitly approved internal mailbox.
• Owner confirmation needed: canonical acceptance list, allowed journey and snippet IDs, trigger event names, expected state transitions, webhook URL and signature policy, asynchronous latency, and cleanup behavior.
• Pass gate: one synthetic profile follows the expected state transitions without entering a production audience or sending to an unapproved address.

GL PPAE Agentic WebApp Ingestion

• Approval task: Asana 1216410130765186
• Status: pending_owner_confirmation
• Accountable external owner: Guilherme Lopes.
• Required journey: create one run-owned PPAE fixture from an approved template, move it through the owner-confirmed workflow states, ingest it into WebApp acceptance, and verify the resulting campaign without publishing or sending it.
• Required evidence: template/version identifier, run correlation key, workflow state history, WebApp acceptance identifier, bounded processing timestamps, and exact cleanup or archive result.
• Owner confirmation needed: canonical PPAE source/version, safe test template, trigger event, required task/phase/custom-field states, stable correlation key, asynchronous latency, and owner-approved reset or cleanup.
• Safety rule: no production campaign, production project mutation, campaign publication, audience send, or broad cleanup.
• Pass gate: one synthetic fixture reaches the expected WebApp acceptance state exactly once and can be deterministically archived or cleaned up.

JK External Synchronization and Cleanup

• Approval task: Asana 1216410160944244
• Status: pending_owner_confirmation
• Accountable external owner: Jakub Korkosz.
• Required journey: emit one run-owned event to each approved external sandbox integration, verify its terminal side effect, repeat the event to prove idempotency, and clean up only the run-owned external object when the owner contract permits it.
• Required evidence: source and destination system labels, redacted correlation key, attempt count, terminal state, processing latency, retry result, and exact cleanup result.
• Owner confirmation needed: integrations in scope, sandbox endpoints, event contracts, side effects, idempotency key, retry and latency semantics, cleanup API/ownership, and systems where cleanup is intentionally manual.
• Safety rule: no production fallback, broad deletion, unbounded retry, or use of an external identity that is not owned by the LTI run.
• Pass gate: the external side effect appears exactly once after a replay and the cleanup outcome matches the confirmed owner contract.

Review and Change Control

• An external owner confirms or corrects the pending fields in the linked Asana task.
• The confirmed contract is updated here in the same pull request as the executable scenario or adapter.
• Contract changes that alter stored run metadata also update specification 005.
• A provider or data dependency may remain disabled without blocking unrelated scenarios. The suite reports it as blocked, not passed or silently skipped.