SDTM mapping proposed by a model,
checked by the standard, accepted by your programmer.
Axiom AI is the INNOVIZZ method for AI-assisted SDTM and CDISC transformation. Source metadata is mapped to the implementation guide by rules wherever a rule exists; the model proposes mappings only for the source variables no rule covers, with its reasoning attached; controlled terminology and conformance checks test every proposal; your data standards lead accepts or rejects each one. The record shows what was proposed, what changed and who accepted it.
Mapping is mostly repetition and occasionally judgment, and both get the same budget
The same EDC forms, the same sponsor standards, a new spreadsheet. Most rows are identical to the last study; the few that differ are where the errors live, and they get the same attention as the rest.
Pinnacle 21 runs after the datasets exist. A controlled terminology mismatch found in week ten costs a week of rework that would have cost an hour in week one.
A vendor tool produces datasets with no record of which mappings were rules, which were guesses and which were corrected. The reviewer guide is written from memory.
Rules map what rules can; the model proposes the rest; the standard checks; a person accepts
Source metadata from EDC, labs, ePRO and external transfers is inventoried against your sponsor standards and the SDTM implementation guide version in scope. Variables with a deterministic mapping are mapped by rule and recorded as such.
For each variable no rule covers, the model proposes a target domain, variable and derivation with its rationale and the standards references it relied on. Proposals are generated inside your environment; no source data leaves it.
Every proposal is tested against controlled terminology for the CT version in scope, the implementation guide rules and your sponsor conventions before a person sees it. Proposals that fail are returned with the failing rule.
Your data standards lead or the named programmer per domain accepts, edits or rejects each proposal in a review queue. Edits are recorded with the reason. The accepted spec is the only thing that generates code.
Transformation code is generated from the accepted spec in SAS or R, run in your environment, checked with Pinnacle 21, and documented. The reviewer guide is produced from the record, not from memory.
A mapping record that explains itself
Every row carries its origin: rule, model proposal accepted as is, model proposal edited, or manual. The inspector can see which is which.
SAS or R transformation programs produced from the accepted mapping, under your macros and versions, with the spec version in the header.
Pinnacle 21 checks run during mapping and again on the datasets. Findings are dispositioned on the record. define.xml and the reviewer guide are built from the same record.
Versions are explicit, and the record keeps them
Every engagement names the implementation guide, controlled terminology and sponsor standards versions in scope, and every proposal references them. Dataset-JSON is handled as a format the pipeline can produce; it is never presented as a requirement it is not.
Including custom domains and sponsor extensions, documented as such.
CT version pinned per study; mismatches surfaced before review, not after lock.
The review-queue approach extends to ADaM specifications where the sponsor wants it, with the same record of what was proposed and accepted.
Why a model can be allowed near a submission dataset
Because it is never allowed to decide.
Rules settle every case they can. A model is consulted only for the residual the rules cannot decide, and its output passes through the same rules before anyone sees it.
Processing runs in your environment, under your identity system. Nothing potentially unblinding reaches an outside model. The data flow diagram is available under NDA before kickoff.
Every output that matters is accepted by a person on your side whose name is on the record. Model output never writes a finding into a deliverable on its own.
Inputs, versions, tool events and decisions are logged as they happen, so the packet an auditor asks for exists before the audit does.
What you provide, what you receive, who signs
Source metadata and sample data, your sponsor standards and mapping conventions, the implementation guide and CT versions in scope, read access to the environment where the work will run.
Proposed mappings with rationale, conformance pre-checks, the accepted-mapping record, the transformation code, the datasets, the conformance report, define.xml inputs and a reviewer guide drafted from the record.
A named programmer or data standards lead per domain accepts every mapping. The record shows proposed, changed and accepted, with the reviewer named.
Before you decide
The questions that come up in the first technical conversation, answered the way we answer them on a call.
Does the model see our patient data?
The model works from metadata, sample structures and the standards. Where sample values are needed to disambiguate a mapping, they are drawn inside your environment under your controls, and potentially unblinding data never reaches an outside model. The data flow diagram is available under NDA.
What happens when the model is wrong?
The standards check catches most conformance errors before a reviewer sees the proposal; the reviewer catches the rest. A rejected proposal is recorded with its reason, and recurring rejection patterns become rules, so the residual the model handles shrinks over the engagement.
Can this run inside our existing mapping tool?
Often. The method produces a spec and code; where you already run a metadata repository or mapping platform, the accepted record can be loaded into it. The review queue is the part that is new, and it can sit alongside.
Do you support Dataset-JSON?
The pipeline can produce it alongside XPT. Whether it is required for a given submission depends on the regulator and the date; we keep a dated status note and do not present it as a mandate it is not.
How long is a first corridor?
The Validated Automation Review runs two to four weeks and ends with a build estimate. A first Axiom AI corridor on one study runs in the four phases above, each accepted before the next.
How is it priced?
Against a written statement of work with deliverables, milestones and acceptance criteria. No figure before the scope is understood.
Where this sits
The corridor that follows clean datasets: cell-level comparison of tables and listings with an audit-ready packet.
SEE CERTUSAIWhat a finished corridor looks like, on synthetic data, with the packet.
OPEN THE EVIDENCE ROOMTen services across two layers and the corridor map.
BACK TO THE CLINICAL HUBStart with the study whose mapping spec is due next.
Tell us the EDC, the standards versions and the timeline. We reply with a scoped proposal: pilot domains, review queue, acceptance criteria.
Or start with the Validated Automation Review: two to four weeks, one workflow corridor, fixed scope. The plan is yours whether or not we build it.