Files
guide-board/registry/capabilities/capability.communication.compliance-evidence-framework.md
tegwick 4970376155 Draft capability entry (reuse-surface REUSE-WP-0017-T04, cohort 1)
Honest first-pass maturity vector grounded in README/docs/tests present
in this repo; no invented evidence. Flagged for human review before
publish. See reuse-surface history/2026-07-06-coverage-classification.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-06 19:03:42 +02:00

121 lines
4.0 KiB
Markdown

---
id: capability.communication.compliance-evidence-framework
name: Certification And Compliance Evidence Framework
summary: Framework that turns standards, conformance, regulatory, and repository-quality claims into structured,
reviewable, repeatable, comparable evidence via a pluggable extension architecture.
owner: guide-board
status: draft
domain: communication
tags:
- compliance
- certification
- evidence
- extensions
maturity:
discovery:
current: D2
target: D4
confidence: medium
rationale: README documents the framework/extension split and a working local baseline (extensions
list/validate, profile validate-target/validate-assessment, plan, run); no separate INTENT/SCOPE
found.
availability:
current: A2
target: A3
confidence: medium
rationale: Dependency-light and runnable today via `PYTHONPATH=src python3 -m guide_board ...`; ships
sample profiles and a working plan/run pipeline.
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- extension listing/validation
- target/assessment profile validation
- plan and run pipeline with sample profiles
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- domain-specific extensions are described as living separately; core repo scope stops at contracts
discovery:
intent: Turn certification/compliance claims into structured, repeatable evidence that can be reviewed
and compared across assessments, with domain specifics delegated to extensions.
includes:
- framework contracts (targets, assessments, plans, runs)
- extension listing and validation
- sample profiles
excludes:
- domain-specific compliance extensions themselves (live in separate extension packages)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- Python package (`guide_board`), runnable via `PYTHONPATH=src`
target_artifacts: []
consumption_modes:
- cli
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
tests:
- tests/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- repos needing a structured compliance/certification evidence pipeline
not_recommended_for:
- needs where no extension exists yet for the target domain
known_limitations:
- core is intentionally dependency-light; domain coverage depends on which extensions exist
promotion_history: []
---
# Certification And Compliance Evidence Framework
## Overview
`guide-board` is a certification and compliance preparation framework. The root project owns framework contracts (targets, assessments, plans, runs); domain-specific compliance logic lives in extensions.
## Assessment notes
### Discovery
README documents the framework/extension split and a working local baseline (extensions list/validate, profile validate-target/validate-assessment, plan, run); no separate INTENT/SCOPE found.
### Availability
Dependency-light and runnable today via `PYTHONPATH=src python3 -m guide_board ...`; ships sample profiles and a working plan/run pipeline.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`