Skip to main content

Zero-Config Governance

The primary review surface for zero-config governance is Governance Studio at /dashboard/studio.

Zero-config is the server-backed governance path for replay(). Add an API key, run your agent, and Vesanor builds a governance plan from tool schemas, descriptions, and observed traffic without local YAML.

This path is still review-first before approval, but it no longer stops at review. Once an approved runtime artifact exists, the SDK can enforce from that approved compiled_session using environment-based behavior.

One line of code​

import OpenAI from "openai";
import { replay } from "vesanor";

const client = new OpenAI();

const session = replay(client, {
  apiKey: process.env.VESANOR_API_KEY,
});

const response = await session.client.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [{ role: "user", content: "Process this order" }],
  tools: myToolDefinitions,
});

No contractsDir. No local session.yaml. No per-tool YAML files.

Anthropic works the same way. Pass an Anthropic client instead of OpenAI and Vesanor will capture the same governance inputs.

What Happens Today​

1. The SDK fetches governance state for the agent​

When you use replay(client, { apiKey }) with no local contracts, the SDK fetches the current governance plan for the agent and environment.

2. Behavior depends on approval state and environment​

Before approval, zero-config remains capture-and-review oriented. After approval, the SDK rehydrates the approved compiled_session and applies runtime behavior from that artifact.

EnvironmentNo approved planApproved / enforcing plan
developmentCapture and reviewMonitor-style behavior. Evaluate without blocking
stagingFail closedAdvisory enforcement. Evaluate and surface violations without blocking
productionFail closedProtective enforcement. Block violations fail-closed

3. Vesanor builds a typed review plan on the server​

The server turns captured requests and responses into a canonical GovernanceReviewPlan using:

  • Schema-only inference for structural argument invariants
  • Deterministic description parsing for side effects, bounds, regex hints, and preconditions
  • Conditional semantic extraction for unresolved tool-level ambiguity only
  • Session inference for workflow placement, limits, bindings, aggregates, envelopes, and checkpoint suggestions

4. You review the draft in Governance Studio​

The Studio workspace shows the current draft review state, including:

  • Tool classifications and argument rules
  • Preconditions, forbids-after rules, and workflow placement
  • Session limits and accepted workflow phases
  • Binding, aggregate, and envelope candidates
  • Checkpoint suggestions
  • Governance gaps the system cannot infer safely
  • Warnings, dry-run traces, and plan-health findings

5. Approval freezes a server-side snapshot​

When you click Approve, Vesanor stores immutable compiled_plan and compiled_session snapshots for that version. New captures do not silently rewrite the approved version, and the approved compiled_session becomes the runtime artifact the SDK can attach to.

6. Post-approval drift becomes review work​

After approval, new evidence is audited against the approved snapshot. Vesanor raises targeted pending_review findings such as:

  • Newly observed tools not covered by the approved plan
  • Side-effect drift or under-classification
  • Argument invariant violations
  • Broken preconditions or forbids-after assumptions

Accepting a finding reopens a draft snapshot for explicit re-approval. Dismissing it leaves the approved snapshot unchanged.

What Zero-Config Surfaces​

AreaWhat you see today
Tool rulesSide effect, confidence, argument invariants, preconditions, forbids-after, phase placement
Session reviewPhases, transitions, session limits, bindings, aggregates, envelopes
Human reviewCheckpoint suggestions, governance gaps, warnings, dry-run evidence
Driftpending_review findings keyed to approved decisions
Runtime artifactApproved compiled_session and compiled_hash used by the SDK after approval

Vesanor only compiles accepted, typed decisions into the canonical review plan. Unsupported or ambiguous values are left as review_required instead of being silently normalized away.

Important Boundaries​

  • Zero-config is approval-driven. Before approval it learns and reviews; after approval it can enforce from the approved compiled artifact.
  • Development stays non-blocking even with an approved plan.
  • Staging is intentionally advisory today: violations are evaluated and surfaced, but not blocked.
  • Production is protective: if an approved plan exists, violations are blocked; if an approved plan or artifact is unavailable, the call fails closed.
  • Customer-triggered semantic re-analysis is still deferred. The current post-approval audit path is deterministic.

Next Steps​