Finance Doctrine Conformance Scanner
Use When
Use when a system, codebase, plan, proposal, blog post, report, product specification, or implementation artefact must be tested against the Chwezi accounting and finance doctrine.
Do Not Use When
Do not use as a replacement for human accounting, audit, tax, legal, security, accessibility, or sector-specialist review. Do not treat a clean heuristic scan as proof of doctrine conformance.
Required Inputs
Target path or document, intended audience, entity type, jurisdiction, reporting framework, period, functional currency, statutory source-register snapshot where values appear, and the intended output type.
Workflow
Run the deterministic scanner where a local target exists, read the target artefacts, map findings to doctrine areas, test source discipline, produce a ranked gap register, and write alignment instructions with owners, evidence required, and acceptance checks.
Quality Standards
Traceable to doctrine, risk-ranked, source-disciplined, actionable, reviewer-routable, and explicit about unsupported claims, missing evidence, statutory uncertainty, and implementation risk.
Anti-Patterns
Only running keyword checks, ignoring proposal prose, marking client-specific statutory values as verified without source-register evidence, or giving generic advice that does not point to a doctrine skill and concrete fix.
Outputs
Conformance report, risk-ranked gap register, doctrine crosswalk, implementation instructions, evidence request list, reviewer route, and optional machine-readable scan JSON.
References
Use references/review-rubric.md, references/output-template.md, and tools/invoke-doctrine-conformance-scan.ps1.
Prerequisites
- Read
doctrine/accounting-finance-doctrine.md.
- Read
doctrine/references/policy-hierarchy.md.
- Read
doctrine/references/ledger-invariants.md.
- Read
doctrine/references/status-taxonomy.md.
- Read
references/review-rubric.md.
- Confirm the target type: codebase, system design, plan, proposal, article, or mixed artefact.
Inputs
| Artifact |
Produced by |
Required? |
Validation |
| Target artefact or path |
User |
Required |
Exists locally or content is provided in the prompt. |
| Review scope |
User or reviewer |
Required |
Names jurisdiction, framework, entity type, period, and output purpose where known. |
| Source-register snapshot |
Country-pack owner |
Required when statutory values appear |
Must be verified-current for final statutory claims. |
| Doctrine baseline |
Doctrine repo |
Required |
Uses current skills/, doctrine/references/, and source-register rules. |
| Output preference |
User |
Optional |
Markdown report by default; JSON when machine ingestion is needed. |
Outputs
| Artifact |
Consumed by |
Acceptance evidence |
| Conformance report |
Product owner, controller, implementer |
Overall state, scope, method, findings, and limits stated. |
| Gap register |
Delivery team |
Severity, doctrine reference, location, risk, fix instruction, owner, and acceptance check. |
| Doctrine crosswalk |
Reviewer |
Maps artefact areas to required doctrine skills and unresolved gaps. |
| Evidence request list |
Client or project owner |
Lists missing source documents, policies, statutory sources, contracts, reconciliations, and approvals. |
| Implementation instructions |
Engineering or proposal team |
Specific changes to workflows, data contracts, controls, reports, or prose. |
Decision Rules
- Separate code defects, process gaps, unsupported accounting claims, missing evidence, statutory uncertainty, and content-quality issues.
- Rank as critical when the artefact can create wrong ledger entries, destroy accounting evidence, bypass period locks, release unsupported statutory values, or misstate financial statements.
- Rank as high when the artefact lacks source-register support, reviewer routing, segregation of duties, control-account tie-out, related-party discipline, AI finance guardrails, or audit evidence.
- Rank as medium when the artefact is directionally sound but missing workflow completeness, documentation, exception handling, accessibility, mobile/offline resilience, or management-reporting traceability.
- For codebases, run
tools/invoke-doctrine-conformance-scan.ps1 first, then manually review the highest-risk files and any finance-domain files the scanner did not flag. Use -NoFailOnFindings when generating an advisory report where findings should not make the command fail.
- For plans, proposals, and blog posts, scan claims manually for framework selection, source discipline, statutory values, over-promising, missing caveats, and alignment with the relevant doctrine skills.
- Every recommendation must name the doctrine skill or reference it comes from and must include an acceptance check.
- If a claim cannot be traced to a real source, mark it as a gap and remove or caveat it; do not rewrite it as if it were verified.
Acceptance Evidence
references/review-rubric.md is used to classify findings.references/output-template.md is followed for the final report shape.tools/invoke-doctrine-conformance-scan.ps1 is run for local codebases or mixed repositories unless the user explicitly requests a manual-only review.- Findings cite doctrine paths and provide implementable alignment instructions.
- Statutory and factual claims are blocked unless source-register or external evidence is current and traceable.
Anti-Patterns
- Reporting "passes doctrine" when only a keyword scan was run.
- Treating marketing copy as harmless when it includes unsupported accounting, tax, ROI, or compliance claims.
- Ignoring blog posts or proposals because they are not code.
- Giving a list of risks without concrete fixes and acceptance checks.
- Failing to distinguish official doctrine requirements from reviewer judgement or inference.
Files
references/review-rubric.mdreferences/output-template.mdexamples/sample-scan-report.mdtools/invoke-doctrine-conformance-scan.ps1
Review Metadata
| Field |
Value |
| Owner role |
Doctrine owner |
| Reviewer roles |
Controller; accounting systems architect; tax reviewer where statutory values appear; security reviewer for codebases; proposal reviewer for bids and investment cases |
| Last reviewed |
2026-05-25 |
| Next review due |
2026-11-25 |
| Release state |
Active doctrine scanner facility; heuristic tool output requires human review before final conformance sign-off. |
| Caveat |
The scanner detects high-risk patterns and structures a deep review; it does not certify compliance on its own. |
Last reviewed: 2026-05-25. Next review due: 2026-11-25.
1---2name: finance-doctrine-conformance-scanner3description: Use when scanning a software system, codebase, implementation plan, proposal, policy memo, business plan, blog post, SRS, or finance/accounting product specification against the Chwezi accounting and finance doctrine. Produces a deep gap analysis, risk-ranked findings, and detailed alignment instructions tied to the doctrine skills and source-register rules.4---56# Finance Doctrine Conformance Scanner78<!-- dual-compat-start -->9## Use When1011Use when a system, codebase, plan, proposal, blog post, report, product specification, or implementation artefact must be tested against the Chwezi accounting and finance doctrine.1213## Do Not Use When1415Do not use as a replacement for human accounting, audit, tax, legal, security, accessibility, or sector-specialist review. Do not treat a clean heuristic scan as proof of doctrine conformance.1617## Required Inputs1819Target path or document, intended audience, entity type, jurisdiction, reporting framework, period, functional currency, statutory source-register snapshot where values appear, and the intended output type.2021## Workflow2223Run the deterministic scanner where a local target exists, read the target artefacts, map findings to doctrine areas, test source discipline, produce a ranked gap register, and write alignment instructions with owners, evidence required, and acceptance checks.2425## Quality Standards2627Traceable to doctrine, risk-ranked, source-disciplined, actionable, reviewer-routable, and explicit about unsupported claims, missing evidence, statutory uncertainty, and implementation risk.2829## Anti-Patterns3031Only running keyword checks, ignoring proposal prose, marking client-specific statutory values as verified without source-register evidence, or giving generic advice that does not point to a doctrine skill and concrete fix.3233## Outputs3435Conformance report, risk-ranked gap register, doctrine crosswalk, implementation instructions, evidence request list, reviewer route, and optional machine-readable scan JSON.3637## References3839Use `references/review-rubric.md`, `references/output-template.md`, and `tools/invoke-doctrine-conformance-scan.ps1`.40<!-- dual-compat-end -->4142## Prerequisites4344- Read `doctrine/accounting-finance-doctrine.md`.45- Read `doctrine/references/policy-hierarchy.md`.46- Read `doctrine/references/ledger-invariants.md`.47- Read `doctrine/references/status-taxonomy.md`.48- Read `references/review-rubric.md`.49- Confirm the target type: codebase, system design, plan, proposal, article, or mixed artefact.5051## Inputs5253| Artifact | Produced by | Required? | Validation |54|---|---|---|---|55| Target artefact or path | User | Required | Exists locally or content is provided in the prompt. |56| Review scope | User or reviewer | Required | Names jurisdiction, framework, entity type, period, and output purpose where known. |57| Source-register snapshot | Country-pack owner | Required when statutory values appear | Must be verified-current for final statutory claims. |58| Doctrine baseline | Doctrine repo | Required | Uses current `skills/`, `doctrine/references/`, and source-register rules. |59| Output preference | User | Optional | Markdown report by default; JSON when machine ingestion is needed. |6061## Outputs6263| Artifact | Consumed by | Acceptance evidence |64|---|---|---|65| Conformance report | Product owner, controller, implementer | Overall state, scope, method, findings, and limits stated. |66| Gap register | Delivery team | Severity, doctrine reference, location, risk, fix instruction, owner, and acceptance check. |67| Doctrine crosswalk | Reviewer | Maps artefact areas to required doctrine skills and unresolved gaps. |68| Evidence request list | Client or project owner | Lists missing source documents, policies, statutory sources, contracts, reconciliations, and approvals. |69| Implementation instructions | Engineering or proposal team | Specific changes to workflows, data contracts, controls, reports, or prose. |7071## Decision Rules72731. Separate code defects, process gaps, unsupported accounting claims, missing evidence, statutory uncertainty, and content-quality issues.742. Rank as critical when the artefact can create wrong ledger entries, destroy accounting evidence, bypass period locks, release unsupported statutory values, or misstate financial statements.753. Rank as high when the artefact lacks source-register support, reviewer routing, segregation of duties, control-account tie-out, related-party discipline, AI finance guardrails, or audit evidence.764. Rank as medium when the artefact is directionally sound but missing workflow completeness, documentation, exception handling, accessibility, mobile/offline resilience, or management-reporting traceability.775. For codebases, run `tools/invoke-doctrine-conformance-scan.ps1` first, then manually review the highest-risk files and any finance-domain files the scanner did not flag. Use `-NoFailOnFindings` when generating an advisory report where findings should not make the command fail.786. For plans, proposals, and blog posts, scan claims manually for framework selection, source discipline, statutory values, over-promising, missing caveats, and alignment with the relevant doctrine skills.797. Every recommendation must name the doctrine skill or reference it comes from and must include an acceptance check.808. If a claim cannot be traced to a real source, mark it as a gap and remove or caveat it; do not rewrite it as if it were verified.8182## Acceptance Evidence8384- `references/review-rubric.md` is used to classify findings.85- `references/output-template.md` is followed for the final report shape.86- `tools/invoke-doctrine-conformance-scan.ps1` is run for local codebases or mixed repositories unless the user explicitly requests a manual-only review.87- Findings cite doctrine paths and provide implementable alignment instructions.88- Statutory and factual claims are blocked unless source-register or external evidence is current and traceable.8990## Anti-Patterns9192- Reporting "passes doctrine" when only a keyword scan was run.93- Treating marketing copy as harmless when it includes unsupported accounting, tax, ROI, or compliance claims.94- Ignoring blog posts or proposals because they are not code.95- Giving a list of risks without concrete fixes and acceptance checks.96- Failing to distinguish official doctrine requirements from reviewer judgement or inference.9798## Files99100- `references/review-rubric.md`101- `references/output-template.md`102- `examples/sample-scan-report.md`103- `tools/invoke-doctrine-conformance-scan.ps1`104105## Review Metadata106107| Field | Value |108|---|---|109| Owner role | Doctrine owner |110| Reviewer roles | Controller; accounting systems architect; tax reviewer where statutory values appear; security reviewer for codebases; proposal reviewer for bids and investment cases |111| Last reviewed | 2026-05-25 |112| Next review due | 2026-11-25 |113| Release state | Active doctrine scanner facility; heuristic tool output requires human review before final conformance sign-off. |114| Caveat | The scanner detects high-risk patterns and structures a deep review; it does not certify compliance on its own. |115116Last reviewed: 2026-05-25. Next review due: 2026-11-25.
peterbamuhigire