OBSERVABILITY

Execution should be inspectable from request intake to terminal outcome.

Tenzarch exposes execution state through durable Job records, lifecycle progress, assignment information, logs, telemetry, and result summaries where available.

EXECUTION STATE

The Job record is the operational anchor.

Execution Jobs give each workload a durable reference. The Job state can be read after submission, after routing, during execution, and after completion or failure. This avoids treating AI execution as a single opaque loading state.

Status

Use queued, routing, assigned, running, retrying, completed, and failed as lifecycle states.

Progress

Progress is a state indicator for user experience and should not be treated as proof of result quality.

Assignment

Assigned-node information explains which execution capacity was selected when that data exists.

Outcome

Completed and failed jobs should be handled as terminal outcomes with explicit result or failure handling.

DEVELOPER ROUTES

Developer integrations inspect jobs through authenticated routes.

Observability routes

GET /api/developers/jobs
GET /api/developers/jobs/:jobId
GET /api/developers/jobs/:jobId/logs
GET /api/developers/jobs/:jobId/telemetry

Use these routes with a scoped server-side API Key. Browser-exposed public frontend code should not contain developer API Keys.

OPERATING PRACTICE

Store the execution references that let you investigate later.

Persist jobId

Connect your application request to the Tenzarch execution record.

Persist workflowRunId

Keep the orchestration reference where the backend provides it.

Poll responsibly

Use lifecycle state and backoff instead of aggressive repeated requests.

Read logs and telemetry

Inspect details when an execution fails, retries, or needs investigation.

TELEMETRY MODEL

Telemetry should explain movement through the execution network.

Telemetry is useful when it helps developers and operators understand what changed: a Job was created, a Workflow Run was initialized, routing began, a node was assigned, execution started, a provider request was made, a result was stored, or an execution failed. It should not be used to invent unsupported real-time metrics.

01JOB_CREATED

02WORKFLOW_INITIALIZED

03ROUTING_STARTED

04NODE_ASSIGNED

05EXECUTION_STARTED

06RESULT_STORED

07EXECUTION_COMPLETED

FAILURE ANALYSIS

Failures are part of the contract, not an afterthought.

Validation failure

The request cannot become a valid workload because required input, authentication, scope, or credit state is missing.

Routing failure

The network cannot currently find eligible execution capacity for the workload.

Runtime failure

A workload was accepted but failed while executing or while interacting with its execution provider.

Recovery path

Retry only when the lifecycle state, error code, and idempotency boundary make the retry safe.