Files
james.maesandClaude Opus 5.5 e7745eb476 docs: KofTwentyTwo standards v1 policies, standards, and architecture
Original KofTwentyTwo standards written against 2026 public frameworks
(OpenSSF OSPS Baseline v2026.08.28, NIST SSDF v1.1, SLSA v1.2, Scorecard):

- policies: requirement framework (K22-<AREA>-NN, RFC 2119), SDLC,
  security program (WISP equivalent), AI-assisted development, exceptions
- standards: repository, CI/CD, testing, dependencies, releases
- architecture: Windows desktop application reference architecture
- compliance: full OSPS Baseline crosswalk (63/64 met, 1 excepted),
  SSDF, SLSA, and Scorecard mappings
- exception register (EX-0001 single maintainer, EX-0002 Windows signing)
- governance, maintainers and repository inventory, code of conduct,
  licenses (docs CC BY 4.0, code MIT)

Coding standards (Kingsrook style), IDE/CLI configs, reusable workflows,
and the conformance checker follow in separate pull requests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>
2026-10-09 07:47:10 -05:00

1.8 KiB

Exceptions

A MUST that cannot be met is never silently skipped: it is recorded as an exception, with a reason, compensating controls, and an end date. All exceptions live in one public register, exceptions/register.md, so anyone can see exactly where KofTwentyTwo falls short of its own standards and why.

Process

  1. Open a pull request against this repository that adds an entry to the register.
  2. The entry states:
    • ID: EX-NNNN, never reused;
    • Requirements: the K22-* IDs (and framework controls) not met;
    • Scope: which repositories or artifacts;
    • Reason: why the requirement cannot be met now;
    • Risk: what could go wrong because of it;
    • Compensating controls: what reduces that risk in the meantime;
    • Expires: a date or a concrete condition (at most 12 months away); and
    • Owner and review date.
  3. The pull request goes through the normal gates. The register is the approval record.
  4. Code or configuration that relies on the exception cites its ID (for example a suppression comment # K22 exception EX-0003).

Rules

  • An exception expires on its date or condition. Before it expires it is either closed (the requirement is now met) or renewed by a pull request that explains why it is still needed.
  • Expired exceptions are not deleted; their entry is marked Closed with the date and how it was resolved.
  • An exception never covers secrets in source control (K22-REPO-04), bypassing the main ruleset (K22-SDLC-12), or skipping signing or attestation of a published release once signing is available (K22-REL-04, K22-REL-05).
  • tools/Test-RepoConformance.ps1 reports a failed requirement as EXCEPTED when an open, unexpired exception covers it for that repository.