Policy author — Dashboard path
Author once. Every agent on Earth that touches your tenant honors it.
A guided wizard, four answers, one published statement. No code, no schema fields, no curl.
Most policy programs are PDFs — written once, distributed, forgotten. Statements in Dictiva are different: they're machine-readable, scope-bound, version-pinned, and attestable. Authored once, they show up in every agent's MCP context immediately. And every commitment they receive comes back to you as evidence.
This is the dashboard path. You'll click through a four-step wizard, answer four questions, and end with a published statement that agents can read and attest to. No knowledge of JSON, schema fields, or REST APIs is required.
3 min
Search the Library before authoring.
Open Library → Statements. The search bar at the top filters across every statement in your tenant — by domain, lifecycle state, modality (must / should / may), risk tier, and whether the statement applies to humans, agents, or both.
Type your topic — data retention, code review, PII handling — and watch the filters live-update. If something close to what you want already exists, adopt or refine it rather than authoring a sibling. Your policy graph is shared. Every duplicate you avoid keeps it readable for the next author and for every agent reading from it.
Dedupe is the policy author's discipline. The library you start with shapes the policy program you end up running — and the cleaner the graph, the easier every conversation with auditors becomes.
10 min
Walk the New Statement wizard.
From the Library page, click + New Statement. The wizard runs in four stages.
Stage 1 — Compose. Title, body, and modality. Modality is the imperative strength: must (non-negotiable), should (default unless justified otherwise), may (permitted, optional). The wizard offers an AI draft if you'd like a starting point — the prose is yours to edit.
Stage 2 — Classify. Pick the domain (Privacy, Security, AI Use, Data Governance, etc. — or create one), the statement type, the risk tier, and the maturity level. These are how your statement gets organized and discovered. Auditors filter by them, agents filter by them.
Stage 3 — Annotate. Tags, governance dates (effective / review / sunset), and the AI governance dimension — applies_to (human / agent / both) plus optional actor_scope refinement. This is where the statement becomes something an agent can act on, not just read.
Stage 4 — Review & Submit. A read-only preview of everything you've assembled. Save as draft to revisit, or publish to make it discoverable to agents and humans across your tenant.
The wizard fills in defaults you don't specify. Most statements only need title, body, modality, domain, and applies_to — the rest can be refined later.
5 min
Choose the enforcement mode.
In Stage 3 of the wizard (or on a published statement's detail page), the enforcement mode field is your governance lever. It's a four-rung ladder you can ratchet over time.
- Informational. Agents read the statement, may reference it; no behavior change. Use for new statements when you want to see who notices before you require anything.
- Human review required. Agents pause before consequential actions and request human approval. Use for statements that gate production deploys, data exports, customer-facing actions.
- Machine-readable. Agents parse the statement and self-restrict based on the agent-guidance fields. Most published statements live here — the standard enforcement.
- Machine-enforceable. A runtime hook, middleware, or tool allowlist physically prevents prohibited actions. The strongest claim. Pair with high-tier attestations.
A reasonable cadence: publish at informational for two weeks, watch attestations land, ratchet to machine_readable once you see agents adopting it. You can change the mode at any time from the statement's detail page — agents pick up the new mode on their next session.
Soft-launch is a feature, not a workaround. The mode is a property of the statement, not the publication — you don't have to re-publish to harden it.
3 min
Scope it to the right actors.
In Stage 3, two fields define who's bound by your statement:
Applies to— Human, Agent, or Both. The same prose may have different consequences for a human reviewer (advisory) versus an agent reviewer (machine-enforceable). Pick the one that matches your intent — agents reading the live policy will only see statements that apply to them.Actor scope(optional) — type a refinement like code-reviewer, service-account, or agent-workflow. The statement only binds agents identifying themselves in that role. Leave blank to bind any agent.
A worked example. The statement "Cannot push to main without two approvals" might be applies_to: both, actor_scope: <empty>, modality must — applies to humans and agents alike. The statement "Must run security-scan before merging" might be applies_to: agent, actor_scope: code-reviewer, enforcement machine_enforceable — only the dev's code-reviewer agent sees this one, and it's blocked from merging without the scan.
Same prose, different consequences. The scope fields let one statement carry the right weight for the right principal.
5 min
Watch agents adopt your statement.
Open the statement's detail page (from the Library list, click the title). At the top is the canonical text, the modality, the enforcement mode, the scope. Below is the Adoptions tab.
The Adoptions tab shows every agent that's attested to this statement, the tier they claimed (T1 Read → T6 Enforced), the evidence they submitted, and when their commitment expires. Filter by tier to see who's at each maturity level. Filter by date range to see adoption-over-time.
Agents that should attest but haven't show up in the Gaps tab — visit Attestations → Gaps for a tenant-wide view that pivots on the same data.
Your policy lands. You can name the agents that adopted it, the tier they reached, and the agents that haven't — the unattested gap is the conversation to have next.
What you just unlocked
Three things are now true that were impossible with PDFs.
- Discoverability. Every statement is queryable by domain, modality, applicability, and enforcement mode. Auditors look themselves up.
- Attestability. Every agent commitment leaves a signed credential anyone can verify — including auditors, customers, and regulators that don't trust your platform.
- Enforceability as a ratchet. Soft-launch at
informational, watch the data, harden when you're ready. No revisions, no re-publishing — same statement, new mode.
What's coming
- Statement templates — one-click starting points for common policy categories (privacy, security, AI use, code review).
- Adoption alerts — get notified when adoption stalls, when divergence appears, when a previously-attested agent stops attesting.
- Diff-aware re-attestation — when you edit a published statement, agents that previously attested are notified to re-attest (or refuse) at the new version.
Want to see this in code? Switch to the API path for the same five steps with curl and MCP.
Next door
You authored the policy. Now make sure the operator side has the tools to watch agents adopt it.