Posit vs Domino vs SAS for Pharma: Computing Compared

Posit, Domino, and SAS represent overlapping architectural choices for a pharmaceutical statistical computing environment (SCE). Posit Team bundles development, publishing, and package management. Domino provides multi-language execution and provenance, and documents integration with Posit Package Manager. SAS Clinical Acceleration explicitly supports SAS, R, and Python. The decision is therefore about the controlled environment and operating responsibilities, rather than a binary SAS-versus-R replacement. (^[1]) (^[2]) (^[3]) (^[4])

The regulatory baseline does not select a winner. The US Food and Drug Administration (FDA) does not require a specific statistical-analysis software product. The European Medicines Agency (EMA) states that the responsible party remains responsible for system validation even when vendor documentation is used. Buyers should require evidence for their configured intended use, including approved runtimes, dependencies, access, execution records, and recovery. A platform's documented controls are inputs to sponsor validation, not a transferable validation status. (^[5]) (^[6])

The quantitative evidence has distinct boundaries. Posit Connect documents configurable defaults of 10 concurrent scheduled reports for Local Execution and 20 for Off-Host Execution. (^[7]) Domino documents 30 years of audit-data retention. (^[8]) The R Consortium reports that its first submission pilot contained 4 R programs. (^[9]) These figures describe configuration, retention, and pilot scope respectively; none measures comparative clinical-analysis throughput. The reviewed sources establish no controlled performance ranking, and the reviewed pricing pages do not establish comparable prices for a defined regulated deployment. (^[10])

The recommended selection process is a controlled proof of concept followed by an explicit responsibility and evidence review. Pin the approved runtime, preserve package sources and locked inputs, run the same analysis through the proposed batch service, and recover its evidence after an environment change. Kubernetes' image-digest guidance supports pinning the executable artifact, while the Clinical Data Interchange Standards Consortium (CDISC) traceability guidance explains why the actual derivation inputs must also remain available. Use coexistence and study-level qualification to modernize deliberately. Choose the configuration that demonstrates reproducible execution, complete evidence, and workable ownership under the sponsor's requirements. (^[11]) (^[12])

A statistical computing environment (SCE) is best evaluated as the controlled path from approved inputs to reviewable analysis outputs. Its programming language, integrated development environment (IDE), execution service, package repository, and data store are separate architectural decisions. A practitioner discussion at PharmaSUG examines standardizing multiple language versions within a shared platform, illustrating why comparing only SAS syntax with R syntax misses the environment decision. (^[13])

The regulatory starting point is straightforward: the US Food and Drug Administration (FDA) does not require a particular statistical-analysis software product and expects software identification in submissions. (^[5]) (^[14]) Its study-data guide discusses XPORT Version 5 as a transport format and explicitly distinguishes transport from dependence on a particular vendor's programs. A dataset format therefore does not establish which language must produce it. (^[15]) (^[16])

This report compares architectures for biometrics platform owners, statistical programming leaders, validation teams, and research information technology (IT) architects. The editorial decision framework separates:

• Language: statistical procedures, numerical behavior, and programming conventions.
• IDE: the interactive editor and its session-specific controls.
• Execution: approved images, batch services, schedulers, and compute allocation.
• Dependencies: package versions, repositories, installation sources, and recovery assets.
• Evidence: input lineage, program review, execution records, output checks, and retention.

These layers connect: CDISC's Analysis Data Model (ADaM) traceability guidance links an element to its predecessors and ultimately source collection. Infrastructure records alone cannot establish that analytical lineage. (^[17])

IntuitionLabs' adjacent advisory perspective is relevant to architecture and implementation: its own site describes technology roadmapping and advisory services. It is not an SCE product option in this comparison. (^[18]) Recommendations below are editorial judgments about control design, separated from documented features and attributed vendor accounts.

The editorial publication anchor is October 13, 2026; source access occurred October 15, 2026. Current undated pages establish what was observed during this research, not a historical snapshot for the earlier date. Version-qualified documentation is identified where it materially limits a conclusion.

Capabilities

Posit Team combines Posit Workbench, Posit Connect, and Posit Package Manager, with documented installation in customer-managed on-premises or cloud environments. (^[1]) The useful comparison unit is this toolchain plus the sponsor's storage, identity, orchestration, and validation arrangements.

Workbench provides interactive development and cluster integration. Its Job Launcher documentation covers Slurm and Kubernetes, along with RStudio Pro, Positron Pro, Jupyter, and Visual Studio Code sessions. Standalone Workbench jobs can execute scripts on a cluster. (^[19]) Launcher availability depends on the purchased edition, so a demonstration should use the proposed commercial configuration. (^[20])

Package Manager contributes a different control layer. Repository actions receive snapshot identifiers, while curated sources can expose selected packages and versions from the Comprehensive R Archive Network (CRAN). These controls help separate a discovery library from an approved analysis library. They do not establish the suitability of every statistical function for a study. (^[21]) (^[22])

Connect supports scheduling reports published with source. This is a specific publishing and execution capability; buyers should map their complete clinical batch workflow to the services that actually execute it. (^[23])

Adoption

The strongest adoption rationale is an organization that wants an open-source-centered analysis workflow while retaining flexibility over surrounding infrastructure. Posit's pharma guidance describes separate repositories for tested packages and explains that validation begins with user requirements. This supports an incremental implementation around existing standards rather than requiring a wholesale change of statistical language. (^[24])

A practical adoption review should establish:

• Purchased scope: required IDEs, launcher features, publishing, and evidence capabilities.
• Runtime ownership: who builds, approves, stores, and restores each environment.
• Package promotion: who authorizes a snapshot for a study and preserves its dependencies.
• Operational ownership: who monitors execution and exports evidence before expiry.

These are proposed acceptance criteria, not claims that a default installation fulfills them.

Strengths and Limitations

The Advanced-tier audited Workbench jobs documentation describes signatures, environment information, and user-defined information alongside outputs. It also documents digesting completed output and capturing language versions and installed packages. Those are concrete artifacts to request during a regulated-use demonstration. (^[25])

Coverage and retention require configuration-specific review. Workbench's session-event documentation limits that coverage to RStudio Pro sessions; audited jobs have configurable expiry. Teams should test each chosen IDE and export required records before their configured lifetime ends. (^[26]) (^[27])

Editorially, Posit fits buyers prepared to assemble and govern an analysis toolchain. Its modularity allows deliberate boundaries, but the acceptance test must span those boundaries, including the package archive, scheduler, external data, and evidence repository.

Capabilities

Domino presents its SCE as combining SAS, R, and other tools with traceability. Its deployment documentation describes self-installed Kubernetes operation and managed services in a customer's cloud or a single-tenant vendor cloud. These are distinct operating arrangements requiring different responsibility matrices. (^[2]) (^[28])

Domino compute environments use Docker images to create isolated execution containers. The documentation exposes revisions and permits an administrator to stop automatically assigning new revisions as active. That supports an approval process, provided study execution actually references the approved revision. (^[29]) (^[30])

The Domino Reproducibility Engine (DRE) records Git commits and the compute-environment version used at execution. It also documents an important boundary: data obtained through external data sources or direct database connections are not automatically tracked by that mechanism. Sponsors should preserve a dated extract, immutable object version, or equivalent input snapshot outside that automatic coverage. (^[31]) (^[32]) (^[33])

Domino separates interactive workspaces from headless jobs. Jobs support external pipeline triggers, and its documented architecture includes dynamic cluster capacity. (^[34]) (^[35]) (^[36]) Its architecture also documents federation to single sign-on (SSO) systems and third-party identity providers. (^[37]) The platform assessment should cover execution, identity mappings, and the underlying cluster together.

Adoption

The adoption rationale is broader execution governance across existing language communities. Domino also documents a Posit Package Manager integration that can update an environment and its lockfile through administrator-configured commands. Thus, choosing Domino need not mean choosing against every Posit component. (^[3])

A vendor-published GSK account describes more than 2,000 users across biostatistics and partnering functions. This is evidence of a named implementation's reported organizational scale, not independent evidence of comparative throughput, cost, or implementation effort. (^[38])

An adoption review should require:

• Project boundaries: study-specific permissions and controlled access to source data.
• Revision policy: explicit approval and selection of execution environments.
• External lineage: preserved versions of data beyond automatic tracking.
• Evidence export: a usable archive outside an administrator's live interface.

Strengths and Limitations

Domino documents privileged audit-trail access through designated administrative roles and export of filtered system events. These support a concrete demonstration: show who can inspect a record, who can change relevant configuration, and how an independent reviewer receives an archive. (^[39]) (^[40])

A scheduled job can select an environment revision; the documented default uses the latest revision. For a locked analysis, approval should cover the scheduled configuration itself. Reproducibility depends on what the scheduler resolves when execution starts. (^[41])

Editorially, Domino fits buyers seeking a shared multi-language execution layer. Selection should turn on the demonstrated completeness of study evidence, including externally stored inputs and archive recovery, rather than assuming that a run history encompasses every dependency.

Capabilities

SAS is a portfolio decision. Its clinical research page lists Life Science Analytics Framework (LSAF) as a clinical SCE and Viya Workbench as an on-demand analytical development environment. These names should not be treated as interchangeable bundles. (^[42]) (^[43])

The current SAS Clinical Acceleration page combines repository and SCE capabilities, identifies a separately available Repository component, and explicitly supports analyses in SAS, R, or Python. A SAS-centered environment therefore need not be a SAS-language-only environment. The actual order should identify the products and integrations being supplied. A cross-vendor supported-version matrix was not established by this research; require the proposed language builds, operating systems, system libraries, and package versions in the acceptance baseline. (^[44]) (^[4])

Infrastructure also differs across the portfolio. Red Hat's joint architecture discussion identifies Kubernetes as Viya's underlying runtime and describes public- and private-cloud distributions. SAS documents deployment on OpenShift within existing infrastructure. These sources support a customer-infrastructure option without establishing that every clinical product has identical deployment arrangements. (^[45]) (^[46]) (^[47])

SAS Grid Manager documents centralized queues and priorities; the same product page distinguishes workload management on Viya within Kubernetes. A comparison should preserve that distinction when assessing an existing SAS estate against a proposed target. (^[48]) (^[49])

Adoption

A SAS-centered choice deserves consideration when the sponsor intends to preserve its existing programs, macro libraries, operating procedures, and programmer workflows. That is a decision criterion, not a claim about the size of any installed base. The proposed platform should demonstrate representative existing programs rather than infer compatibility from the vendor name.

Open-source interoperability also needs precise wording. SAS's documented R package is a client for Cloud Analytic Services (CAS). Calling CAS from R is a different architecture from executing an arbitrary R package library in an independently governed runtime. (^[50])

An adoption review should establish:

• Product identity: exact clinical, execution, repository, and optional components.
• Compatibility: representative program results and documented differences.
• Entitlements: licensed procedures, external-language interfaces, and compute rights.
• Promotion: controlled movement of programs, configuration, and dependencies.

Strengths and Limitations

SAS's Jobs and Flows manual documents execution history and an allowlist for command-line job actions. These are useful acceptance-test subjects: run a permitted analysis, reject an unauthorized command, and export the resulting execution evidence. (^[51]) (^[52])

Audit conclusions require version discipline. The reviewed 2024.03 through 2024.07 Viya audit guide describes immutable audit records and states that the archive file system is not configured during deployment. This is version-qualified evidence to investigate in the proposed release, not an assertion that a current deployment is already archived correctly. (^[53]) (^[54])

Editorially, SAS fits a continuity-led strategy when the contracted architecture meets the sponsor's requirements. A buyer should compare its specific SAS configuration against specific Posit and Domino configurations, including open-source coexistence, rather than compare an entire vendor portfolio with a single competing application.

Table 1 compares architectural responsibilities. Entries describe the reviewed documentation, not a feature score or certification. A component's presence does not establish the behavior of a fully configured submission-producing system.

Decision layer	Posit	Domino	SAS
Commercial comparison unit	Team toolchain: Workbench, Connect, Package Manager. ([1])	Multi-language SCE and execution platform. ([2])	Named clinical and analytical products; specify the contracted combination. ([42])
Deployment	Customer-managed cloud or on-premises installation. ([55])	Self-installed Kubernetes or documented managed-service arrangements. ([28])	Viya supports public/private Kubernetes architectures; verify clinical-product topology. ([46])
Approved environment	Package snapshots supplement the selected runtime. ([21])	Image-based environments with selectable revisions. ([29])	Verify runtime governance in the selected clinical product; Clinical Acceleration supports multiple languages. ([4])
Batch orchestration	Launcher integrates cluster execution; Connect schedules source reports. ([19])	Headless jobs and external pipeline triggers. ([35])	Grid queues and priorities; Viya workload management is separately described. ([48])
Evidence boundary	Audited jobs capture environment and output evidence; inspect IDE coverage separately. ([25])	Execution provenance includes environment versions; external inputs need explicit controls. ([33])	Execution history is documented; confirm export and retention for the contracted release. ([51])

The matrix suggests a practical distinction: Posit emphasizes an integrated toolchain, Domino a shared execution layer, and SAS a portfolio that can preserve or modernize a SAS-centered estate. These are editorial descriptions of the documented architectures. They do not establish exclusive capabilities or a universal winner.

Map controls to reviewable evidence

For closed systems within its scope, Title 21 of the Code of Federal Regulations (21 CFR), section 11.10 addresses validation, authorized access, record copies, and audit trails. Applicability and implementation should be assessed with the sponsor's quality and regulatory specialists. The European Medicines Agency (EMA) likewise retains responsibility with the responsible party when vendor validation documentation is used. (^[56]) (^[6])

Table 2 turns those principles into proposed procurement and validation tests. The evidence examples are this report's implementation recommendations; the cited sources establish their regulatory or technical rationale.

Control	Evidence to retain	Acceptance demonstration
Intended use	Approved requirements, risk assessment, configuration baseline, test results.	Trace critical requirements to approved tests and outcomes. ([57])
Runtime identity	Image digest, build recipe, runtime and system-library manifest.	Resolve an approved digest and recover the same image after rollback. ([11])
Package governance	Repository snapshot, lockfile, package sources, approval record.	Restore recorded versions without resolving fresh dependencies. ([58])
Authorized access	Role matrix, group mapping, access approvals, tested revocation.	Remove a user and demonstrate that protected work is inaccessible. ([59])
Execution history	Actor, timestamp, program revision, input identity, logs, status.	Reconstruct creation and changes without overwriting earlier history. ([60])
Analytical traceability	Derivation specifications, source references, output-to-program links.	Trace a reported result through analysis data to its predecessors. ([61])
Export and recovery	Human-readable copies, electronic records, archive index, retrieval test.	Recover a reviewable record set independently of the live workspace. ([62])

A product can contribute evidence without completing the sponsor's validation. EMA expects validation activities to be planned, documented, and approved. A successful demonstration becomes part of that process only when the sponsor evaluates it against its intended use and approved configuration. (^[63])

Submission-readiness checklist

The minimum archive proposed here is an evidence package rather than a screenshot of a successful run. The International Council for Harmonisation (ICH) E6(R3) guideline calls for retaining statistical-programming records associated with reported outputs, including quality-control and validation activities. (^[64])

• Programs: reviewed source, immutable revision, macros, configuration, and execution entry point.
• Inputs: frozen datasets, metadata, extraction specifications, and provenance.
• Environment: image identity, language build, system libraries, and package manifest.
• Execution: command, parameters, timestamps, actor, logs, and completion status.
• Outputs: datasets, tables, listings, figures, and their hashes.
• Checks: independent review, reconciliation, numerical tolerances, and dispositions.
• Retention: ownership, access rules, archive location, and successful retrieval evidence.

The distinction between execution lineage and analytical lineage matters. CDISC notes that checking a derivation requires the input data used to create it. A platform-generated run identifier cannot replace those inputs or the derivation specification. (^[12])

What the evidence establishes

The reviewed sources do not provide a controlled, like-for-like benchmark across these shortlisted architectures. No speed, cost, or productivity ranking is calculated. A reported customer deployment and a documented concurrency setting answer different questions from the elapsed time required to reproduce a sponsor's locked analysis.

A useful proof of concept measures the full path: admission to the execution queue, environment startup, data access, computation, output checking, and evidence export. Slurm's accounting documentation illustrates the available distinction between job status, steps, and exit codes. Successful scheduling alone should not count as an analytically successful rerun. (^[65])

The test protocol should define:

• Workload: a representative locked analysis and a separate interactive development task.
• Equality: byte identity where appropriate and prespecified semantic checks elsewhere.
• Recovery: reconstruction from retained assets after losing the original workspace.
• Load: comparable resources, input sizes, parallelism, and simultaneous users.

These are proposed measurement conditions. Buyers should agree them before seeing results, including exclusions for environmental failures and rules for rerunning a failed test.

A reproducibility test readers can execute

Cryptographic digests detect changed content; they do not establish statistical correctness. NIST describes this change-detection purpose, while Reproducible Builds defines exact artifact reproduction using the same source, environment, and instructions. Applying those ideas to clinical outputs requires an additional sponsor-defined analytical comparison. (^[66]) (^[67])

The following Hypothetical Example uses synthetic data and Python's standard library. It is a portable demonstration of hashing and result comparison, not a validated analysis or a performance benchmark. Save it as a controlled script and execute it as a batch job in each proposed environment.

import hashlib, json, platform
from decimal import Decimal

inputs = b"arm,value\nA,10\nA,12\nB,13\nB,15\n"

def analyze(raw):
    groups = {}
    for row in raw.decode().splitlines()[1:]:
        arm, value = row.split(",")
        groups.setdefault(arm, []).append(Decimal(value))
    means = {
        arm: str(sum(values) / len(values))
        for arm, values in sorted(groups.items())
    }
    return json.dumps(means, sort_keys=True).encode()

outputs = [analyze(inputs) for _ in range(4)]
reference = outputs[0]
changed = analyze(inputs.replace(b"B,15", b"B,17"))
report = {
    "python": platform.python_version(),
    "system": platform.platform(),
    "input_sha256": hashlib.sha256(inputs).hexdigest(),
    "output_sha256": hashlib.sha256(reference).hexdigest(),
    "output": json.loads(reference),
    "rerun_success_pct": 100 * sum(
        item == reference for item in outputs
    ) / len(outputs),
    "changed_input_detected": changed != reference
}
print(json.dumps(report, sort_keys=True, indent=2))

The four local evaluations are illustrative repeated calls in one interpreter, not independent recovered executions. A production test must replace those calls with results collected from fresh scheduled jobs and recovered environments. Preserve the script, report, scheduler log, runtime manifest, package lock, and platform evidence together. Hash comparison follows the artifact-comparison principle documented by Reproducible Builds. (^[68])

Calculate rerun success (%) = accepted reruns / attempted reruns × 100. Define acceptance to include output checks and complete evidence. Calculate unexpected drift (%) = unexpected changed outputs / compared outputs × 100. Keep intentional input changes in a separate positive-control category. These formulas are proposed evaluation definitions, not published product metrics.

A numerical difference should be classified against the approved tolerance and analytical consequence. Byte changes in rendered documents can also arise from metadata. Preserve both exact hashes and the semantic comparison report instead of allowing either measure to stand for the other.

Table 3 separates quantitative observations by their actual unit and scope. All pages were accessed during this research; source dates are supplied where stated. Organization-specific and product-configuration figures have no geographic extrapolation.

Evidence and source date	Quantity and scope	What it can establish
Connect scheduling, undated live documentation	Default maximum 10 concurrent scheduled reports in Local Execution and 20 in Off-Host Execution; configurable product settings, geography not applicable. ([7])	A configuration question, not an analytical throughput benchmark.
Domino audit documentation, undated	30 years of stated audit-data retention; vendor-documented product behavior, geography not specified. ([8])	A retention claim to verify against deployment, contract, exports, and recovery requirements.
R Consortium update, February 2026	Pilot 1 contained 4 R programs; one submission pilot, geography: US FDA submission context. ([9])	Feasibility evidence with a deliberately narrow program scope.
R Consortium update, February 2026	Pilot 4's WebAssembly component was submitted through the FDA gateway on September 20, 2024; one reported submission event. ([69])	A dated submission milestone, not universal acceptance of an environment.
Domino's GSK account, undated	More than 2,000 users across the described functions; geographic distribution not specified. ([38])	Reported implementation scale, without a controlled comparator.

The figures cannot be combined into a platform score. Concurrency is a setting, retention is a documented policy, pilot size describes a demonstration, and users describe deployment reach. None is a measured estimate of the sponsor's migration cost or submission-cycle improvement.

The R Consortium's account is an originator report about its own work. Likewise, Domino's customer account is vendor-published deployment evidence. These distinctions preserve useful information while preventing a feasibility example from becoming an unsupported performance claim.

Commercial evidence and total cost

Posit's pricing page identifies named users as a pricing basis. Domino directs buyers to its account team for a quote, and SAS's Viya pricing page requests information about the prospective deployment. Comparable prices for a defined pharmaceutical SCE were not established from these pages. No missing value is treated as zero. (^[70]) (^[10]) (^[71])

A comparable request for quotation should state the environment count, user roles, compute arrangements, storage, package services, support, evidence export, and retention requirements. The costing boundary proposed here includes:

• Commercial charges: platform products, required options, and language entitlements.
• Infrastructure: compute, storage, network movement, backup, and archive recovery.
• Operations: image builds, package curation, monitoring, access administration, and support.
• Validation: intended-use tests, change assessment, evidence review, and periodic evaluation.
• Transition: training, parallel running, program qualification, and study migration.

The total should use a common term and workload assumption. Lower license expenditure alone cannot establish lower total cost when the operating and validation responsibilities differ.

Govern packages and runtimes independently

A validated R environment for clinical trials requires a defined intended use and operating procedures around the actual dependency set. The R Foundation's guidance applies to the official R distribution, not arbitrary add-on packages, and places substantial obligations on the user's organization. A pharmaverse listing also does not endorse a package's reliability for a particular analysis. (^[72]) (^[73]) (^[74])

Use package risk assessment to determine necessary review and testing, with the scope tied to clinical use. ICH's risk-based validation principle supports proportionality to intended use and the importance of the information. A package approval should therefore state what was evaluated, rather than imply that every possible use has been validated. (^[75])

For R, renv records package versions, sources, repositories, and R information, and restores recorded package versions. For Python, pip documents pinning dependencies and verifying downloaded artifacts with hashes. These mechanisms complement infrastructure controls; they do not replace statistical quality control. (^[58]) (^[76]) (^[77]) (^[78])

Kubernetes distinguishes mutable tags from immutable image digests. Preserve the approved image and its build dependencies, not merely a familiar tag. For offline recovery, pip also documents wheel archives and their operating-system and architecture constraints. Recovery assets must match the target environment. (^[79]) (^[80])

Plan coexistence around studies

A phased migration should preserve explicit execution boundaries. The following is a proposed sequence, not a universal requirement to keep or replace a language:

• Inventory: map studies to programs, dependencies, outputs, owners, and retention obligations.
• Separate: establish discovery and controlled-analysis environments with approved promotion.
• Coexist: add a governed R or Python workflow alongside an unchanged reference analysis.
• Compare: prespecify checks and investigate substantive differences before promotion.
• Migrate: move selected studies or components after successful qualification and recovery tests.

Cross-language agreement is useful evidence, but statistical-programming quality control must remain documented. Agreement with an existing result does not independently establish that both implementations follow the intended analysis. (^[81])

This approach is consistent with IntuitionLabs' stated service scope of selective modernization across SAS and open-source workflows. That first-party description explains its advisory perspective; it is not evidence that any shortlisted product delivers a particular result. (^[82])

Require recovery and change demonstrations

The final selection should include demonstrations of a complete analysis rerun, disaster recovery, package upgrade, and controlled rollback. For each, define the initiating change, approval, expected outcome, retained evidence, and responsible owner. Suggested scenarios are:

• Analysis rerun: recover a locked input and program, execute a fresh job, and compare outputs and evidence with the reference.
• Disaster recovery: restore access mappings, images, package assets, data, and archives into an isolated recovery environment, then repeat the analysis.
• Package upgrade: promote a changed dependency through testing, record expected differences, and confirm unrelated locked studies retain their approved environment.
• Controlled rollback: return the execution configuration to the approved baseline and demonstrate that the old results and their history remain recoverable.

Record a pass only when the predefined checks and required evidence are complete.

Preserve old study environments while qualifying changes separately. Rebuilding an image against an evolving package repository can alter its contents; Posit's change-control documentation explicitly cautions that Docker alone does not guarantee reproducibility. (^[83])

Finally, test archival retrieval without relying on a live user's account. EMA describes read-only archival and continued availability of required files and software. That makes long-term recovery a selection criterion alongside interactive usability and compute capacity. (^[84])

The practical answer to Posit vs Domino vs SAS for pharma is conditional on the intended operating model. An open-source-centered organization should evaluate Posit's toolchain and the surrounding controls it must own. A team seeking shared multi-language execution should evaluate Domino's revision, lineage, and export behavior. A continuity-led organization should specify the SAS clinical and execution products it needs, including any open-source workflows.

These are starting hypotheses for procurement, not a ranking. The comparison should use contracted configurations and representative study workloads. A package repository, IDE, execution service, and clinical content repository serve different functions, even when presented within the same commercial platform.

The deciding evidence should be concrete: an approved analysis can be rerun with identified inputs and dependencies; its output can be checked against prespecified criteria; an independent reviewer can reconstruct its history; and retained records can be recovered after operational change. The validation team should assess that evidence against the sponsor's intended use.

Coexistence can provide a controlled route to modernization. Preserve the reference workflow for the work that requires it, qualify new components deliberately, and promote changes through an approved process. Select the architecture whose demonstrated controls, responsibilities, and operating costs fit the portfolio. A language preference or broad platform claim cannot substitute for that review.