Skip to main content

Deployment Testing & Validation

AxonFlow validation should prove more than "the service starts." A serious rollout should confirm that runtime, governance, identity, approval, execution, monitoring, and evidence paths behave correctly in the deployment model you actually run.

Use this page for initial rollouts, upgrades, policy-framework changes, connector onboarding, provider onboarding, and major approval or compliance workflow changes.

Minimum Validation Bar​

Before treating a deployment as ready, validate all of the following:

  1. the runtime health checks pass
  2. the expected license or edition state is visible
  3. policy-management flows respond for the intended tenant or organization context
  4. one safe agent or request-mode workflow succeeds
  5. one approval workflow can pause and resume, if approvals are in scope
  6. one execution can be inspected in the expected status, replay, or dashboard view
  7. one export path works for audit or usage evidence, if evidence export is in scope

If any of those fail, the platform may be running but still not operationally ready.

Validation Sequence​

1. Runtime and License Checks​

Start with basic runtime health:

curl -sf http://localhost:8080/health | jq .
curl -sf http://localhost:8081/health | jq .

Then confirm the license or edition behavior that applies to the environment:

  • Community should run without a license key
  • Evaluation and Enterprise should expose the expected licensed capabilities
  • SaaS and In-VPC deployments should expose only the surfaces intended for that mode

Use Deployment Mode Matrix and License Management when the expected behavior is unclear.

2. Policy-Management Checks​

Validate policy visibility and one safe policy test path:

  • confirm active policy inventory loads
  • simulate one benign request against the intended policy context
  • verify the result explains whether the request is allowed, blocked, redacted, or routed to approval
  • confirm policy changes are not being tested directly against production traffic

Start with Policy Hierarchy, Configuring Policies, and Policy Simulation for the public path.

3. Agent and Request-Mode Checks​

Validate at least one request path that matches how your application will call AxonFlow:

  • Proxy Mode for app-mediated LLM requests
  • Gateway Mode for request-level gateway enforcement
  • MCP for governed tool or connector access
  • WCP or MAP for governed workflows

The key test is not just whether one endpoint returns 200. The key test is whether the request passes through the intended governance layer and produces the audit, policy, and monitoring signals you expect.

Use Choose A Runtime Path and Choosing a Mode to select the right path.

4. Workflow and Approval Checks​

For deployments that use approval or workflow governance, run one workflow end to end:

  • create or trigger a safe workflow
  • call a step gate
  • trigger or simulate an approval path
  • review the pending approval
  • approve or reject the step
  • confirm the workflow resumes, terminates, or records the expected outcome

This proves governance is actually operable, not only configured.

5. Execution Visibility Checks​

For the same test workflow or request path, confirm operators can inspect what happened:

  • status or execution list view is populated
  • detailed execution view shows the expected steps
  • replay or trace information is available where that feature is enabled
  • metrics and logs move in the expected monitoring surface

Use Execution Viewer, Execution Operations Playbook, and Monitoring Overview as the public baseline.

6. Audit and Evidence Checks​

If audit or compliance evidence is part of the rollout, test at least one export or retrieval path:

  • confirm usage or audit data exists for the test action
  • export a small evidence sample
  • verify the exported fields match the downstream parser or review workflow
  • confirm the export does not include raw secrets or unnecessary sensitive data

For public API families, start with Audit API and Enterprise Compliance API Surface.

Smoke-Test Checklist​

  • runtime health checks pass
  • expected license or edition state is visible
  • policy inventory and simulation work
  • one request-mode path succeeds
  • one connector or provider-backed path succeeds, if in scope
  • one approval queue item can be reviewed, if approvals are in scope
  • one workflow or execution appears in the expected status view
  • one audit, usage, or evidence export path succeeds
  • monitoring reflects the test traffic

Failure Patterns To Catch Before Production​

Common rollout failures are usually not subtle:

  • session or identity works, but proxied runtime APIs do not
  • health endpoints pass, but provider or connector credentials are wrong
  • approval queues fill, but reviewers cannot complete actions
  • execution status works, but replay or export does not
  • policy simulation works in one tenant context but not another
  • metrics exist for the runtime but not for the workflow path being tested

A serious validation plan should catch these before production traffic depends on the platform.

Last updated on