Appearance
Cross-Artifact Verification
A study setup spans several artifacts: source documents (SOW, Protocol), the governed Study Model, generated outputs (PSD, Lab Manual, KDF, POP), and the configuration mirrored into downstream systems (BSI, Infor, Smartsheet). Keeping these consistent has been described as needing a Cross-Artifact Verification Engine that continuously compares artifacts and flags disagreements.
Study Setup does not build such an engine. The Study Model (captured in immutable Checkpoints) is the single authoritative source, and every other artifact is either generated from it, proposed into it through a governed change flow, or synchronized from it with explicit drift detection. Because no artifact is an independently authored copy that could silently disagree with the model, consistency is a property of how artifacts are produced and synchronized rather than a separate after-the-fact check. The concern reduces to three existing mechanisms, each owned by an existing module.
| Consistency concern | How it is solved | Owning module |
|---|---|---|
| Study Model ↔ Output documents | Direct generation — outputs are rendered from the model, so they are in sync by construction | Templates, Document Review |
| Inputs ↔ Study Model | Formal change detection & resolution — extracted input data is diffed against the model and reconciled through changesets | Source Ingestion, Studies |
| Study Model ↔ Remote systems | Automated provisioning & drift detection — approved checkpoints are released and remote snapshots are compared back against the model | Provisioning, Studies |
1. Direct generation of outputs from the Study Model
Output documents (PSD, Lab Manual, KDF, POP) are generated from the Study Model through Templates — they are never hand-authored as independent artifacts. Because an output is a rendering of the model at a given checkpoint, an output and the model it was produced from cannot disagree: there is nothing to verify between them. When the model changes, the affected outputs are regenerated; staleness is handled by requiring a refresh against the current checkpoint, not by a comparison pass that hunts for inconsistencies.
This is why there is no "does the PSD match the Study Model?" check — the question is structurally meaningless when the PSD is a projection of the Study Model.
2. Formal change detection and resolution between Inputs and the Study Model
Source documents are not silently trusted, nor are they compared by a generic engine. The Source Ingestion pipeline extracts attributes from each input and its Diff stage compares them against the current Study Model checkpoint, packaging every difference as a Changeset. The Attributes view surfaces these as per-source columns, and disagreements are highlighted for triage.
Reconciliation is an explicit, governed decision: the SDL reviews the proposed changes and applies, edits, or rejects them through the standard changeset flow. The "verification" of inputs against the model is therefore continuous and built into ingestion — every completed ingestion job is, in effect, a verification pass whose result is a reviewable changeset rather than a passive report.
3. Automated provisioning to remote systems and drift detection
Downstream systems (BSI, Infor, Smartsheet) receive configuration through Provisioning: only approved checkpoints are released, so the model is the authoritative source pushed outward. To catch divergence that arises after release — for example, a value edited directly in a remote system — Study Setup captures immutable Remote Snapshots and compares them against the model.
Differences raise DriftDetected events and appear as remote-system columns in the Attributes view, where they are resolved by either pushing the model value outward (update_remote) or pulling the remote value in as a proposed change (update_model). This is the same detect-and-resolve loop as inputs, applied to the outbound direction.