Policies

Policies are rules with teeth. While regular rules are guidance that Athena follows, policies include enforcement settings that can block violations, warn about them, or log them for audit.

What Is a Policy?

A policy is a rule with an enforcement level and enforcement points. For example:

Rule: “Never hardcode API keys in source files” Enforcement: Hard — block at pre-generation Why: “Prevents credential leaks in version control”

This policy is injected into every conversation. If Athena is about to generate code with a hardcoded key, the policy blocks it.

Creating Policies

From the Web UI

Go to Org Settings > Policies and click Create Policy.

The wizard walks you through four steps:

1. Choose a template — Start from a platform baseline or write a custom rule
2. Define the rule — Write the rule, explain why it exists, and note any exceptions
3. Set enforcement — Choose level, enforcement points, and enable/disable
4. Review — Add topic tags and confirm

From a Conversation

Tell Athena to create a policy:

• “Create a policy: always use TypeScript strict mode. Enforce it as a hard rule.”
• “Add a soft policy: prefer named exports over default exports.”

Athena will save the rule with the enforcement settings you specify.

From a Baseline

Quarterback ships with platform-level baseline policies covering common standards. When creating a policy in the web UI, the first step lets you browse available baselines and adopt them as org policies.

Adopted baselines are pre-filled with suggested enforcement settings. You can customize the rule, level, and enforcement points before saving.

Enforcement Levels

Level	Behavior	Use Case
Hard	Violations are blocked	Mandatory standards (no hardcoded secrets, required types)
Soft	Violations trigger a warning	Guidelines (prefer patterns, code style)
Audit	Violations are logged only	Tracking adoption (deprecation paths, migration progress)

Enforcement Points

Policies can be enforced at different stages:

Point	When	Effect
Pre-generation	Before Athena responds	Policy injected into system prompt — Athena follows it when generating code
Write gating	When saving knowledge	Prevents contradictory items from being stored

Pre-generation is the most common enforcement point. It means Athena sees the policy in every conversation and follows it when writing code or making suggestions.

Updating Policies

Policies are versioned — you don’t edit them in place. To update a policy:

1. Open the policy in the web UI
2. Click Edit
3. Modify the rule, enforcement, or topics
4. Save — this creates a new version and deprecates the old one

The old version is preserved in history with a link to the new version.

Deprecating Policies

If a policy is no longer relevant, click Deprecate in the policy detail view. Deprecated policies stop being enforced but remain visible in the policy list for reference.

Viewing Violations

Each policy’s detail page shows a violations table:

• Date — When the violation occurred
• Action — Blocked, warned, or logged
• Level — The enforcement level at the time
• Details — What triggered the violation

This helps you understand how well the policy is working and whether it needs adjustment.

Policies vs. Rules

	Rule	Policy
Created via	Conversation or cogz_write	Web UI wizard or conversation
Enforcement	Guidance only — Athena follows but can’t block	Configurable: hard, soft, or audit
Violations tracked	No	Yes, with history
Versioned	No	Yes — updates create new versions
Best for	Conventions, preferences	Standards that must be enforced

Both rules and policies are injected into Athena’s context (L3 layer) and apply to every conversation in the org. The difference is whether violations are actively enforced and tracked.