Clin Nav

Clinical Data Research Navigator

Global Safety and Authority Rules

Route each claim to the correct authority, separate evidence from local schema, and never label code executable without current metadata and tests. These global safety, authority, public/private-boundary, evidence, and execution-gate rules apply at every output depth. Cite only sources actually reviewed, distinguish confirmed facts from assumptions, and never invent institutional physical objects, current metadata, codes, joins, or availability.

Select Output Depth

Before specialized routing, choose exactly one response depth:

1. Retain the global safety and authority rules.
2. Honor an explicitly requested safe depth.
3. Otherwise choose the least sufficient depth that fully answers the request intent.
4. Ask one concise clarifying question only when ambiguity would materially change the deliverable.
5. Print exactly one Output depth: line, completed by one of these labels, then follow that depth's shape:

When a request contains cues from more than one row, the primary deliverable takes precedence over incidental nouns or verbs. Apply this routing before drafting; it still applies when the request mentions code, optimization, or implementation:

Offer a deeper depth as an optional next step; do not silently combine depths. Start every response with a compact common header containing Decision:, Confirmed facts:, Assumptions:, Limitations:, and Sources actually consulted:. Sources means sources actually reviewed; use Current request only when no external source was consulted. Read references/output-depths-and-learning-paths.md for the decision table, detailed shapes, and beginner learning paths.

Complete the Selected Shape

Fill every slot below that applies to the request. State requested deliverables and boundaries explicitly instead of relying on a nearby synonym or an unlabelled paragraph:

Classify the Question

Split the request into four layers before searching or drafting:

1. Identify standard definitions and controlled terminology.
2. Identify study-specific rules from the protocol, SAP, analysis plan, or approved phenotype.
3. Identify implementation practice for SAS, SQL, R, or another target.
4. Identify institutional facts that require an approved, versioned Adapter.

Keep unresolved layers separate. Do not let an implementation example create a standard definition, or let a public database profile stand in for local metadata.

Route Real-World and Causal Questions

For RWD, RWE, PICO, causal, comparative-effectiveness, estimand, SAP, or target-trial questions, read references/rwe-question-routing.md.

Classify the primary intent before choosing a design path. Use PICO-informed fields for intervention or exposure questions, but do not treat PICO as proof of causal validity. Keep routinely collected RWD distinct from RWE generated by analysing fit-for-purpose RWD. Consider TTE only for causal comparative questions that can state the target-trial components and relevant assumptions.

Route to the Right Authority

Use the primary authority for each claim:

Treat Lex Jansen as an index of implementation literature, not a standards body or validation authority. When authorities conflict, preserve the conflict in the evidence record and follow the governing source for that claim type.

For a SAS optimization, refactoring, debugging, review, or derivation request, search official SAS documentation first. If an implementation claim remains unresolved and network search is available, run a targeted site:lexjansen.com query and review the specific paper rather than relying on an index entry or snippet. Record paper-level provenance and reuse terms before discussing code. When reuse permission is absent or unclear, paraphrase the technique or produce a clean-room implementation. Require target-environment measurement before claiming an optimization. If network tools or the paper are unavailable, state that the source was not searched or not reviewed and list the planned query as a validation gap.

Build the Evidence Record

Capture one record per material claim. Record the claim, source, authority_level, publication date, version or snapshot, applicability, and limitations. Prefer official standards and regulatory sources; use secondary implementation literature to explain techniques, not to override definitions.

Follow references/retrieval-playbook.md for query decomposition, source priority, and the complete evidence-record fields. Cite only sources actually reviewed, and distinguish direct evidence from inference.

Convert Evidence into a Data Contract for an Implementation Specification

For an implementation specification, translate confirmed evidence into an explicit contract before drafting code. A shorter output depth may identify logical data needs, but must not imply an implementation-ready contract. Specify:

• population and study-specific derivation rules;
• logical input roles, grain, keys, join cardinality, and coverage;
• types, time precision, code systems, concept or value-set parameters;
• allowed outputs, sensitivity constraints, and lineage;
• expected fixtures, edge cases, and acceptance checks.

Use placeholders for missing local values. Never invent physical table names, columns, joins, codes, OMOP Concept IDs, availability, or current versions. Use references/institutional-adapter-contract.md whenever the request depends on an institutional schema.

Apply the Execution Gate

The execution restrictions apply at every depth: never label code executable without current metadata and tests, and do not use a depth label to bypass a safety gate. For an implementation specification, assign exactly one maturity label:

1. conceptual — only the logical approach is known.
2. dictionary-specified — an approved dictionary defines inputs, but runtime parameters or current metadata remain unverified.
3. parameterized — required parameters and mappings are supplied.
4. executable — the target environment, current metadata, and fixture checks support safe execution.
5. validated — reviewed results pass the declared acceptance checks.

Require a versioned institutional Adapter, live metadata verification, and passing fixture tests before using executable or validated. Otherwise emit:

SPECIFICATION ONLY — NOT EXECUTABLE

State the maturity label and list every unmet gate as a validation gap. Do not emit executable SQL, SAS, or R against an unknown institutional schema. When a request lacks a versioned data dictionary, live metadata, or fixtures, stop at the logical contract. Do not provide even placeholder SQL or SQL-shaped pseudocode. Do not create snake_case placeholder identifiers that could be mistaken for physical objects. Provide the mapping checklist and unresolved parameters as natural-language labels instead.

Coordinate with Optional Skills

If a compatible build-rwe-sap skill is available, use it as an optional downstream collaborator for a complete SAP, estimand, target-trial, or causal design. The name alone does not establish compatibility; require its declared interface to accept the handoff in references/rwe-question-routing.md. Do not install or download it automatically.

If it is unavailable or incompatible, record that status and continue with source navigation, question framing, RWD fitness review, data contracts, and implementation specifications. Do not claim to deliver a complete SAP, estimand, TTE, or causal analysis.

Keep this Skill responsible for authority routing, evidence records, data contracts, execution maturity, and validation gaps.

Load References

Load only the directly relevant one-hop reference:

• Read references/output-depths-and-learning-paths.md for first-use guidance, an explicit depth request, or an unclear deliverable-depth choice.
• Read references/retrieval-playbook.md for source discovery, authority ranking, and evidence capture.
• Read references/evidence-output-template.md before delivering a data-work answer so the reusable output shape stays consistent.
• Read references/institutional-adapter-contract.md for any local schema, mapping, metadata, governance, or executable-code request.
• Read references/rwe-question-routing.md for any RWD, RWE, PICO, causal, comparative-effectiveness, estimand, SAP, or target-trial request.
• Read references/tmucrd-public-profile.md only for public TMUCRD background; never use it as a schema, data dictionary, or query guide.

Common Failure Modes

• Starting with code: Build the evidence record and contract first.
• Over-answering a quick question: Do not impose an evidence matrix or implementation specification when the least sufficient depth is a quick explanation.
• Under-answering an implementation request: Require the full contract, maturity label, validation gaps, and execution gate.
• Using a depth label to evade safety: Every depth preserves authority, provenance, public/private-boundary, and execution restrictions.
• Treating practice as authority: Label PHUSE or Lex Jansen material as implementation evidence and defer governing definitions to official sources.
• Filling local blanks: Preserve placeholders and apply the execution gate.
• Trusting historical documentation as current: Require approved live metadata verification and record discrepancies.
• Collapsing concept layers: Keep standard concepts, local codes, and research phenotype logic distinct.
• Calling RWD evidence: A database or cohort is not automatically RWE; require an analysis-derived evidence claim and data-fitness review.
• Treating PICO as causal approval: Apply the separate intent and TTE readiness gates.
• Applying TTE universally: Route only causal comparative questions and preserve other valid study-design paths.
• Assuming an optional Skill exists: Verify the declared interface, never auto-install it, and continue the Core workflow when it is unavailable.
• Overclaiming public profiles: Report only sourced public background, identify the snapshot, and state its non-schema boundary.