Changelog

v1 customer API

This release covers bound directory/intelligence/administrative reads, client/project register writes, import lifecycle, manual commercial inputs, assumption review, investigations/notes/packages, saved scenarios and immutable reports/PDF.

The manifest identifies exact API revision and digest of immutable assets. Publication must match its API deployment. Staging proof is separately recorded by the acceptance/release gates; this entry is not a claim of live provider or customer-specific success.

Reference schemas and examples are tied to the deployed API revision. Publication receipts identify that revision, the documentation digest and the website build together, so engineers can verify the API they are integrating against. Documentation publishes only after matching API capability is deployed; stale or corrupted releases are refused. Generic downloads retain the original immutable release bytes.

2026-10-16 — AI-assistance provenance in AI Economics

GET …/ai-economics and …/ai-economics/surface add an assistance object: every merged change in the selection classified as confirmed, possible, conflicting, declared not assisted or unclassified from source-control provenance (self-reported tags, and markers a coding agent signs itself), with coverage, baseline eligibility and per-change evidence links. adoption adds possibleChanges and per-item evidenceKinds, and its provenance (with the comparison's) may now read source_provenance. All additions are optional fields or new enum values; unclassified always means unknown, never non-AI, and nothing here reports tokens, spend, AI-written lines or time saved from Git metadata.

2026-10-06 — azure AI provider value

Report-builder narrativeProvenance.provider (create, preview and read) and the organization settings data policy's aiProviders may now be azure — a Microsoft Foundry model deployment — beside openai and anthropic. The change is additive: nothing else in those schemas changed. Treat an AI provider value you do not recognise as an opaque label.

Compatibility policy

Compatible new operations may be added after review. Removing or changing an existing request/response schema, required scope, current action, plan policy or mutation semantics fails the checked baseline and needs an explicit major-version decision. Editorial explanations/synthetic examples can improve separately. Never silently replace the baseline to hide a breaking change.

See Getting started, API reference and plans/limits. Unbound operations are not advertised.