API Surface & Evidence¶
The whole surface, what it maps to, and how current state proves it.
This page mixes hand-written prose with generated evidence
The narrative is hand-written. The catalogs and counts inside EAA regions are rendered live from the platform's current EAA evidence and CI-checked. Where pinned evidence is narrower than the full typed contract, this page says so.
Two Numbers To Hold In Mind¶
The typed contract surface is large: across the OpenAPI specs there are on the
order of 428 declared operations. The wired surface — operations backed by a
running backend today — is a subset; the rest are typed contracts whose backends
are planned. A typed contract with no wired backend is a design asset, not a
delivered API. The authoritative classification
(delivered_wired / contract_only_spec / roadmap_named_no_contract) lives in
the platform's capability maturity register.
Evidence-Backed Route Catalog (generated)¶
The routes the platform currently lowers as authoritative EAA evidence — generated live, not hand-typed:
| Operation | Method | Path |
|---|---|---|
createConfigDoctorCase |
POST | /config-doctor/cases |
getConfigDoctorCase |
GET | /config-doctor/cases/{case_id} |
finalizeConfigDoctorCaseForRun |
POST | /config-doctor/cases/{case_id}:finalize-for-run |
planConfigDoctorRepair |
POST | /config-doctor/cases/{case_id}:plan-repair |
validateConfigDoctorCase |
POST | /config-doctor/cases/{case_id}:validate |
This pinned evidence set is the Config Doctor surface. It is intentionally narrower than the full 428-operation contract — it reflects what the current EAA state proves as authoritative evidence, not everything declared in the specs.
Analytical Truth (generated)¶
The schema these APIs read and write:
| Metric | Value |
|---|---|
| Table Count | 857 |
| Field Count | 26619 |
Governed Runtime Boundaries (generated)¶
Every API action crosses governed runtime boundaries. The platform currently records
53
of them:
| # | Runtime boundary |
|---|---|
| 1 | receipt_contract |
| 2 | lineage_hooks |
| 3 | runtime_boundary_guards |
| 4 | runtime_public_api |
| 5 | cli_command_registry |
| 6 | promotion_gate_registry |
| 7 | receipt_schema_registry |
| 8 | openapi_contract_exporter |
| 9 | pydantic_schema_stability |
| 10 | terraform_extractor_hardening |
| 11 | bigquery_contract_extractor_hardening |
| 12 | workflow_lowering_hardening |
| 13 | graph_staging_schema_hardening |
| 14 | graph_staging_export_validator |
| 15 | source_fact_drift_gate |
| 16 | source_authority_coverage_scanner |
| 17 | negative_fixture_catalog |
| 18 | qa_evidence_matrix |
| 19 | documentation_consistency_gate |
| 20 | runtime_performance_budget |
| 21 | performance_trend_comparator |
| 22 | security_trust_boundary_registry |
| 23 | ci_integration_candidate |
| 24 | documentation_publisher_candidate |
| 25 | documentation_traceability_index |
| 26 | backward_compatibility_matrix |
| 27 | runtime_consumer_onboarding_scaffold |
| 28 | follow_on_tranche_closure_planner |
| 29 | latest_vre_agent_harvest_gate |
| 30 | gcp_e2e_execution_gate |
| 31 | gcp_e2e_receipt_schema_registry |
| 32 | gcp_e2e_command_receipt_harness |
| 33 | gcp_e2e_live_runner_adapter |
| 34 | gcp_e2e_live_execution_runner |
| 35 | gcp_e2e_live_receipt_persistence_guard |
| 36 | gcp_e2e_full_evidence_bundle_validator |
| 37 | gcp_e2e_live_evidence_bundle_orchestrator |
| 38 | gcp_e2e_phase_receipt_runner |
| 39 | adr_candidate_generator |
| 40 | adr_requirement_gate |
| 41 | wip_surface_leakage_guard |
| 42 | harvest_absorption_gate |
| 43 | runtime_packaging_candidate |
| 44 | closure_governance_report_generator |
| 45 | receipt_closure_bundle_aggregator |
| 46 | lowering_extension_point_index |
| 47 | generator_capability_catalog |
| 48 | template_version_lock_guard |
| 49 | artifact_ownership_collision_guard |
| 50 | generated_header_manual_edit_guard |
| 51 | import_boundary_guard |
| 52 | semantic_diff_coverage_matrix |
| 53 | runtime_smoke_matrix |
How This Page Stays Honest¶
The generated regions above are produced by the EAA documentation region engine
(docs/architecture/_eaa_publishing/). On every docs build they can be
re-rendered from current state, and a CI check fails if any published number
drifts from reality. That is why this page can carry hard numbers without risking
the "documentation says X, system does Y" gap.
What This Means For Integration¶
- Build against the wired operations named throughout this guide; treat contract-only specs as forward signals, not endpoints to call yet.
- When in doubt about an operation's maturity, consult the maturity register — not the raw OpenAPI spec, which includes planned contracts.
- The numbers on this page are current as of the last docs build; they are generated, not asserted.