Create and edit policies

The policy editor is where most of the work happens. This page covers every field on the form and every thing that can trip you up.

Opening the editor

• New policy: from the policies list, click New Policy (top-right).
• Edit existing: from a policy’s detail view, click Edit (top-right). You must have the EDIT_POLICIES permission (Policy Editor, Policy Lead, or Admin).

The editor body

InPolicy uses a TipTap rich-text editor, not Markdown. The toolbar supports:

• Text formatting: bold, italic, underline
• Headings: H1, H2, H3
• Lists: bulleted, numbered
• Blockquote
• Links: paste or use the link button (⌘K / Ctrl+K)
• Inline code

If you paste from Google Docs, Word, or a webpage, most formatting carries over. If you paste plain text, it’s inserted as a plain paragraph.

There is no Markdown syntax input — typing ## heading will not convert. Use the toolbar.

Minimum length: 10 characters of body text. Shorter bodies can’t be saved.

Maximum length: No hard cap. Very long policies (>50KB of body text) will save fine but may slow violation detection — consider splitting into multiple related policies in the same Policy Area.

Metadata fields

Title

A short, specific name. Shown everywhere a policy is referenced. If left blank on save, InPolicy auto-extracts the first ~12 words of the body as the title. You can edit this later.

Severity (1–5)

Drives visual treatment in the extension, Mac app, and analytics:

• 1–3 (Low) — yellow underline, no dismissal required
• 4–7 (Medium) — orange treatment (used by analytics; per-policy severity is 1–5)
• 8–10 (High/Critical) — red treatment, always surfaces a card

The editor shows a 1–5 scale. Analytics uses a 1–10 range to allow for more granular bucketing if we expand the scale later.

Confidence threshold

Controls how certain PolicyBot must be before flagging a violation. The slider shows 0–10; stored internally as 0.0–1.0. Default is 8 (0.8).

• Higher (9–10): fewer flags, near-zero false positives. Right for broad “don’t share customer data” policies.
• Lower (5–7): more flags. Right for narrow, keyword-driven policies where you’d rather err on the side of a warning.

Policy Area

Every policy belongs to a Policy Area. Areas are managed by Policy Leads and Admins under Settings → Policy Areas. If the Area you want doesn’t exist, create it first.

Scope

Three optional dimensions:

• Audience — which employee groups this policy applies to
• Countries — list of country codes (ISO-3166 alpha-2). Blank = all countries.
• Teams — list of team names (free-text array).

Leaving all three blank means the policy applies to everyone on the tenant.

Effective and expiry dates

Optional. If set, the extension and Mac app will only flag violations for this policy during the effective window. Outside the window, the policy remains published (searchable, viewable) but is not enforced.

Rationale

A note to other editors explaining why this policy exists. Only visible to users with VIEW_POLICY_RATIONALE — by default, all editor roles. Rationale does not appear in the extension or Mac app surface; it’s for internal documentation.

Tags

Free-text list. Used for filtering in the policies list and in CSV exports. Not surfaced to end users in the extension.

Enforcement level

Three settings:

• Fix — PolicyBot suggests a rewrite. The user sees the suggestion and a “Apply fix” button.
• Warning — PolicyBot explains the issue but offers no rewrite. Most common default.
• Audit — PolicyBot logs the violation but shows nothing to the user. Used for silent compliance monitoring.

Saving

Two save actions:

• Save as draft — creates or updates the policy in DRAFT status. Drafts are invisible to User roles and are never checked by the extension or Mac app.
• Save & publish (or Publish on first save) — writes to PUBLISHED status. Triggers embedding generation; violation detection kicks in within ~30 seconds.

Each save creates a new revision in history. See Revision history for how that works, and Policy lifecycle for how policies move between draft, published, and retired states.

Who can do what

Action	Admin	Policy Lead	Policy Editor	User
Create a draft	✓	✓	✓	—
Edit a draft	✓	✓	✓	—
Edit a published policy	✓	✓	✓	—
Publish / unpublish	✓	✓	—	—
Delete a policy	✓	✓	✓	—
View policy rationale	✓	✓	✓	—

Policy Editors can edit drafts and published policies but cannot change publish status — a Lead or Admin has to flip that switch.

Gotchas

• The confidence slider shows 0–10 but stores 0–1. Don’t be alarmed if you set “8” and the API response says “0.8” — same thing.
• Editing a published policy keeps it published. There’s no “unpublish and re-review” flow.
• Embeddings regenerate on every publish. Rapid publish/edit/publish cycles may briefly cause the extension to miss violations while the new embedding is in flight.
• Auto-extracted titles can be awkward. If you let InPolicy generate a title from a body that starts with “Introduction” or “Overview”, you’ll get that as the title. Always set one manually for anything important.
• Pasted rich text can carry over color styles you don’t want. The easiest cleanup: select all → click the Clear formatting button (eraser icon) → re-bold anything you wanted bold.