CALIBER v1.0.0 product requirements document

Status and decision#

Status: draft for approval. This PRD defines the product contract that the roadmap delivers. It does not assert that CALIBER has reached v1.0.0 or that all visible alpha capabilities are supported.

The proposed v1.0.0 product is an enterprise-usable, single-tenant CALIBER deployment for one governed prompt-refinement journey. A named operator can take a flagged MLflow trace through verification, diagnosis, candidate creation, evaluation, authorized Apply, and auditable release, reconciliation, or rollback. The journey is available through the documented UI and a small, contract-tested API/SDK/CLI subset.

The product decision is deliberately narrower than the repository's alpha surface. It prioritizes an operable and recoverable path over broad lifecycle coverage or distributed scale.

Problem and users#

Agent-development teams can observe a poor model or agent outcome but often cannot safely turn that evidence into a reviewed production change. The work is split among tracing, prompt authoring, evaluation, release tooling, and operator runbooks. Failures across a non-transactional provider boundary can leave an uncertain live state.

Product goal and success measures#

The goal is not to make every CALIBER asset family production-ready. The goal is to make one named prompt-refinement path supportable for one enterprise tenant.

Pilot PASS proves only the named commit, environment, fixture, and journey. It does not prove production readiness without the v1 security, recovery, and acceptance evidence.

Scope#

Supported v1 journey#

flagged MLflow trace
  -> human verification
  -> diagnosis
  -> candidate creation
  -> evaluation gate
  -> explicit authorized Apply
  -> durable release, reconciliation, or rollback evidence

The supported deployment is one tenant, one active CALIBER process, a durable PostgreSQL metadata store, a named MLflow tracking/provider profile, selected object storage when required by the canonical fixture, external TLS/ingress and network policy, least-privilege credentials, authenticated role-based users, logs/traces/metrics/readiness, backup/restore, and a human-operated upgrade and incident procedure.

Explicit non-goals#

• Multi-tenancy, SSO/SCIM, and cross-tenant lifecycle management.
• HA, active-active or multi-worker operation, broker acknowledgement/replay, and multi-region disaster recovery.
• Managed hosting, Kubernetes operators, or automatic TLS issuance.
• General-purpose untrusted tool/MCP execution.
• A uniform lifecycle or production-support claim for every visible asset family, provider, optional dependency, API, SDK, or CLI operation.
• An unmeasured scale or performance promise.

These are post-v1 decisions, not implicit v1 commitments. They are represented by Epic #58 and its child work.

Product requirements#

Experience and operating constraints#

The user experience must make the governing decisions visible, not inferred:

• Verification and Apply are human decisions; evaluation evidence informs them but does not silently change the live target.
• Every external release effect has a durable state and an operator-visible next action. Indeterminate effects must be labelled reconcile_required, not reported as successful.
• The API/SDK/CLI contract is intentionally smaller than the current alpha API surface. Unsupported operations must fail clearly rather than degrade.
• The hardened deployment runs one active CALIBER process. Starting a second process cannot silently produce duplicate scheduler, reconciler, or worker effects.
• The release decision is human-owned. Automation, an agent, or a passing test suite cannot approve or merge a production decision.

Delivery traceability#

The GitHub Project is the execution system; this table is the requirements trace. Individual issue bodies remain the source for implementation details, test commands, dependencies, and completion evidence.

Release gates and timeline#

The roadmap owns dates and capacity. The PRD gates those milestones as follows:

Risks, assumptions, and open decisions#

Approval and change control#

Approval requires the product lead to accept this boundary and record the decision in #153. Any material change to the supported journey, topology, provider profile, or non-goal must update this PRD, the roadmap, the Project hierarchy, and the affected issue acceptance criteria in the same pull request.

This PRD is superseded only by a versioned revision that identifies the changed requirements and the evidence required to support them.