Part11 Assessor

Use this skill when:

• the user asks to assess, review, or evaluate a system against 21 CFR Part 11
• the part11-foundation repository is available directly or through a separate checkout

Prerequisites

Before starting, you need:

• a target system to assess
• enough repo-local evidence to begin answering the triage questions
• a resolvable part11-foundation repository

If the target system or foundation root cannot be identified, stop and ask for the missing path. Otherwise inspect the target repo first and ask follow-up questions only if the assessment is still blocked.

Locate the foundation repo

Resolve the foundation root before reading any core/ files.

Resolution order (implemented in scripts/resolve-foundation-root.sh):

1. PART11_FOUNDATION_ROOT environment variable (fail closed if set but invalid)
2. Cross-tool config file: ${XDG_CONFIG_HOME:-$HOME/.config}/part11-assessor/config (single line, absolute path)
3. Well-known path: $HOME/github/part11-foundation
4. Current working directory if it is the foundation repo
5. Sibling of the target repo root (walk up to .git, check sibling)
6. Sibling of cwd (fallback if not inside a git repo)

Run scripts/resolve-foundation-root.sh from this skill package. Once resolved, treat that absolute path as FOUNDATION_ROOT and read all referenced files from there.

Workflow

Before triage, explore the target repo directly. Use code, docs, infrastructure config, tests, and any in-repo architecture or procedural material as assessment evidence.

Ask follow-up questions only when a required decision cannot be derived from the reviewed corpus and the assessment would otherwise be blocked.

Step 0 — Applicability triage

Read FOUNDATION_ROOT/core/applicability/triage.yaml.

Answer:

1. What predicate rules require the records at issue?
2. Are required records maintained electronically in place of paper?
3. Are electronic signatures used as equivalents of handwritten signatures?
4. Is the system open, closed, or hybrid? Use the classification guidance in FOUNDATION_ROOT/core/applicability/triage.yaml under system_classification.classification_guidance. Key rule: if any record-affecting data path crosses the boundary between the controlled environment and an uncontrolled network (including the public internet), classify as hybrid or open, not closed. A system with strong transmission controls (TLS, API keys, MDM) is still hybrid if regulated data crosses the public internet.
5. Do legacy-system considerations apply?

If Part 11 does not apply, state why and stop.

Produce a structured triage scope block conforming to FOUNDATION_ROOT/core/applicability/triage-output-template.yaml. This block must use exact enum values and the canonical node-family vocabulary. Include it in the assessment output before any findings.

Required scope fields:

• scope_confidence, record_boundary_status, predicate_rule_mapping_status — use final, provisional, or tbd
• system_of_record_status — use confirmed, provisional, tbd, or not_applicable
  • provisional: some evidence exists but the decision is not finalized
  • tbd: no sufficient evidence to name the mapping or decision. tbd is weaker than provisional. When a tbd field drives applicability, prefer Not assessed over Partial unless the technical control is clearly present regardless of how the open decision is resolved.
• evidence_basis — use repo-only, repo-plus-external-evidence, or repo-plus-runtime-or-interviews
• system_classification — use "closed", "open", or "hybrid"
• electronic_records_in_scope, electronic_signatures_in_scope, legacy_system — use "yes", "no", or "tbd"
• in_scope_node_families, excluded_node_families — use only canonical family IDs

Record-boundary language rule: When record_boundary_status is provisional or tbd, do not use definitive record-boundary language. Do not write "X is the electronic record" or "Y is the system of record." Use conditional phrasing such as "X appears to serve as the electronic record, pending final record-boundary determination."

Step 1 — Identify predicate rules

Read FOUNDATION_ROOT/core/predicate-rule-index/index.yaml.

Identify the predicate-rule families that create the underlying obligations. Part 11 is an overlay, not a replacement.

Step 2 — Select in-scope nodes

Read FOUNDATION_ROOT/core/index/node-inventory.yaml.

Node selection must derive from in_scope_node_families and excluded_node_families in the triage output, not only from prose reasoning.

• closed system: include relevant §11.10 child nodes; exclude 11.30
• open or hybrid system: include relevant §11.10 and 11.30 nodes
• electronic signatures in scope: include relevant subpart_c nodes
• no electronic signatures: exclude subpart_c
• scoping nodes (§11.1), implementation nodes (§11.2), and definition nodes (§11.3) are always retrievable regardless of the family lists

Filter by assessment_role: direct. Collect evidence at direct nodes unless parent context is needed.

Step 3 — Explore the target system

Consult FOUNDATION_ROOT/core/checklists/control-family-evidence-map.yaml while exploring the target repo, infrastructure, and documentation.

For each in-scope control family, use the evidence map to know what to look for:

• look_for_in_code — source code patterns and logic
• look_for_in_infrastructure — IaC, cloud config, network architecture
• look_for_in_docs — procedures, policies, and operational documentation
• look_for_in_external_evidence — governance artifacts outside the codebase
• common_false_positives — patterns that look like compliance evidence but are not

Step 4 — Check FDA guidance

Read FOUNDATION_ROOT/core/guidance/scope-and-application-2003.yaml.

Before flagging a gap, check whether the node is subject to enforcement discretion. Do not label an enforcement-discretion node as straightforward noncompliance without noting the guidance position and remaining predicate-rule expectations.

Assessment depth by enforcement status:

• Enforcement-discretion nodes (§11.10(a), §11.10(b), §11.10(c), §11.10(e), §11.10(k)(2), §11.30 counterparts): lighter treatment. Note guidance position, check predicate-rule expectations, brief observation. Move on unless a clear non-discretionary issue is evidenced.
• Actively enforced nodes (§11.10(d), §11.10(f)-(j), §11.10(k)(1), §11.50, §11.70, §11.100, §11.200, §11.300): deeper review across implementation, procedures, and retained evidence.

Step 5 — Assess each in-scope node

For each in-scope direct node, read the corresponding YAML file under FOUNDATION_ROOT/core/regulations/.

For each node:

1. use authoritative_text as the binding requirement
2. use fda_guidance.summary for enforcement-discretion context
3. use repo_interpretation.review_questions and common_gaps to structure the review
4. compare the requirement against system design, configuration, procedures, and evidence

Apply the rating rubric from FOUNDATION_ROOT/core/checklists/rating-rubric.yaml:

• Adequate — both implemented controls and approved/controlled procedural evidence present. Forbidden if unresolved scope dependencies affect the node. Forbidden for governance-heavy families (11.10.a, 11.10.d_g_h, 11.10.i_k1, subpart_c) when evidence is repo-only and documentation is draft-only or approval records are absent.
• Partial — technical controls exist but approved SOP/governance evidence is missing, draft-only, incomplete, or externally assumed.
• Gap — required control is absent or materially insufficient within an established in-scope boundary.
• Not assessed — needed evidence is organizational, runtime, interview-based, or otherwise outside the reviewed corpus.
• Not applicable — triage excludes the node or node family.
• Enforcement discretion — node materially narrowed by 2003 guidance. Note guidance position and predicate-rule expectations. Do not upgrade to Adequate based only on strong technical posture. Default severity is Observation. Override to a higher severity only when a clear predicate-rule gap is independently evidenced in the reviewed corpus — not merely inferred. When overriding, state the specific predicate-rule obligation that justifies the higher severity.

tbd vs provisional downstream effects:

• When a tbd field is the primary driver of whether a node is in scope, prefer Not assessed over Partial unless the technical control is clearly present regardless of how the open decision is resolved.
• When a provisional field affects a node, Partial is appropriate where technical controls exist. Adequate remains blocked.

External dependencies:

• When a critical control depends on an external managed service (vendor API, MDM, cloud provider service) that cannot be assessed from the reviewed corpus, rate the node Partial and note the external dependency explicitly. Do not rate Adequate based on the assumption that the external service is adequate. Do not rate Not assessed if the repo-side controls are clearly present — the external dependency is a gap in evidence, not a gap in the control.

Keep missing evidence separate from actual design or control gaps.

Step 6 — Produce the assessment

Use:

• FOUNDATION_ROOT/docs/assessment-output-template.md
• Worked examples for reference:
  • FOUNDATION_ROOT/docs/example-assessment.md — use when assessing a mature system with governed evidence and clear record-of-record status
  • FOUNDATION_ROOT/docs/example-assessment-supporting-pipeline.md — use when assessing a supporting pipeline with provisional scope, repo-only evidence, or incomplete governance

Every output must:

• begin and end with: This is a draft assessment for human QA/regulatory review. It is not a compliance determination.
• include the triage scope block immediately after the disclaimer
• include the new header fields: evidence basis, scope confidence, record boundary status, system-of-record status, predicate-rule mapping status, unresolved scope dependencies
• cite the specific core/regulations/*.yaml source files used
• distinguish authoritative text, FDA guidance, repo interpretation, missing evidence, and observed gaps
• note predicate-rule dependencies
• include a detailed finding section for every row in the findings summary that is not Adequate or Not applicable. Do not skip any. Every Partial, Gap, Not assessed, and Enforcement discretion finding must have its own detailed section with authoritative text, FDA guidance position, observation, gap or concern, recommendation, evidence needed, and predicate-rule dependency.

Step 7 — Self-review

Run FOUNDATION_ROOT/core/checklists/assessment-self-review.md before finalizing output.

If any check fails, go back and correct the affected findings.

Output rules

• never claim compliance from absence of evidence
• never claim Part 11 is self-contained
• never treat framework nodes as standalone evidence-bearing obligations
• never convert provisional scope into a final claim
• never rate governance-heavy families Adequate on repo-only draft evidence
• use severity levels: Critical, Major, Minor, Observation
• if scope confidence is provisional or tbd, say so before any node conclusions
• if evidence basis is repo-only, Adequate is limited to controls fully supported by repo evidence including approved procedural documentation
• if signatures are out of scope, state what external system/process handles approvals when known; otherwise mark that dependency unresolved

When information is insufficient

If the available information is not enough to answer a triage question or assess a node:

• do not guess
• mark the node Not assessed
• state what information is needed
• continue only on nodes that can be assessed

Multi-repo systems

When the target system spans multiple repositories:

• Treat them as one integrated system unless evidence clearly shows they should be scoped separately.
• Identify which repository owns each control: record storage, access control, audit trails, processing, client-side enforcement.
• Note cross-repo dependencies (e.g., the client repo depends on the backend repo for record storage and audit).
• Assess cross-repo release synchronization. If no version-locking or coordinated release process exists, note that as a gap in documentation change control (11.10(k)(2)).
• In the triage summary, describe the repo roles and the data flow between them.
• In findings, cite the specific repo and file path where evidence was found or was expected.

Cross-repo note

This skill is not self-contained.

It depends on a separate accessible part11-foundation checkout. Prefer PART11_FOUNDATION_ROOT when the target system is in another repository.