This guide gives implementers a repeatable workflow to generate one coherent assurance story using both:
Conformance answers: “Does it behave according to TRQP expectations?”
Posture answers: “Is it deployed in a way that’s resilient under realistic threats?”
In most procurement/audit contexts you need both—behavior and posture—because failures in either become exploitable system risk.
The key to a combined story is a shared build identifier.
Record this in both runs:
Do not physically merge tool outputs unless you must.
Preferred approach:
assurance/
build-<ID>/
conformance-suite/
evidence-bundle.json
reports/
tspp/
evidence-bundle.json
reports/
combined-manifest.json
Your combined manifest should be dead simple:
This hub repo will eventually host a small JSON schema for combined-manifest.json once both underlying bundle formats are stable.
This guide assumes the producer repos emit portable evidence bundles with a stable surface:
profiles/smoke.yamlbundle_descriptor.jsonchecksums.jsonbundle.zip (optional convenience package)Crosswalk: https://github.com/sankarshanmukhopadhyay/trqp-conformance-suite/blob/main/docs/hub-crosswalk.md
TSPP_REPORT_PATH=...python scripts/create_evidence_bundle.py --report <report.json> --out <bundle_dir>
Evidence output directory contains:
bundle_descriptor.jsonchecksums.jsonbundle.ziptspp_posture_report.jsonCrosswalk: https://github.com/sankarshanmukhopadhyay/TRQP-TSPP/blob/main/docs/hub-crosswalk.md
At AL3, both tools must run and their outputs must be linked in a Combined Assurance Manifest (CAM).
python cts/run.py \
--profile profiles/baseline.yaml \
--sut examples/sut.local.yaml \
--out reports/cts-run-al3
Collect: bundle_descriptor.json, checksums.json, verdicts.json.
export TRQP_BASE_URL="https://your-registry.example"
export TSPP_EXPECT_AL="AL3"
export TSPP_REPORT_PATH=./tspp_report_al3.json
pytest harness/ -q
python scripts/create_evidence_bundle.py --report tspp_report_al3.json --out reports/tspp-run-al3
Collect: bundle_descriptor.json, checksums.json, tspp_posture_report.json.
AL3 requires the following artifacts (see examples/al3-evidence-bundle/ for worked examples):
An independent assessor reviews the evidence bundle. Assessor identity MUST be recorded in the Certification Attestation (where certification is claimed).
See examples/al3-evidence-bundle/ for complete file examples.
AL4 extends AL3 with continuous monitoring requirements and operationalized revocation and renewal.
Run both tools as above. Use AL4-specific TSPP mode:
export TSPP_EXPECT_AL="AL4"
In addition to all AL3 artifacts, AL4 requires:
See examples/al4-evidence-bundle/ for complete file examples.
At AL4, assessor identity and method MUST be recorded in the Certification Attestation.
{
"assessor_id": "...",
"assessment_method": "remote-document-review",
"validity_period": { "not_before": "...", "not_after": "..." }
}
Both AL3 and AL4 share the same core evidence kinds. The following table maps AL expectations to concrete artifact paths and schema references.
| Artifact | Required at | Schema / Example |
|---|---|---|
| Combined Assurance Manifest | AL3+ | schemas/combined-assurance-manifest.schema.json |
| Control Satisfaction Declaration | AL3+ | schemas/control-satisfaction.schema.json |
| Lifecycle Assertion | AL3+ | schemas/lifecycle-assertion.schema.json |
| Remediation Closure | AL3+ (if nonconformity found) | examples/al3-evidence-bundle/remediation-closure.json |
| Certification Attestation | AL3 optional / AL4 required | schemas/certification-attestation.schema.json |
| Monitoring evidence | AL4+ | examples/al4-evidence-bundle/monitoring-evidence/ |
| Revocation Notice | AL4+ | schemas/recognition-assertion.schema.json |
examples/al3-evidence-bundle/README.mdexamples/al4-evidence-bundle/README.mddocs/guides/assurance-levels.mddocs/guides/evidence-artifacts.md