Ch 3 — The Unsafe Log

Governance Active
Chapter 3 of 8 — The Unsafe Log

What is a violation, and how does the runtime detect one?

A violation is recorded whenever a log breaks a rule in the active governance profile. It is not an error — your application keeps running. It is a governance decision, recorded so the problem can be found, understood, and fixed at source.

1

Step 1 of 3

The log that caused these violations

The developer was building the checkout flow and added this log statement to debug a payment issue. It looks completely normal. It compiles. It runs. But it breaks three rules in the governance profile.

CheckoutService.cs — the log the developer wrote

logger.LogInformation(
    "Checkout started for {userId} paying with {creditCardNumber}",
    request.UserId,           // ✓ safe — userId is in requiredFields
    request.CreditCardNumber  // ✗ CRITICAL — in disallowedFields
);
// Missing: correlationId    // ✗ MEDIUM — required, not present
// Missing: eventName         // ✗ MEDIUM — required, not present

One Critical violation and two Medium violations. All three are detected automatically, at runtime, without any code review, linting, or CI check. The developer does not know this happened — until the dashboard shows them.

2

Step 2 of 3

The three violations — click each one to understand it

Below are the three violation records the runtime created. Click any row to expand it and see exactly what the raw value was, what governance wrote instead, why it is a violation, and how to fix it.
3

Step 3 of 3

What governance does to these violations — and what it does not do

Governance does

  • Replace the disallowed value with REDACTED before writing
  • Record each violation with field, rule, severity, and timestamp
  • Score the application based on open violations
  • Surface the violation in the dashboard for the developer to review

Governance does not do

  • Throw an exception or crash your application
  • Block the log from being written (the governed version is written)
  • Send alerts on its own — that is your alerting pipeline's job
  • Fix the code — that is the developer's job (Chapter 6 shows them how)

Chapter 4 of 8

Governance in Action — field by field, what the runtime did and why

Continue
Cerbi | Logging Governance for Your Stack