OPERATIONAL INTELLIGENCE · CODING OPERATIONS · INSIDE YOUR PERIMETER
Governed AI coding operations for clinical programming.
The daily work of a programming team runs through agents and skills your reviewers can audit: environment setup, program execution, parity checks, log diagnosis, lineage questions, controlled backups. Delivered inside the estate and the IDE your team already uses. The four rules apply to every package on this page.
These packages describe methods INNOVIZZ builds and runs in current sponsor-side work. No client is named on this page and no client-derived figure appears on it.
01
PACKAGE 01 · THE USUAL ENTRY WORKFLOW
Migration Parity Validation
Dataset equivalence between a legacy and a target environment: SAS 9.4 or LSAF to Viya, or SAS to R. A deterministic comparison engine runs in your estate, classifies every discrepancy, and produces an equivalence report per dataset. A model assists only in drafting discrepancy explanations, and a reviewer accepts each one.
Check it: every equivalence report names its comparison rules and its reviewer.
YOU PROVIDE
Both environments, the program and dataset inventory, acceptance criteria for equivalence.
YOU RECEIVE
The comparison engine in your estate, an equivalence report per dataset, a classified discrepancy log, the code.
SIGN-OFF
Your validation lead accepts equivalence before any cut-over; nothing moves on a model's word.
02
PACKAGE 02 · IDE-NATIVE
Governed Agent Shelf in the IDE
A versioned set of agent skills inside the editor your programmers already use: job launch and scheduling on the platform, run triage with a log-proven output inventory, log diagnosis with an evidence pack per verdict, study and reporting-event provisioning, and controlled backups. Write actions are gated by named approval; generated programs land in a controlled folder; capability changes travel through a governed request loop, never a local edit.
Check it: the shelf is a repository you read; every version carries its change record.
YOU PROVIDE
The IDE standard, platform access under your identity system, your SOPs for change and backup.
YOU RECEIVE
The skill repository in your source control, a user guide, training, and a change record per release.
SIGN-OFF
Your platform owner approves each capability before rollout; approvals are recorded per action.
03
PACKAGE 03 · DUAL-STACK
R Integration and Qualified R Environments
R working inside the SAS estate rather than beside it: macro bridges for standalone and dataset-dependent R programs, platform connections from the analyst's own R session, and a qualification framework that makes the R environment defensible under GxP. Includes dual-stack parity checks when a deliverable moves from SAS to R.
Check it: the qualification framework is a document set your QA reads before use.
YOU PROVIDE
The target R use cases, the environment, your validation SOP and package policy.
YOU RECEIVE
Working integration patterns, the qualification framework documents, parity evidence for converted deliverables.
SIGN-OFF
Your statistician or validation lead accepts the qualification evidence before production use.
04
PACKAGE 04 · METADATA
Metadata Lineage and Impact Analysis
A queryable lineage layer over your programs and metadata that answers the questions that stall a study: what breaks if this variable is renamed, which programs read this dataset, where a derivation comes from. Optionally extended to a knowledge-graph layer with natural-language query, running entirely inside your perimeter.
Check it: every lineage answer cites the program and line it was read from.
YOU PROVIDE
Program repositories and metadata exports, or catalog access, read-only.
YOU RECEIVE
Lineage and impact reports, the queryable layer in your environment, the extraction code.
SIGN-OFF
Your data standards lead validates sampled answers against source before the layer is trusted.
ONE OPERATING LOOP · EVERY PACKAGE RUNS ON IT
Nothing acts alone. Everything is logged.
Your platform + programs
Agent proposes
Rules layer checks
Named reviewer approves
Executed + written to your audit log
Migration parity, IDE agents, R qualification, lineage queries: different packages, same loop. The gate before execution is always a person.
THE EVIDENCE LAYER · SYNTHETIC SAMPLES · FORMAT, NOT MECHANISM
Every action in the loop leaves a record. These are the records.
Three sample records, rendered from synthetic data, showing the format your QA team receives. How the records are produced stays inside the engagement; what they contain is shown here, because that is what an auditor reads.
APPROVAL LOGSYNTHETIC
[0712] job.launch study=SYN-001
approver platform owner (named)
verdictAPPROVED · scope: run only
[0713] write.request output folder
verdictAPPROVED · controlled dir
[0714] write.request prod dataset
verdictREFUSED · outside scope
Every write action names its approver. Refusals are records too.
CAPABILITY CHANGE RECORDSYNTHETIC
shelf v1.4 → v1.5
change log-triage skill: new verdict class
requested via governed request loop
tested sandbox, reviewer account
approved platform owner (named)
released source control, tagged
No capability changes by local edit. The shelf is a repository you read.
RUN EVIDENCE PACKSYNTHETIC
run re-execution, reporting event A
log hash7c41e9…20ab
outputs 38 expected · 38 produced
diagnosis 2 warnings, both dispositioned
reviewer named, sign-off recorded
written to your audit log, not ours
Verdicts cite the log line they were read from.
These samples show the record format only. The agents, rules and wiring that produce them are INNOVIZZ-built and are not published; they are demonstrated inside your environment during the review. For the full evidence-first pattern applied to clinical QC, see the Evidence Room.
Start with one package, one workflow
Every package enters through the same door: a free 30-minute fit call, then a Validated Automation Review of the one workflow you pick, two to four weeks, fixed scope. The review's plan is yours whether or not a build follows.
1
Fit call. One workflow, your platform, the review path. We say plainly when automation does not fit.
