Skip to main content

Governance artifact

Gemara Layer 6

EnforcementLog

Enforcement Log

Purpose

Prevention or remediation based on assessment findings.

Role

Enforcement records what was done after evaluation: block a merge, open a ticket, notify owners, require remediation. Methods should be those declared on policy, justified by assessment results. Without an enforcement log, denials and fixes exist only as chat noise or ephemeral CI annotations.

Examples

Merge blocked after PR #417 secret-scan failure

When the evaluation log fails data-leakage checks, enforcement blocks the pull request merge, posts a failing check run, and notifies the contributor and OSPO—citing the policy enforcement method and the failed assessment as justification.

Source: internal-tools PR #417 Enforcement Log (foss-enforcement-internal-tools-pr417), citing em-foss-block-merge.

Remediation notification, not only hard deny

Enforcement can obligate follow-up (notify, ticket, re-run) rather than only refuse. The log still records disposition, method and timing so audit can see the closed loop.

Source: em-foss-notify-noncompliance in the FOSS Contribution Policy, used alongside block-merge enforcement in the PR #417 Enforcement Log.

Anti-patterns

Enforcement without evaluation

Blocking or remediating with no cited assessment. You cannot show the action was policy-justified.

Silent CI failure

A red check that leaves no durable enforcement record. Weeks later, nobody can prove what was blocked or why.

References