Observe runs, usage, and governance evidence

​

Prerequisites

• a written success criterion and proof boundary for the integration under test;
• synthetic tenants, subjects, credentials, and lifecycle fixtures;
• redacted observability fields and a secure location for test evidence;
• an owner for rollback, cleanup, and unresolved qualification gaps;
• an acceptance assertion that proves run, event, usage, delivery, and trace evidence correlate without leaking tenant data.

​

Execution Fabric dashboard

​

Read one run

const response = await fetch(`https://api.praxa.io/v1/runs/${runId}`, {
  headers: { authorization: `Bearer ${process.env.PRAXA_API_KEY}` },
});
if (!response.ok) throw new Error(await response.text());
const run = await response.json();

​

Resume the event stream

const response = await fetch(
  `https://api.praxa.io/v1/runs/${runId}/events`,
  {
    headers: {
      authorization: `Bearer ${process.env.PRAXA_API_KEY}`,
      accept: "text/event-stream",
      ...(lastEventId === undefined ? {} : { "last-event-id": lastEventId }),
    },
  },
);

if (!response.ok || !response.body) throw new Error(await response.text());
// Parse SSE frames, require numeric increasing IDs, and persist each cursor.

​

Read usage evidence

curl --get https://api.praxa.io/v1/usage \
  -H "Authorization: Bearer $PRAXA_API_KEY" \
  --data-urlencode "from=2026-08-01T00:00:00.000Z" \
  --data-urlencode "to=2026-09-01T00:00:00.000Z" \
  --data-urlencode "group_by=day"

​

Inspect webhook deliveries

curl --get https://api.praxa.io/v1/webhook-deliveries \
  -H "Authorization: Bearer $PRAXA_API_KEY" \
  --data-urlencode "run_id=$RUN_ID" \
  --data-urlencode "limit=50"

​

Integration Gateway diagnostics

const [mission, trace, skill, coverage] = await Promise.all([
  client.getMission(runId),
  client.getTrace(traceId),
  client.getSkill(skillId),
  client.getReferenceCoverage(),
]);

​

Recommended data model

type ObservedRun = {
  plane: "execution_fabric" | "integration_gateway";
  tenantKey: string;
  runId: string;
  status: string;
  lastEventId?: string;
  lastSequence?: number;
  updatedAt: string;
  terminal: boolean;
};

​

End-to-end verification

1. Create a disposable run and save its returned identifier.
2. Read that exact run and reject unknown or foreign IDs.
3. Stream, persist a cursor, disconnect, and resume without regressing sequence.
4. Require one terminal state or explicitly record a timed-out verification.
5. Query a range containing the run and confirm usage remains tenant scoped.
6. If using webhooks, correlate delivery run_id with the run and deduplicate by event_id.
7. For the Integration Gateway, compare trace, skill, and coverage outputs only within their documented scope and deployment.
8. Revoke the disposable credential and require all subsequent reads to fail closed.

​

Troubleshooting

​

Best practices

• Define the expected observable result before running the test.
• Separate positive, denial, isolation, replay, degraded-state, and cleanup lanes.
• Use synthetic data and credential fingerprints rather than secrets.
• Record unresolved checks as pending instead of inferring success.
• Keep rollback and owner information beside the release evidence.

​

Optimize for production

• Run cheap contract and fake tests before authenticated canaries.
• Parallelize only independent test lanes and cap external side effects.
• Sample high-volume telemetry while retaining every denial, conflict, and terminal failure.
• Measure pass rate, p50/p95 latency, retry budget, isolation failures, cleanup completion, and time to diagnose.

​

Cleanup and next steps

1. Revoke every disposable key and OAuth grant.
2. Remove test endpoints, provider records, candidates, and local artifacts.
3. Close or explicitly record unresolved runs and verification gaps.
4. Publish only redacted results, exact versions, timestamps, and rollback instructions.

​

Frequently asked questions

​

What proves this tutorial works?

​

Can a browser, mobile app, or model prompt hold the credential?

​

How should an ambiguous mutation be retried?

​

What should we monitor after release?