AIP v0.7.0

Published from qualified candidate fdbabcfa949836fbc654d01f2041bafb394bb74e after the technical GO.

AIP adds the bounded question: which consumers have configured access to an API Operation, an
application Service or a gateway Route, which of them have independently observed usage in a
selected completed window, and what remains unresolved? It is answered by a fifth read-only MCP
tool, get_api_consumer_usage, and by POST /api/api-consumer-usage and
POST /api/api-consumer-usage/evidence. There are exactly five read-only MCP tools. See the
guide.

Scope of the qualification

• The configured-access implementation is qualified for APISIX only (3.19.0, over the Admin API
  with etcd). A differently shaped gateway source (Tyk was examined as a cross-check) shows a native
  access concept the current model cannot carry without a reviewed source-neutral amendment. That is
  a recorded MODEL_GAP, scoped out of v0.7; no second gateway adapter ships.
• Associations need a mapping or an exact match. A Route is linked to an API Operation by an
  explicit statement or an exact path and method match, and to an application Service by an
  explicit statement or an aip/service label. Without either, the association stays unresolved by
  design, and the answer says so. A consumer list is complete only for the Routes the answer names.
• Configured access is a configuration fact and observed usage is a measurement. Neither is
  authorization, approval, ownership, policy, architectural Intent, a complete consumer population or
  proof that a change is safe. A measured zero is bound to its window and coverage.

Migration and contracts

Product, Producer and MCP server version become 0.7.0. The earlier answer contracts and the meaning of
the four earlier tools are unchanged. The new answer uses its own published 0.7 request and answer
schemas. Without a gateway source in the
configuration, the canonical snapshot has none of the new keys, so every earlier snapshot is
unchanged.

New optional configuration registers the sources (see configuration):

architecture_intelligence:
  sources:
    gateways:             # an APISIX configuration capture (python -m app.gateway_capture.apisix)
      - {id: apisix-prod, root: ./captures/gateway, gateway_instance_id: gw-prod-1}
    gateway_measurements: # a measurement window (python -m app.gateway_capture.apisix_metrics)
      - {id: apisix-prod-metrics, root: ./captures/metrics, gateway_instance_id: gw-prod-1, environment: prod}

An optional apisix-mapping.json (aip-apisix-mapping/1) in the measurement root binds Routes to
Operations and Routes or gateway Services to application Services. No credential value or key is
stored or returned, and no plugin configuration is returned.

Evidence and limitations

The frozen expectations were written independently of the code. They were run twice on one exact
commit, with byte-identical results across the service, REST and negotiated MCP, and with a
real-source replay of captures from a pinned APISIX instance, including a revision change with stale
cursor and evidence-reference refusal. See the
I4 completion record and the
replay package. The product-value pilot is one
bounded coding-agent session (disposition CONTINUE), not user research.

Known limitations:

• The projection builds the whole selection before paging (F1), every request reads the whole
  canonical state (F2) and the evidence reference map is rebuilt per call (F3). Costs are measured
  and recorded, not bounded by an SLO.
• Environment and measurement coverage are operator assertions; the measurement is cumulative
  counters read at two settled boundaries.
• No Tyk or other gateway adapter, no hosted-demo extension, and no production-capacity claim.