Chapter 2 of 8 — The Governance Profile

What does a governance profile actually say?

Before any log is intercepted, there is a profile. Think of it as a contract — written once, applied automatically to every single log line your application produces. Let's read it together, line by line, in plain English.

Step 1 of 4

A profile is attached to one application

Every application that uses CerbiStream has exactly one active profile per environment. This profile is identified by a name and a version, so the dashboard always knows which rules were in effect when a decision was made. If a rule changes, the version number changes — and old audit records still reference the version that was active at the time.

Profile Identity

Profile name

checkout-api-production

Identifies this policy document

Version

v1.0.0

Pinned in every audit record

Application

Cerbi.Demo.CheckoutApi

One profile per app

Environment

Production

Separate profiles for staging vs production

Relax Mode

Off

Off = violations enforced, not just logged

Relax Mode explained: When Relax Mode is off (as it is in Production), governance decisions are enforced — sensitive values are redacted before the log is written. When Relax Mode is on (typically in Development), violations are recorded in the dashboard but the raw value is still written, so developers can see what they are logging without data being hidden.

Step 2 of 4

Required fields — what must be in every log

Required fields are fields that must appear on every log line that goes through this profile. If a log is missing one, the runtime records a Medium violation and flags the log in the dashboard. The log is still written — governance never blocks your application — but the absence is recorded so the developer can fix it.

Required Fields — missing = Medium violation

correlationIdRequiredLinks this log line to a specific request trace. Without it, you cannot reconstruct what happened during a request.

userIdRequiredIdentifies which user performed the action. Required for user-level audit trails.

eventNameRequiredNames the business event. Required for structured log analysis and alerting.

Step 3 of 4

Disallowed fields — what must never appear

Disallowed fields are fields that must never appear in any log governed by this profile. If the runtime detects one, it immediately replaces the value with REDACTED in the governed payload — the raw value is never written anywhere. A violation is recorded in the dashboard with the field name, the rule that matched, and the severity.

Disallowed Fields — present = value redacted + violation recorded

creditCardNumberCriticalPCI-DSS prohibited. This field must never appear in any log, in any environment. If present it will be redacted and a Critical violation recorded.

passwordCriticalUser credentials must never be logged. Any presence is immediately redacted.

ssnCriticalSocial security numbers are PII under HIPAA and GDPR. Automatically redacted.

authTokenHighSession and bearer tokens grant account access. Redacted to prevent session hijacking via log exposure.

Step 4 of 4

How the profile connects to everything else

The profile is the starting point for everything in the system. The runtime loads it. The dashboard stores which profile version was active for every decision. The remediation recommendation tells the developer which profile rule they violated. The audit trail records the profile name and version so a compliance auditor can verify the exact rules in effect at any point in time.

Runtime

Loads the profile at startup. Every log is evaluated against it.

Violations

Each violation references the profile rule that was broken.

Audit Trail

Every audit record stores the profile name and version.

Chapter 3 of 8

The Unsafe Log — what goes wrong and how the runtime detects it

Continue