DocsQuick StartsGovernance Professional Quick-Start (via API)

Governance professional — API path

Your developers' agents are working. Now you can see what they're committing to.

Through the REST API. For compliance teams scripting their monitoring.

You don't need a new tool to know whether your governance program is working. You need a way to see what your agents are actually committing to, at what maturity, and where coverage is missing — without writing a single regex over commit messages.

Dictiva surfaces all of it via four operational reads. Each is a single API call you can run from a terminal, schedule from a monitoring system, or hand to your developer to wire into a dashboard.

3 min

View your agent inventory.

Every agent registered in your tenant — humans don't show up here, only actor_type='agent' users with a resolvable W3C DID.

curl -H "Authorization: Bearer dv_live_..." \
  https://dictiva.com/api/governance/attestations/agents

Response:

{
  "data": [
    {
      "id": "uuid-...",
      "did": "did:web:dictiva.com:agents:agent-code-reviewer",
      "displayName": "Code Reviewer Agent",
      "lifecycle": "active"
    },
    { "id": "...", "did": "...:agent-content-harvest", "displayName": "Content Harvest Agent", "lifecycle": "active" }
  ]
}

Or open Workbench → Agents.

What just happened:

You can name every agent acting in your tenant's name. Each has an operator of record, a public DID, and a place in the audit trail.

4 min

See coverage at a glance.

Two reads answer the question: who's attesting to what, and where am I exposed?

Coverage matrix — agents × statements grid showing where attestations exist.

curl -H "Authorization: Bearer dv_live_..." \
  https://dictiva.com/api/governance/attestations/coverage-matrix

Gap report — the inverse: agent/statement pairs where coverage is missing or below your target tier.

curl -H "Authorization: Bearer dv_live_..." \
  https://dictiva.com/api/governance/attestations/gap-report

Together they tell you what an auditor will ask. Run them once a week and you have your starting point.

Workbench → Coverage Matrix renders the same data interactively.

What just happened:

Your agent governance program just became measurable. No regex over commit messages. No spreadsheet to keep up to date.

2 min

Understand the tier ladder.

Every attestation declares a tier on the Commitment Maturity Ladder. The tier is your credibility signal — T1 says "the agent claims it"; higher tiers add cryptographically-linked evidence.

  1. T1Read
    Agent identity + signed timestamp.Reachable today from the CLI.
  2. T2Aligned
    Semantic similarity report against the statement.Tooling not yet shipped.
  3. T3Referenced
    Memory file, AGENTS.md, or system prompt fragment.
  4. T4Procedural
    ADR, skill, or PR commit.
  5. T5Bounded
    Non-empty scope: tenants / entity types / actions / refusal rules.
  6. T6Enforced
    Hook, middleware, tool allowlist, or preflight.

What's reachable today: T1 (Read) is plausible from any developer's CLI workflow. T3 and T4 are reachable when a skill, memory file, or ADR demonstrably codifies the commitment. T2 (Aligned) requires a semantic_similarity_report artifact that hasn't shipped yet — flag this as a known gap when you brief your team.

T5 and T6 require scope expressions and runtime enforcement (hooks, middleware, tool allowlists). They typically come from infrastructure work, not solo authoring.

What just happened:

Your monitoring shouldn't treat T1 the same as T6. The tier IS the meaningful signal — read it, ratchet up over time.

6 min

Set up monitoring and finalize pending drafts.

PCA event subscription via webhooks isn't shipped yet. Today, the operational pattern is polling — three queries on three different cadences.

Daily — what new attestations landed?

curl -H "Authorization: Bearer dv_live_..." \
  "https://dictiva.com/api/agent/attestations?per_page=50"

Weekly — which are tier-1-only and might warrant a follow-up?

curl -H "Authorization: Bearer dv_live_..." \
  "https://dictiva.com/api/agent/attestations?tier=T1"

Daily — what's expiring? PCA credentials carry an expiration; a forgotten renewal becomes a coverage gap.

curl -H "Authorization: Bearer dv_live_..." \
  https://dictiva.com/api/governance/attestations/expiration-calendar

One-click finalize — when a developer commits with an Attests: trailer, the credential lands in your drafts inbox awaiting your review:

Workbench → Drafts inbox

Each draft shows the source (github_webhook / mcp_skill_registration / agents_md_parser), the proposed tier, the evidence, and a one-click finalize.

What just happened:

Governance becomes detection, not paperwork. Three queries on three cadences plus a weekly trip to the drafts inbox is your full operating cycle.

What you just unlocked

You can answer three questions live, in a meeting, without preparation.

  1. Who? — Every agent acting in our tenant, with operator of record and DID.
  2. What? — Every commitment they've made, at what tier, against which statement.
  3. Where are we exposed? — Every gap in the coverage matrix, every commitment expiring this month, every draft awaiting finalization.

What's coming (and what to plan for)

Today's monitoring is polling-based. On the near-term roadmap:

  • Webhook subscriptions for PCA events — push delivery to your SIEM, your ticketing system, or your alerting bus. No more cron.
  • Statement-level alerts — define an alert rule per statement (e.g. "T1-only commits past 30 days"), get paged when it fires.
  • semantic_similarity_report tooling — unblocks T2 attestations from agent CLI workflows. The whole industry needs this; we're shipping it.
  • Cross-tenant audit views for parent organizations governing multiple tenants.

If you hit a wall, the PCA overview covers the underlying credential model, and PCA API reference covers every endpoint shape.

Next door

You can see what's working. The next question is what should be working — that means going upstream to the policies your agents are reading.