sce-schema.json: controlsMap key pattern rejects all real control identifiers

$defs/controlsMap (lib/compliance_engine/sce-schema.json:52) combines a restrictive key pattern with additionalProperties: false:

"patternProperties": {
  "^\\w(?:[\\w.-]*[\\w-])?(?::\\w(?:[\\w.-]*[\\w-])?)*$": { "type": "boolean" }
},
"additionalProperties": false

The pattern allows only word characters, dots, dashes, and colons. Real control identifiers in shipped SCE data routinely contain parentheses, spaces, and pipes, so every one of them fails validation.

Impact

Validating the four Sicura enterprise modules against the shipped schema with json_schemer produces 18,543 violations, all from this one rule:

Representative failing keys:

AU-3(1)                                                   # NIST control enhancement
SC-28(1)
GRID: MS-00000001                                         # CIS
STIG ID: RHEL-08-040025 | RULE ID: SV-230498r1069314 | CAT III

Relaxing that single patternProperties entry and re-running gives zero violations in all four modules — the rest of the schema matches production data accurately. So this one pattern is the only thing standing between the schema and being usable as a validation gate.

Suggested fix

Widen the controlsMap key pattern to accept the identifier forms actually in use (at minimum parentheses, spaces, and pipes), or drop additionalProperties: false on this $def so unrecognized key shapes are permitted rather than rejected.

Whichever way it goes, it would be worth deciding explicitly whether keys like STIG ID: ... | RULE ID: ... | CAT III are intended control identifiers or a data-side smell — the schema is currently making that call implicitly, and making it in the direction that rejects everything.

Context

Found while evaluating whether scelint should consume ComplianceEngine.schema as an additional lint pass (simp/rubygem-simp-scelint#88 raised scelint's pin to compliance_engine ~> 1.0, which is what made the schema reachable). As it stands, adopting the schema at error level would bury every other finding.

Validated with json_schemer 2.5.0 against compliance_engine 1.1.0.

Inspect $defs/controlsMap at lib/compliance_engine/sce-schema.json:52 and reproduce validation with json_schemer 2.5.0 against the four shipped Sicura modules. Decide how the schema should represent the documented control identifiers, then verify the chosen change produces zero violations without weakening unrelated validation.