sentrik Tool Qualification Report¶

Document ID: sentrik-TQR-001 Revision: 1.0 Date: 2026-03-20 Classification: Quality Management System Document

Document Control¶

Field	Value
Tool Name	sentrik
Tool Version	1.1.0
Vendor	Sentrik (https://sentrik.dev)
Document Author	Sentrik Engineering
Approval Status	Released

Revision History¶

Rev	Date	Author	Description
1.0	2026-03-20	Sentrik Engineering	Initial release

1. Tool Identification¶

1.1 General Information¶

Attribute	Value
Tool Name	sentrik
Version	1.1.0
Vendor	Sentrik (sentrik.dev)
Distribution	PyPI (`sentrik`), npm (`sentrik`), Docker (`maxgerhardson/sentrik`), standalone binary
License	Proprietary (EULA)

1.2 Purpose¶

sentrik is a governance runtime for software development teams building safety-critical and regulated products. Its purpose is to:

Enforce coding standards through static pattern matching (regex), abstract syntax tree (AST) analysis, and structural file policy checks against configurable rule sets mapped to regulatory standards.
Perform regulatory compliance scanning against pre-built standards packs (IEC 62304, OWASP Top 10, SOC 2, HIPAA, PCI DSS, ISO 27001) and custom organizational rules.
Provide requirement-to-code traceability by linking source files to requirements and detecting requirement drift.
Gate CI/CD pipelines by evaluating scan results against configurable severity thresholds and returning deterministic pass/fail exit codes.
Generate compliance evidence in machine-readable formats (SARIF, JUnit XML, HTML, CSV) suitable for audit review.
Maintain audit trails of all governance decisions, scan results, and gate outcomes.

1.3 Tool Category (ISO 26262)¶

Tool Impact (TI): TI 2 — sentrik can fail to detect an error or non-compliance in the software under development, but it cannot introduce errors into the software product itself. sentrik operates in a read-only capacity on source code; it does not modify, compile, or link any artifact that becomes part of the deliverable software.

Note: The optional auto-patch feature can suggest code modifications, but these are explicitly staged as proposals requiring human review and are not applied without developer confirmation. Auto-patching is excluded from the qualification scope.

1.4 Tool Confidence Level (IEC 62304)¶

Confidence Level 2 — The output of sentrik (scan findings, gate pass/fail decisions, compliance reports) is verified by subsequent activities in the software development lifecycle:

Gate enforcement prevents merge of non-compliant code (fail-safe behavior).
Human review of findings is required by governance policy before acceptance.
Audit trail provides a permanent record of all tool decisions for independent verification.
Compliance reports are reviewed by quality assurance personnel during formal audits.

2. Tool Classification¶

2.1 Classification per IEC 62304 Section 8.1.2¶

IEC 62304:2006+AMD1:2015, Section 8.1 requires that software tools used in the development of medical device software be validated for their intended use when the output of the tool is not independently verified.

sentrik falls into the class of tools whose output could contain undetected errors (i.e., false negatives — a compliance violation that the tool fails to flag). This classification triggers the requirement for tool validation as described in Section 8.1.2.

However, because sentrik's output is:

Verified by subsequent V&V activities (code review, integration testing, system testing),
Supplemented by manual compliance checks during design reviews, and
Recorded in an audit trail for independent review,

the tool is classified at Confidence Level 2, meaning that validation evidence must demonstrate fitness for purpose but exhaustive proof of correctness is not required.

2.2 Classification per ISO 26262 Part 8 Section 11.4.6¶

ISO 26262:2018, Part 8, Section 11 defines a classification method based on two dimensions:

Tool Impact (TI):

Level	Definition	sentrik
TI 1	Tool cannot introduce or fail to detect errors	No
TI 2	Tool can fail to detect errors but cannot introduce errors	Yes

sentrik is classified as TI 2 because a false negative (missed finding) could result in non-compliant code proceeding through the pipeline. However, sentrik never modifies compiled artifacts, linker configurations, or any deliverable component of the target software.

Tool Error Detection (TD):

Level	Definition	sentrik
TD 1	High degree of confidence that a tool malfunction will be detected	No
TD 2	Medium degree of confidence that a tool malfunction will be detected	Yes
TD 3	Low degree of confidence that a tool malfunction will be detected	No

sentrik is classified as TD 2 because:

Gate failures produce exit code 1 (observable in CI/CD).
Scan results are captured in structured reports reviewed by developers and quality personnel.
The audit trail records all tool decisions.
However, a silent false negative (the tool simply not flagging a violation) would not be automatically detected without independent code review.

Tool Confidence Level (TCL) Determination:

Per ISO 26262 Part 8, Table 4:

TI \ TD	TD 1	TD 2	TD 3
TI 1	TCL 1	TCL 1	TCL 1
TI 2	TCL 1	TCL 2	TCL 3

Result: TCL 2 — Qualification is required. Methods 1 and/or 2 (see Section 3) are sufficient for TCL 2 qualification.

3. Tool Qualification Methods¶

ISO 26262 Part 8, Section 11.4.7 defines four qualification methods. The following methods are applied to sentrik:

3.1 Method 1: Increased Confidence from Use¶

Applicability: Sufficient for TCL 2 qualification.

Evidence of operational reliability:

sentrik has been in continuous development and use since its initial release, with iterative refinement across 26+ development phases.
The tool has been exercised against real-world codebases including medical device software, fintech applications, and SaaS platforms.
The automated test suite (2,100+ tests) is executed on every code change, providing continuous regression verification.
The tool has been used in CI/CD pipelines (GitHub Actions, Azure Pipelines) processing thousands of scan cycles during development and validation.

3.2 Method 2: Evaluation of the Tool Development Process¶

Applicability: Sufficient for TCL 2 qualification.

The sentrik development process includes:

Version control: All source code is maintained under Git with full commit history and traceability.
Automated testing: 2,100+ unit and integration tests with an 80% minimum coverage threshold enforced by CI/CD.
Continuous integration: Every commit is validated against the full test suite before merge.
Code review: All changes are reviewed before integration into the main branch.
Release process: Automated release pipeline (GitHub Actions) builds, tests, packages, and publishes artifacts. No release is issued without a passing test suite.
Defect tracking: Issues are tracked in the project management system with full lifecycle visibility.

3.3 Method 3: Validation of the Tool¶

Applicability: Provides additional confidence beyond TCL 2 requirements.

Validation testing has been performed to confirm correct operation:

Known-defect detection: Test cases inject known coding violations (e.g., eval() usage, hardcoded secrets, missing documentation, prohibited imports) and verify that sentrik correctly identifies them with the expected severity, rule ID, and file location.
Standard clause mapping: Each rule in every standards pack is verified to map to a specific regulatory clause (e.g., rule IEC62304-5.5.5-CPP maps to IEC 62304 Section 5.5.5).
Gate behavior: Test cases verify that the gate correctly returns exit code 0 (pass) or exit code 1 (fail) based on configurable severity thresholds.
Report generation: Test cases verify that output reports (SARIF, JUnit, HTML, CSV) contain the expected structure and content.
Determinism: Repeated scans of identical input produce identical output, confirmed by automated regression tests.

3.4 Method 4: Development in Accordance with a Safety Standard¶

Applicability: Not applied. Method 4 requires development per a recognized safety standard (e.g., IEC 61508 Part 3). This method is not required for TCL 2 and has not been applied to sentrik's own development process.

4. Validation Evidence¶

4.1 Test Suite¶

Metric	Value
Total automated tests	2,100+
Test framework	pytest
Minimum coverage	80% (enforced by CI/CD)
Test execution frequency	Every commit, every pull request, every release

Test coverage includes:

All rule types: regex, ast, file_policy, required_pattern, documentation_obligation, requirement_verification
All six standards packs (IEC 62304, OWASP Top 10, SOC 2, HIPAA, PCI DSS, ISO 27001)
All CLI commands (scan, gate, init, reconcile, compliance-report, verify-reqs, trace, etc.)
All output formats (SARIF, JUnit XML, HTML, CSV)
Configuration loading, validation, and migration
License enforcement and governance policy evaluation
DevOps provider integration (Azure DevOps, GitHub, Jira)
Edge cases: empty files, binary files, malformed input, missing configuration

4.2 Deterministic Operation¶

sentrik's core analysis is deterministic. Given identical inputs (source code, rule set, configuration), the tool produces identical outputs (findings list, severity assignments, gate decision). This property is guaranteed by the following design:

Regex rules: Pattern matching against file contents is inherently deterministic.
AST rules: Python abstract syntax tree analysis is parsed deterministically by the standard library ast module.
File policy rules: Structural checks (line counts, docstring presence, import verification) operate on deterministic file properties.
Required pattern rules: Absence detection is deterministic.
Severity assignment: Severity is assigned by the rule definition, not by probabilistic analysis. The optional heuristic rescorer uses a deterministic weighted formula (not machine learning).
Gate decision: Pass/fail is computed by comparing finding severities against a configured threshold list. No randomness is involved.

Non-deterministic features (LLM-powered confidence rescoring) are:

Disabled by default.
Opt-in only (requires explicit configuration).
Excluded from the qualification scope.
Clearly identified in output when active (deterministic=False flag on affected findings).

4.3 Known Limitations¶

The following limitations are documented and must be considered when using sentrik as part of a verification and validation strategy:

False positives from regex matching in non-executable contexts. Regex rules may match patterns appearing in comments, string literals, or documentation. This is mitigated by the confidence scoring system, which assigns reduced confidence (0.4-0.7) to matches in these contexts. Suppression rules allow teams to dismiss confirmed false positives with documented rationale.
No data flow analysis. sentrik does not perform inter-procedural data flow analysis, taint tracking, or symbolic execution. It cannot detect vulnerabilities that require understanding how data propagates through the program (e.g., SQL injection via an indirect variable). Teams requiring data flow analysis should supplement sentrik with dedicated SAST tools.
No binary or compiled code analysis. sentrik operates exclusively on source code. It does not analyze compiled binaries, intermediate representations, or linked executables.
Language-specific AST analysis limited to Python. The built-in AST checks (complexity analysis, mutable defaults, nested functions, etc.) operate on Python source files only. Other languages are covered by regex rules and file policy checks.
SBOM vulnerability scanning depends on external databases. The SBOM scanning feature queries the OSV.dev vulnerability database. Completeness and accuracy depend on the external database's coverage. Network availability is required.
LLM-powered features are non-deterministic. When enabled, LLM confidence rescoring introduces non-deterministic behavior. These features are excluded from the qualification scope and must not be relied upon for safety-critical decisions.

4.4 Version Control and Traceability¶

All source code is maintained in a Git repository with full commit history.
Every rule in every standards pack includes a standard_ref field mapping to a specific regulatory clause (e.g., IEC 62304 §5.5.5, OWASP A03:2021, SOC2 CC6.1).
The audit trail (out/agent_audit.jsonl) records every scan, gate decision, and governance action with timestamps, user identity, and decision rationale.
Compliance reports include rule-to-standard traceability for each finding.

4.5 Fail-Safe Behavior¶

sentrik is designed to fail safely:

If the scan encounters an error (invalid configuration, file read failure, internal exception), it exits with code 1 (gate failure). The default behavior is to block, not to pass silently.
If no standards or rules are configured, the tool reports the configuration issue and does not produce a false "all clear" result.
If the gate threshold configuration is invalid, the gate fails closed.

5. Operating Environment¶

5.1 Supported Platforms¶

Component	Requirement
Python	3.11 or later
Operating System	Windows 10/11, macOS 12+, Linux (Ubuntu 20.04+, RHEL 8+)
Architecture	x86_64, ARM64 (Apple Silicon)

5.2 Dependencies¶

Core scanning (no external dependencies beyond Python standard library):

Regex analysis: Python re module (standard library)
AST analysis: Python ast module (standard library)
File I/O: Python pathlib, os modules (standard library)

Runtime dependencies (installed via pip):

typer — CLI framework
fastapi + uvicorn — REST API server
pyyaml — YAML configuration parsing
httpx — HTTP client for DevOps provider APIs
rich — Terminal output formatting

Optional dependencies (not required for core scanning):

clang-tidy, cppcheck — deeper C/C++ analysis (external tools, not bundled)
LLM provider API keys — confidence rescoring (non-deterministic, excluded from qualification scope)

5.3 Deployment Modes¶

sentrik supports the following deployment configurations, all producing equivalent scan results:

CLI on developer workstation — sentrik scan, sentrik gate
CI/CD pipeline step — GitHub Actions, Azure Pipelines, GitLab CI, Jenkins
Pre-commit hook — sentrik scan --staged
Docker container — docker.io/maxgerhardson/sentrik
REST API server — sentrik dashboard with dashboard and programmatic access
VS Code / Cursor extension — in-editor diagnostics with scan-on-save

6. Intended Use¶

6.1 Primary Use Cases¶

sentrik is intended for use as a supplementary verification tool within a software development lifecycle governed by a quality management system. Specific intended uses include:

Automated compliance scanning — Continuous verification of source code against regulatory coding standards (IEC 62304, OWASP Top 10, SOC 2, HIPAA, PCI DSS, ISO 27001) during development.
CI/CD gate enforcement — Blocking non-compliant code from being merged into protected branches by returning a deterministic pass/fail result based on configurable severity thresholds.
Pre-commit verification — Scanning staged changes before commit to provide early feedback to developers.
Compliance evidence generation — Producing structured reports (SARIF, JUnit XML, HTML) documenting scan results for audit review and regulatory submissions.
Requirement traceability — Mapping source files to requirements and detecting requirement drift.
Audit trail maintenance — Recording all governance decisions, scan outcomes, and gate results for retrospective analysis.

6.2 Scope Limitations¶

sentrik is NOT intended to serve as:

The sole verification method for safety-critical software. It must be used as part of a broader verification and validation (V&V) strategy that includes code review, unit testing, integration testing, system testing, and formal design reviews.
A replacement for human judgment in safety-critical decisions. All critical findings should be reviewed by qualified personnel.
A formal methods tool. sentrik does not perform mathematical proof of correctness, model checking, or exhaustive state-space exploration.
A compiler or build tool. sentrik does not participate in the compilation, linking, or deployment of the software product.

7. Residual Risk Assessment¶

7.1 False Positive Risk¶

Aspect	Assessment
Risk	sentrik may flag compliant code as non-compliant (false positive).
Impact	Developer time spent investigating non-issues. No safety impact (false positives do not mask real defects).
Probability	Medium — regex rules can match patterns in comments, strings, and documentation.
Mitigation	Confidence scoring assigns reduced confidence to matches in non-executable contexts. Suppression rules allow documented dismissal of confirmed false positives. Rule-specific `exclude_patterns` configuration.
Residual	Low — manageable through configuration and team workflow.

7.2 False Negative Risk¶

Aspect	Assessment
Risk	sentrik may fail to detect a genuine compliance violation (false negative).
Impact	Non-compliant code may proceed through the pipeline undetected by this tool.
Probability	Medium — regex pattern matching has inherent coverage limits; no data flow analysis is performed.
Mitigation	Multi-standard rule coverage provides overlapping detection (the same issue may be caught by rules from different frameworks). Independent code review is required by governance policy. Integration and system testing provide additional verification layers. Regular rule set updates expand detection coverage.
Residual	Medium — accepted as inherent to pattern-based static analysis. Must be compensated by other V&V activities per the quality management system.

7.3 Tool Failure Risk¶

Aspect	Assessment
Risk	sentrik may crash, hang, or produce corrupted output.
Impact	Pipeline gate may not execute, potentially allowing unverified code to proceed.
Probability	Low — extensive test coverage and fail-safe design (errors produce exit code 1).
Mitigation	Fail-safe behavior: any unhandled exception causes exit code 1 (gate failure). CI/CD pipelines treat non-zero exit codes as step failures. Scan metrics and audit logs provide observability into tool operation.
Residual	Low — fail-safe design ensures failures block rather than pass.

7.4 Configuration Error Risk¶

Aspect	Assessment
Risk	Misconfiguration may disable rules, reduce gate strictness, or exclude critical files from scanning.
Impact	Reduced detection coverage without visible indication.
Probability	Low — configuration validation (`sentrik validate-config`) detects common errors.
Mitigation	`sentrik validate-config` command verifies configuration integrity. Governance profiles provide pre-validated configurations (strict, standard, permissive). Configuration is version-controlled alongside source code. Configuration changes are visible in code review.
Residual	Low — manageable through process controls and configuration review.

8. Qualification Maintenance¶

8.1 Re-Qualification Triggers¶

Re-qualification of sentrik is required when any of the following changes occur:

Change Type	Re-Qualification Required
Major version change (e.g., 1.x to 2.x)	Yes — full re-qualification
Change to rule matching logic (regex engine, AST parser)	Yes — targeted re-qualification of affected rule types
Introduction of new analysis techniques	Yes — qualification of new technique
Change to gate decision logic	Yes — targeted re-qualification
Change to report output format	Yes — if report format is cited in regulatory submissions
New standards pack added	No — new packs do not affect existing rule behavior
New rules added to existing packs	No — additive changes do not affect existing behavior
Bug fixes that do not change detection logic	No
UI/dashboard changes	No
Minor version updates (e.g., 1.1 to 1.2)	No — unless detection logic is modified

8.2 Ongoing Validation¶

The automated test suite (2,100+ tests) is executed on every code change and must pass before any release.
Regression tests verify that previously detected findings continue to be detected after updates.
Release notes document all changes and identify any that affect detection behavior.

8.3 Version Tracking¶

Each project using sentrik for qualified purposes must record:

The exact sentrik version in use (obtainable via sentrik version).
The standards packs and versions enabled.
Any custom rules added to the configuration.
The governance profile and gate thresholds configured.
The deployment mode (CLI, CI/CD, Docker, etc.).

9. References¶

Standard / Document	Relevance
IEC 62304:2006+AMD1:2015, Section 8.1	Software development tools — validation requirements
ISO 26262:2018, Part 8, Section 11	Qualification of software tools
IEC 61508:2010, Part 3, Section 7.4.4	Software tool qualification (general functional safety)
FDA Guidance: "Off-The-Shelf Software Use in Medical Devices" (2019)	FDA expectations for software tools in medical device development
ISO 14971:2019	Application of risk management to medical devices (referenced for residual risk methodology)
ISO 13485:2016, Section 7.5.6	Validation of processes for production and service provision (QMS context)
DO-330: Software Tool Qualification Considerations	Aerospace tool qualification framework (informative reference for cross-domain alignment)

Appendix A: Standards Pack Rule Mapping Summary¶

Standards Pack	Standard Reference	Number of Rules	Rule Types
fda-iec-62304	IEC 62304 / 21 CFR Part 11	14	regex, ast, file_policy, required_pattern
owasp-top-10	OWASP Top 10 2021	22	regex, file_policy
soc2	SOC 2 Trust Services Criteria	16	regex, file_policy, required_pattern
hipaa	HIPAA 45 CFR Part 164	15	regex, file_policy, required_pattern
pci-dss	PCI DSS v4.0	16	regex, file_policy, required_pattern
iso-27001	ISO/IEC 27001:2022 Annex A	14	regex, file_policy, required_pattern

Appendix B: Analysis Technique Summary¶

Technique	Deterministic	Qualified	Description
Regex pattern matching	Yes	Yes	Pattern-based detection of prohibited constructs
AST analysis (Python)	Yes	Yes	Structural analysis of Python syntax trees
File policy checks	Yes	Yes	Structural validation of file properties
Required pattern checks	Yes	Yes	Detection of absent required patterns
Heuristic rescoring	Yes	Yes	Deterministic weighted-formula severity adjustment
LLM confidence scoring	No	No	Non-deterministic, opt-in, excluded from scope
Auto-patching	No	No	Requires human review, excluded from scope
SBOM/OSV scanning	Yes*	No	Depends on external database; excluded from scope

* Deterministic for a given database state, but database contents change over time.

End of Document