How manifests get created
You rarely callPOST /manifests directly. The SDK’s framework adapters (decimalai.langchain.install(), decimalai.openai_agents.install(agent=...), etc.) extract the structural config and call it for you. The GitHub Action regression-check runs the same code under DECIMALAI_MODE=manifest_only to capture the PR-branch manifest.
Common patterns
Timeline view
GET /manifests?agent_name=... returns version history in reverse chronological order.Inspect a version
GET /manifests/{id} returns the full component list with content hashes — useful for diffing two versions.Explicit registration
When the SDK can’t auto-detect (custom framework, dynamic config), call
decimalai.register_manifest(...) directly with the components you want recorded.CI manifest extraction
The regression-check GitHub Action runs in
manifest_only mode — it calls your agent factory but suppresses LLM traffic, then writes the manifest ID to a file CI can read.One-call impact report
GET /agents/{agent_name}/impact-report returns the full impact of a manifest transition in one response: surface changes, affected_trace_count, keep/repair/replay/drop buckets, and a human-readable summary. Defaults to the latest transition; pin either side with manifest_id / baseline_manifest_id. (Python: client.impact_report("my-agent").)Concepts
- Manifest hash: SHA-256 fingerprint of structural components (tools + models). Same hash + same agent = idempotent.
- Component: one piece of the manifest. Types:
tool,model,prompt,skill,subagent,output_contract. - Status:
active(current),superseded(replaced),draft(registered but not activated). - Revert: same hash reappearing reactivates the old manifest — no duplicate.
Related
- Manifests Guide — framework-by-framework setup
- Regression Check — how manifests drive the PR comment
- Compatibility Policies — tune how strict the impact analysis is