How this fits together

An operator declares a configuration and proves it works while declaring it — the connection is tested, the schema discovered, and the columns chosen and described before anything is submitted. The record is then locked, and only then does a worker extract and land data.

  • built, deployed, exercised
  • built or declared — not yet exercised end to end
  • enforced server-side
  • not ours — another team, another resource group
Flow: input and config plane feed a ten-step wizard; step 2 tests each partner's connection and discovers its schema; the versioned contract gates a submit-and-lock; a worker then extracts named columns to Parquet in ADLS with a YAML schema and DuckDB views, read by TenantIQ MCP and a separate evidence service.

Click to view full size

What this encodes that is easy to get wrong

The lock is the deliverable, not a checkpoint. Phase 1 ends at the lock. It declares an integration contract and never executes it.

One source per partner, not one per client. A client running FieldAssist for SFA and somebody else for DMS has two sources, two credentials and two schemas. A single shared form could only ever describe one of them.

The column selection is the schema approval. Choosing columns and describing them at step 2 is the approval — made by the person who has the schema in front of them. The description is the mapping artefact the interpreter reads, not documentation, so a change after approval is a contract change.

A source kind we cannot probe is refused by name. It never falls back to SQL. A REST endpoint probed as a database produces a driver error about a host that was never a host, and sends the operator to check something correct.

Alerts are proposals. Onboarding writes nothing to the trigger registry — not one row.

The DuckDB layer copies nothing. Views over the same Parquet, never a materialised table. The schema and views are derived and regenerable; deleting them loses nothing but convenience.

The read side is split, and stays split. TenantIQ MCP serves the compiled tenant profile and reads no client rows. The evidence service — a separate module in a different resource group — is the only thing that touches landed client data.