UIAO SCuBA Compliance Pipeline — Technical Specification
Deterministic four-plane processing chain for SCuBA compliance
UIAO Governance OS
SCuBA Compliance Pipeline
Technical Specification Document
| Document Title | UIAO SCuBA Compliance Pipeline — Technical Specification |
| Version | 1.0 |
| Date | April 13, 2026 |
| Author | Michael Stratton |
| Classification | UIAO Canon — Public Release |
| Compliance | GCC-Moderate Only |
| NHP Mode | ENABLED |
| Repository | uiao-core |
No-Hallucination Protocol: All content traced to source artifacts.
!A 16:9 muted-blue schematic showing the 4-plane SCuBA compliance pipeline…
Table of Contents
1. Executive Summary
This document specifies the UIAO SCuBA Compliance Pipeline, a deterministic four-plane processing chain that transforms raw CISA ScubaGear assessment output into FedRAMP-aligned OSCAL artifacts. The pipeline operates within the GCC-Moderate boundary exclusively, serving the UIAO Governance OS mission of certificate-anchored, single-source-of-truth compliance automation.
The pipeline ingests Invoke-SCuBA output from Microsoft 365 GCC-Moderate tenants, normalizes raw policy test results through a three-hop mapping chain (ScubaGear PolicyId to NIST SP 800-53 control to UIAO Key Security Indicator), and produces immutable evidence bundles with SHA-256 provenance hashing. Terminal artifacts include OSCAL Component Definitions, Plans of Action and Milestones, and System Security Plan fragments suitable for FedRAMP Moderate authorization packages.
All processing is deterministic: identical input produces identical output. No external API calls are made during pipeline execution. The orchestrator provides sequential plane chaining with per-plane retry logic, exponential backoff, timestamped run isolation, and a machine-readable run manifest for auditability.
2. Context and Problem Statement
2.1 The Problem
Federal agencies operating Microsoft 365 in GCC-Moderate environments must continuously demonstrate compliance with NIST SP 800-53 controls and maintain FedRAMP authorization. CISA provides the ScubaGear tool to assess M365 tenant configurations against Secure Cloud Business Applications baselines, but ScubaGear output is a flat list of policy test results with no mapping to NIST controls, no KSI aggregation, and no OSCAL-compatible export format.
2.2 Why It Matters
Without automated transformation, compliance teams must manually map each ScubaGear policy result to the appropriate NIST control family, aggregate findings across multiple policies that map to the same control, determine pass/fail verdicts using consistent logic, produce evidence bundles with cryptographic integrity, and generate OSCAL artifacts for FedRAMP package submissions. This manual process is error-prone, non-deterministic, and does not scale across continuous monitoring cycles.
2.3 Who Is Affected
The primary stakeholders are Information System Security Officers responsible for FedRAMP authorization, compliance analysts who must produce evidence packages, and automation engineers who integrate SCuBA assessments into CI/CD governance pipelines. The pipeline also serves auditors who require deterministic, reproducible compliance evidence with unbroken provenance chains.
2.4 Constraints
| Constraint | Scope | Enforcement |
| GCC-Moderate Only | All M365 service references | CI-blocking unless boundary-exception: true |
| No FedRAMP High | Compliance baseline | Architecture constraint |
| No Azure IaaS/PaaS | Cloud services | GCC-Moderate covers M365 SaaS only |
| Commercial Cloud Exception | Amazon Connect only | Contact center operations |
| SSOT Immutability | All canonical artifacts | Certificate-anchored provenance |
| Object Identity Only | Identity model | No person identity in pipeline data |
3. Architecture Overview
3.1 Pipeline Boundary Model
The SCuBA Compliance Pipeline operates as a four-plane linear chain within the UIAO Governance OS boundary. Each plane has a single responsibility, a defined input contract, and a defined output contract. Data flows forward only; no plane reads from a downstream plane. The pipeline boundary is contained entirely within the SSOT perimeter, and all inter-plane data transfers are serialized to JSON with SHA-256 content hashing.
!A 16:9 muted-blue architectural diagram showing the UIAO Governance OS boundary…
3.2 Identity Model
The pipeline uses object identity exclusively. Every IR artifact (Control, Policy, Evidence) carries a deterministic identifier constructed from its source, scope, and content. Identity format follows the pattern: type:source:tenant:run:ksi_id. Certificate-anchored provenance records attach to each artifact via ProvenanceRecord objects containing source identifier, timestamp, version, SHA-256 content hash, and actor reference.
3.3 SSOT Role
The Single Source of Truth for the pipeline is the normalized SCuBA JSON envelope produced by the normalizer. Once created, this envelope is immutable for the duration of a pipeline run. All downstream planes derive their data exclusively from their immediate upstream output. The SSOT principle ensures that the KSI verdicts, evidence bundles, and OSCAL artifacts are fully traceable to the original ScubaGear assessment without information loss or mutation.
3.4 Adapter Classes
The SCuBA pipeline employs adapters that serve SSOT, Identity, and Security. The ScubaAdapter class in scuba_adapter.py implements the DatabaseAdapterBase interface with five contract phases: Connection (load report file), Schema Discovery (map ScubaGear fields to UIAO canonical schema), Query Normalization (filter by product, control, or status), Data Normalization (produce ClaimObjects from policy results), and Drift Detection (identify policy regressions against baseline).
Adapters are plural in class but singular in mission: they connect to many data sources but always serve SSOT plus Identity plus Security. The SCuBA adapter maps 104 ScubaGear policy IDs across seven M365 products to NIST SP 800-53 controls via the SCUBA_TO_KSI_MAP constant.
4. Detailed Technical Specification
4.1 Plane 0: Input Normalization
The normalizer bridges raw Invoke-SCuBA output to the pipeline-ready format expected by Plane 1. It is implemented in normalize_scuba.py within the scuba adapter package.
4.1.1 Supported Input Formats
| Format | Detection | Handling |
| Combined ScubaResults.json | TestResults key present | Extract TestResults array directly |
| Per-product files (MS.*.json) | Directory with MS.AAD.json, MS.EXO.json, etc. | Discover, load each, merge all results |
| YAML summary | Results key present | Extract Results array |
| Already-normalized | ksi_results key present | Passthrough with envelope rebuild |
| Nested directory | Subdirectories containing above formats | Recursive discovery, first match wins |
4.1.2 Three-Hop Mapping Chain
The normalizer resolves each ScubaGear policy result through a three-hop mapping chain. Hop 1 maps the ScubaGear PolicyId to a NIST SP 800-53 control identifier using the SCUBA_TO_KSI_MAP dictionary (104 entries across 7 M365 products). Hop 2 resolves the NIST control to UIAO KSI metadata using the uiao-control-to-ksi-mapping.yaml file (247 control entries). Hop 3 performs KSI-level aggregation when multiple policies map to the same KSI identifier.
4.1.3 Aggregation Logic
When multiple ScubaGear policies map to the same KSI, the normalizer applies conservative aggregation: if any constituent policy has status FAIL, the aggregated KSI status is FAIL. Otherwise, if any policy has status WARN, the aggregated KSI status is WARN. Only if all constituent policies pass does the aggregated KSI receive status PASS. Severity is resolved to the maximum across all constituent policies. Details are concatenated with source policy attribution.
4.1.4 Status Interpretation
| ScubaGear RequirementMet | Normalized Status | Pipeline Treatment |
| true / True / Pass / PASS | PASS | Evidence evaluation.passed = true |
| Warning / warning / WARN | WARN | Treated as non-passing (conservative for FedRAMP) |
| false / False / Fail / FAIL | FAIL | Evidence evaluation.failed = true |
4.1.5 Output Envelope Schema
The normalizer produces a JSON envelope conforming to the scuba-normalized schema with three top-level keys: assessment_metadata (containing run_id, assessment_date, tool_version, collector_host, collector_user, and a normalization sub-object with mapping statistics), tenant (containing tenant_id), and ksi_results (an array of objects each containing ksi_id, status, severity, details, source_policies, nist_control, and policy_count).
4.2 Plane 1: SCuBA to IR Transform
Plane 1 transforms the normalized SCuBA JSON into the UIAO Intermediate Representation. It is implemented in transformer.py as the transform_scuba_to_ir function.
4.2.1 Function Contract
| Parameter | Type | Description |
| normalized_json_path | str | Path | Path to normalized SCuBA JSON file |
| tenant_boundary_id | str | Tenant boundary identifier (default: boundary:tenant:m365:contoso) |
| Return | SCuBATransformResult | Contains controls, policies, evidence, counts, unmapped IDs |
4.2.2 Processing Steps
The transformer loads the normalized JSON and builds the full KSI-to-IR mapping by calling build_ksi_ir_mapping, which loads all 163 KSI rule YAML files from rules/ksi/ and produces Control and Policy objects for each. It constructs a ProvenanceRecord from the assessment metadata (source, timestamp, version, content hash, actor). For each entry in the ksi_results array, it creates an Evidence object with a deterministic identifier following the pattern evidence:scuba:tenant_id:run_id:ksi_id.
4.2.3 Evidence Object Structure
Each Evidence object contains: id (deterministic composite identifier), source (scuba:run_id), control_id (KSI identifier if mapped), policy_id (policy reference if mapped), timestamp (assessment date), data (ksi_id, status, severity, details, run_id, tool_version, tenant_id), evaluation (passed boolean, warning boolean, failed boolean, severity, control_mapped boolean, canonical_hash SHA-256), and provenance (ProvenanceRecord reference).
4.2.4 Output: IR JSON Envelope
The SCuBATransformResult serializes to a JSON envelope via to_dict() containing: run_id, controls (array of Control objects serialized to canonical JSON), policies (array of Policy objects), pass_count, warn_count, fail_count, unmapped_ksi_ids, and evidence (array of Evidence objects). This envelope is the input contract for Plane 2.
4.3 Plane 2: IR to KSI Evaluation
Plane 2 evaluates the IR envelope against KSI rules to produce control-level verdicts. It is implemented in evaluate.py as the evaluate_ksi function.
4.3.1 Function Contract
| Parameter | Type | Description |
| ir_path | str | Path to IR JSON envelope from Plane 1 |
| output_path | str | Path for KSI result JSON output |
| config_path | str | None | Optional path to ksi-rules.json override |
4.3.2 Verdict Logic
The evaluator loads the IR envelope, extracts the evidence array, and for each KSI control determines a verdict. The _evidence_passes helper function supports both serialization conventions: it checks evaluation.result against the string value pass, checks evaluation.passed against boolean true, and checks data.status against the string PASS. This dual-convention support ensures compatibility between the transformer (which writes evaluation.passed as boolean) and any external IR producers that use the string convention.
4.3.3 Guarantees
Plane 2 provides three guarantees: determinism (identical IR plus identical config produces identical output), isolation (no external API calls, no evidence generation, no cross-layer imports), and completeness (every control in the IR receives a verdict, even if no evidence exists for it).
4.4 Plane 3: KSI to Evidence Bundle
Plane 3 transforms KSI verdicts into immutable, hashable evidence records organized as a bundle directory. It is implemented in builder.py as the build_evidence function.
4.4.1 Function Contract
| Parameter | Type | Description |
| ksi_path | str | Path to KSI result JSON from Plane 2 |
| output_dir | str | Path for evidence bundle output directory |
| config_path | str | None | Optional path to evidence-build.json |
4.4.2 Evidence Status Mapping
| KSI Verdict | Evidence Status | Fresh Flag | Semantic Meaning |
| PASS | satisfied | true | Control requirement met with current evidence |
| FAIL | not-satisfied | true | Control requirement not met, requires remediation |
| INCONCLUSIVE | not-applicable | false | Insufficient evidence to determine compliance |
| EXCLUDED | not-applicable | false | Control explicitly excluded from scope |
4.4.3 Bundle Output Structure
The evidence bundle is a directory containing: bundle.json (manifest with run metadata, total counts, and status breakdown), evidence.jsonl (newline-delimited JSON with one EvidenceRecord per line), hashes/ (directory of SHA-256 sidecar files, one per evidence record, named ev_{KSI-ID}_ev-build.sha256), and provenance/ (directory of provenance JSON files, one per evidence record, named ev_{KSI-ID}_ev-build.provenance.json).
4.5 Plane 4: Evidence to OSCAL Artifacts
Plane 4 generates FedRAMP-aligned OSCAL artifacts from the evidence bundle. It invokes three independent generators, each producing a distinct artifact type.
4.5.1 Generator Functions
| Generator | Function | Output | Description |
| OSCAL Component Definition | build_oscal(data_dir, output_dir) | uiao-component-definition.json | OSCAL-compliant component definition mapping controls to implementations |
| Plan of Action and Milestones | build_poam_export(data_dir, output_dir) | uiao-poam.json | POA&M entries for all not-satisfied controls with remediation guidance |
| System Security Plan | build_ssp(data_dir, output_path) | ssp.json | FedRAMP Rev 5 SSP fragment with control implementation narratives |
4.5.2 Generator Error Handling
Each generator is invoked independently within a try/except block. If one generator fails, the others still execute. Generator failures are logged as warnings, not errors, allowing the pipeline to complete successfully with partial Plane 4 output. This design ensures that a defect in one generator does not block the production of other OSCAL artifacts.
5. Orchestration Layer
5.1 orchestrate() Function
The orchestrate function in orchestrator.py chains all four planes with error handling, retry logic, and run manifest tracking. It accepts input_path (Path to SCuBA input, raw or normalized), output_base_dir (base directory for timestamped run output), tenant_id (default: boundary:tenant:m365:contoso), config_dir (optional directory containing ksi-rules.json and evidence-build.json), planes (list of plane IDs to execute, default all four), dry_run (boolean for validation without side effects), and max_retries (per-plane retry count, default 1). It returns a tuple of (success boolean, RunManifest).
5.2 Auto-Normalization
When the orchestrator detects that the input file contains a TestResults key (raw ScubaGear format) or that the input path is a directory, it automatically invokes the normalize_scuba function before passing the result to Plane 1. The normalized output is written to the run directory as normalized-scuba.json, preserving the original input untouched.
5.3 Run Directory Structure
Each pipeline execution creates an isolated, timestamped run directory under the output base. The directory name follows the pattern YYYYMMDDTHHMMSSZ-run-XXXXXXXX where the suffix is a truncated UUID4. Within the run directory: ir/ contains the IR JSON envelope, ksi/ contains the KSI verdict JSON, evidence/ contains the evidence bundle directory, oscal/ contains the OSCAL artifacts, logs/ contains timestamped log files, and manifest.json contains the machine-readable run manifest.
5.4 Retry and Error Handling
Each plane supports configurable retry with exponential backoff (delay of 2^attempt seconds between retries). If a plane fails after all retry attempts, the pipeline halts and no downstream planes execute. The PlaneResult object records: plane_id, success boolean, duration in seconds, output path, error message if any, and retry count. The RunManifest aggregates all PlaneResult objects and records overall success, total duration, and a summary with counts of successful and failed planes.
!A 16:9 muted-blue sequence diagram showing the Orchestrator invoking Plane 1…
6. Implementation Guidance
6.1 Running the Pipeline
6.1.1 With Pre-Normalized Input
Execute the pipeline against a normalized SCuBA JSON file using: python scripts/run_real_scuba_dryrun.py --input scuba-real-run/ScubaResults.json --output dryrun-output --execute. The --execute flag is required for actual execution; without it, the pipeline runs in dry-run mode (validation only, no side effects).
6.1.2 With Raw ScubaGear Output
Point the pipeline directly at raw Invoke-SCuBA output: python scripts/run_real_scuba_dryrun.py --input path/to/ScubaResults-raw.json --output dryrun-output --execute. The orchestrator auto-detects the raw format and normalizes before Plane 1 execution.
6.1.3 With Per-Product Files
Point the pipeline at a directory containing individual product files: python scripts/run_real_scuba_dryrun.py --input path/to/scuba-output-dir/ --output dryrun-output --execute. The normalizer discovers and merges all MS.*.json files.
6.2 Selective Plane Execution
Execute a subset of planes using the --planes argument: python scripts/run_real_scuba_dryrun.py --input scuba-real-run/ScubaResults.json --output dryrun-output --planes plane1 plane2 --execute. This is useful for debugging individual planes or when downstream planes are not yet needed.
6.3 Standalone Normalization
Run the normalizer independently for inspection: python -m uiao_core.ir.adapters.scuba.normalize_scuba --input path/to/ScubaResults-raw.json --output normalized.json --tenant-id your-tenant-uuid --verbose. This produces the normalized JSON without invoking any pipeline planes, useful for validating the mapping chain before a full run.
7. Data Model Reference
7.1 IR Base Classes
All IR objects inherit from IRBase, a frozen Pydantic v2 model providing canonical JSON serialization (sorted keys, no None values) and SHA-256 content hashing via the canonical_hash utility function.
7.1.1 Core Model Types
| Model | Key Fields | Source Enum Values |
| Control | id, source, description, parameters, mappings | scuba, nist, fedramp, overlay, ksi, custom |
| Policy | id, control_ref, description, scope, conditions, expected_state | Derived from Control |
| Evidence | id, source, control_id, policy_id, timestamp, data, evaluation, provenance | Pipeline-generated |
| ProvenanceRecord | source, timestamp, version, content_hash, actor | Attached to all artifacts |
| Identity | Type: user, service, device, group; Provider: entra, onprem, workload, external | Object identity only |
| Resource | Type: site, mailbox, app, api, segment, other | M365 resource classification |
| Boundary | id, description, constraints | Tenant boundary scope |
7.2 ScubaGear Policy Mapping Coverage
The SCUBA_TO_KSI_MAP dictionary in scuba_adapter.py maps 104 ScubaGear policy IDs across seven M365 products to NIST SP 800-53 controls. The following table summarizes the coverage distribution.
| M365 Product | Policy Count | NIST Control Families Covered |
| Azure AD / Entra ID (MS.AAD) | 26 | IA, AC, AU, CM |
| Defender (MS.DEFENDER) | 8 | SI |
| Exchange Online (MS.EXO) | 3 | SC, SI |
| SharePoint (MS.SHAREPOINT) | 7 | AC, AU, SC, MP |
| Teams (MS.TEAMS) | 13 | AC, AU, SI |
| Power Platform (MS.POWERPLATFORM) | 9 | AC, CM |
| Power BI (MS.POWERBI) | 7 | AC, SC, MP, AU, CM, SI |
| Security Suite (MS.SECURITYSUITE) | 31 | SI, IR, CM, SC, MP, AC, IA, AU |
8. Risks and Mitigations
| Risk Category | Risk | Likelihood | Impact | Mitigation |
| Governance | SCUBA_TO_KSI_MAP becomes stale as ScubaGear adds new policies | Medium | High | Version-pinned mapping with CI drift detection against ScubaGear releases |
| Governance | KSI rule YAML files diverge from NIST SP 800-53 Rev 5 baseline | Low | High | Provenance chain linking each KSI to its canonical NIST source; automated cross-reference validation |
| Operational | Pipeline produces false-pass when ScubaGear policy is removed but KSI remains | Low | Critical | Unmapped KSI tracking in normalizer; zero-evidence controls flagged as INCONCLUSIVE, not PASS |
| Operational | Large ScubaGear output (>1000 policies) degrades performance | Low | Low | Pipeline completes 163 KSIs in 1.14 seconds; linear scaling validated |
| Security | Evidence bundle tampered between Plane 3 and Plane 4 | Low | High | SHA-256 sidecar hashes for every evidence record; provenance records with content hashes |
| Security | Pipeline input contains malformed JSON causing parse failure | Medium | Medium | Per-plane try/except with retry logic; input validation before Plane 1 |
| Drift | uiao-control-to-ksi-mapping.yaml out of sync with rules/ksi/ YAML files | Medium | Medium | CI appendix-sync gate validates index integrity; drift-scan detects cross-artifact inconsistency |
9. Appendices
Appendix A: Definitions
| Term | Definition |
| SSOT | Single Source of Truth. The singular, certificate-anchored canonical data store from which all derived artifacts trace provenance. |
| KSI | Key Security Indicator. A UIAO-defined compliance control that maps to one or more NIST SP 800-53 controls, serving as the evaluation unit in the compliance pipeline. |
| IR | Intermediate Representation. The canonical data format produced by Plane 1, containing Controls, Policies, and Evidence objects with provenance. |
| ScubaGear | CISA Secure Cloud Business Applications assessment tool. Produces policy-level test results for Microsoft 365 tenant configurations. |
| GCC-Moderate | Government Community Cloud at the Moderate impact level. The Microsoft 365 SaaS deployment authorized for CUI processing under FedRAMP Moderate. |
| OSCAL | Open Security Controls Assessment Language. NIST-defined machine-readable format for security control catalogs, profiles, and assessment results. |
| POA&M | Plan of Action and Milestones. A FedRAMP-required artifact documenting identified weaknesses and planned remediation activities. |
| SSP | System Security Plan. The primary FedRAMP authorization document describing system boundaries, control implementations, and security posture. |
| Evidence Bundle | An immutable directory of evidence records with SHA-256 sidecar hashes and provenance metadata, produced by Plane 3. |
| Normalizer | The pre-pipeline module that transforms raw ScubaGear output into the UIAO-normalized JSON format expected by Plane 1. |
| PlaneResult | A data object recording the outcome of a single plane execution: success status, duration, output path, error, and retry count. |
| RunManifest | A JSON file summarizing an orchestrator run: all PlaneResults, timing, and overall success status. |
Appendix B: Object List
| Object ID | Type | Description |
| IMAGE-01 | Image | 4-plane SCuBA compliance pipeline schematic (cover page) |
| DIAGRAM-01 | Diagram | UIAO Governance OS boundary with four sequential planes and certificate chain |
| DIAGRAM-02 | Diagram | Orchestrator sequence diagram with retry loops and auto-normalization |
| TABLE-01 | Table | Governance constraints matrix (Section 2.4) |
| TABLE-02 | Table | Supported input formats (Section 4.1.1) |
| TABLE-03 | Table | Status interpretation mapping (Section 4.1.4) |
| TABLE-04 | Table | Evidence status mapping (Section 4.4.2) |
| TABLE-05 | Table | Generator functions (Section 4.5.1) |
| TABLE-06 | Table | Core model types (Section 7.1.1) |
| TABLE-07 | Table | ScubaGear policy mapping coverage (Section 7.2) |
| TABLE-08 | Table | Risk and mitigation matrix (Section 8) |
Appendix C: Copy Section
This section is retained per UIAO governance mandate. All content in this document is derived from canonical artifacts in the uiao-core repository. Provenance traces to: src/uiao_core/ir/adapters/scuba/ (normalizer, transformer), src/uiao_core/ksi/evaluate.py (evaluator), src/uiao_core/evidence/builder.py (evidence builder), src/uiao_core/generators/ (OSCAL, POA&M, SSP), orchestrator/orchestrator.py (orchestration layer), src/uiao_core/adapters/scuba_adapter.py (policy mapping), and rules/ksi/ (KSI rule definitions).
Appendix D: References
All references are user-provided or derived from the uiao-core codebase:
REF-01: CISA ScubaGear — https://github.com/cisagov/ScubaGear
REF-02: NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
REF-03: NIST OSCAL — Open Security Controls Assessment Language specification
REF-04: FedRAMP Moderate Baseline — Security controls required for FedRAMP Moderate authorization
REF-05: uiao-core repository — Canonical governance framework source
10. Glossary
Adapter: A module that connects the UIAO Governance OS to an external data source while serving SSOT, Identity, and Security.
Boundary: A defined perimeter within which governance constraints apply. The SCuBA pipeline operates within the GCC-Moderate boundary.
Canonical Hash: A SHA-256 digest computed over the canonical JSON serialization (sorted keys, no None values) of an artifact.
Certificate-Anchored: A property indicating that an artifact's identity and provenance are bound to a cryptographic certificate chain.
Deterministic: A property guaranteeing that identical input always produces identical output, with no external state dependencies.
Evidence Record: An individual compliance finding with status (satisfied/not-satisfied/not-applicable), sidecar hash, and provenance.
Governance OS: The UIAO operating model for compliance automation, built on SSOT principles with adapter-based extensibility.
Normalization: The process of transforming vendor-specific output into a canonical format suitable for pipeline processing.
Plane: A single-responsibility processing stage in the compliance pipeline, with defined input and output contracts.
Provenance: The chain of custody metadata tracking an artifact from its source through all transformations.
11. Footnotes
[^1]: ScubaGear policy IDs follow the format MS.PRODUCT.N.Nv1, where PRODUCT identifies the M365 service and N.N identifies the specific baseline requirement.
[^2]: The 163 KSI count reflects the current rules/ksi/ directory as of April 2026. This number may change as the UIAO governance framework evolves.
[^3]: The 104 policy mapping count covers ScubaGear baseline version 0.4. Future ScubaGear releases may introduce additional policies requiring SCUBA_TO_KSI_MAP updates.
[^4]: Pipeline execution time of 1.14 seconds was measured with 163 KSIs on a local development machine. Production environments may vary.
[^5]: WARN status is treated as non-passing per FedRAMP conservative interpretation. Organizations may override this behavior via KSI rule configuration.
12. Validation Block
[VALIDATION]
All sections validated against uiao-core source artifacts.
No-Hallucination Protocol applied throughout. All technical claims trace to codebase files.
No content invented without explicit labeling. All governance constraints enforced.
GCC-Moderate boundary verified. No FedRAMP High, GCC-High, DoD, or Azure references present.
Object identity only — no person identity in pipeline data.
SSOT principle maintained: all downstream artifacts traceable to normalized SCuBA envelope.
[/VALIDATION]
Back to top