Skip to main content

FAQ

Short answers to the questions that come up most often.

Use the public zero-config path:

  1. wrap your client with replay(client, { apiKey, agent })
  2. run real traffic through session.client
  3. open Governance Studio
  4. review the workspace draft
  5. approve when ready

That is the main product flow in this repo today.

Do I need YAML contracts to use Vesanor?​

No.

You do not need local YAML packs, session.yaml, or hand-authored per-tool files to use the main product path.

Is Governance Studio the main browser surface now?​

Yes.

/dashboard redirects to /dashboard/studio, and the old /dashboard/agents browser authoring routes redirect there as well.

What happens before approval?​

Before approval, zero-config governance is review-first.

That means:

  • the SDK can capture runtime evidence
  • Studio can show drafts, judgments, approval preview, and conformance context
  • the runtime does not attach to an approved artifact until one exists

In that state, you will often see governanceAttachment: no_plan.

What does approval actually freeze?​

On the Studio side, approval creates durable approval records for the current draft snapshot, including:

  • a GovernanceApproval
  • a linked CompiledGovernanceArtifact
  • an updated active_approval_id on the workspace

Separately, the zero-config runtime path still attaches through GovernancePlan and its approved runtime artifact.

See Approval Model.

Does approval make production enforcement happen immediately?​

Not by itself.

The runtime still has to fetch and attach the approved artifact successfully.

After approval:

  • development stays non-blocking
  • staging evaluates in advisory mode
  • production enforces protectively and fails closed when governance is unavailable

What do no_plan, fetch_failed, and artifact_invalid mean?​

They mean different things:

  • no_plan: the hosted lookup worked, but there is no approved plan for that agent/environment yet
  • fetch_failed: the runtime could not fetch hosted governance state
  • artifact_invalid: an approved plan exists, but the runtime artifact is not valid enough to attach
  • attachment_failed: the plan was found, but runtime initialization still failed

Those are not interchangeable states.

See Runtime States.

What happens if the server is down?​

It depends on the path and environment.

For the public zero-config path:

  • development remains non-blocking
  • staging and production fail closed when governance is unavailable

For explicit Govern sessions using wrapped tools, runtime durability can degrade to local behavior depending on configuration, but that is the advanced runtime path.

Do I need to wrap tools?​

Not necessarily for the main zero-config path.

You do need wrapped tool executors when you want stronger governed execution evidence, durable receipts, and full govern-level behavior on state-bearing tool paths.

What is the difference between Studio, Runs, and References?​

  • Studio is the review and approval surface
  • Runs is the execution and evaluation history surface
  • References is the operational trust surface for active, stale, candidate, and retired references

Studio tells you the current operating model. Runs tell you what happened. References tell you what is currently trusted.

Are baselines and references still useful if I do not use local contracts?​

Yes.

References are still useful for:

  • trust posture
  • active vs stale reference state
  • promotion readiness
  • operational comparison over time

They are not tied to hand-authored local YAML packs.

Does local promote show up in Studio automatically?​

No.

Promoting a local observed pack into a local truth pack does not automatically make it the Studio authority.

In the current repo, local packs and Studio/browser approval are separate lanes.

Is workflow governance the default path?​

No.

The default public path is zero-config governance plus Studio.

Workflow governance exists in the repo as an advanced runtime capability for multi-agent coordination, handoffs, shared-resource controls, and workflow-level kill behavior.

What is the difference between healthy and active?​

They describe different dimensions.

  • healthy belongs to overall runtime status
  • active belongs to authorityState

A runtime can be broadly healthy while still being advisory rather than actively authoritative.

Where did the old local-pack docs go?​

They were moved out of the public docs site into:

  • docs/legacy/advanced-local/

That archive includes the older observe/promote/YAML-pack material and the older local governance docs.