AIP v0.8.0

v0.8.0 is a demonstration release. Its promise, assessment and projection semantics are
experimental and do not become a v1.0 contract by appearing here. It claims no product value;
that is validated afterwards with a target customer.

The question

A modernization moves one bounded context of a running system to another broker. The move is safe
only if every binding that crosses the boundary of the moving context is known before the move and
still holds after it. v0.8.0 asks:

Can AIP make the consequences of a cross-boundary migration visible: which bindings cross the
boundary of the context that moves, which of them are declared, what the evidence establishes, and
how a coding agent uses that picture to plan and carry out the move?

The showcase answers it on Sokol111, a multi-tenant e-commerce system whose services exchange
events through one Redpanda broker. The move: Catalog Management (the Catalog and Image
services) goes from Redpanda to Apache Kafka, with MirrorMaker 2 bridging the two brokers.

Before the move: what is declared, and what the evidence establishes

Sokol111's documented architecture says that Catalog Management publishes product and category
events to the storefront. The broker evidence shows more. Catalog and Image also consume tenant
events from Store Provisioning, and the storefront also consumes attribute events from Catalog
Management. No document names these bindings. A move planned from the documents alone would not
bridge them.

AIP shows this as the binding picture: one row per consumer Service × Topic × broker, with the
crossing of the boundary and the status of the promise and of the observation. Before the move it
gives nine rows on Redpanda.

The agent's plan and the move

A coding agent (claude-opus-5-5 in Claude Code, headless) read the binding picture through AIP's
MCP interface, planned the move and carried it out. Its plan cites the AIP claims it relies on. The
plan was frozen before the first command that changed the environment.

After the move: the binding picture on both brokers

The operator captured the consumer-group state of both brokers after the move; AIP imported the
captures and produced the after-move binding picture. Its answer equals the reference that was
committed before the run (Proof C passed). Each broker keeps its own Topic ids, and AIP does not
establish delivery across the brokers (CROSS_BROKER_DELIVERY_NOT_ESTABLISHED).

What an instrument measures is not what people conclude from it. Each claim names the instrument
that establishes it:

Claim	Established by
group state and topic assignments per broker, before and after, attributed to Services	AIP
offsets, lag, replication progress	broker tools (rpk, kafka-consumer-groups)
the tested scenarios pass after the cut-over: a new shop with a product and its image, a category update, an attribute update	the functional test

The showcase outcome, as recorded

The run's acceptance results are recorded in the
I4 completion record. The run did not meet every
acceptance check:

Check	Result
The keys (E1)	Met: the plan answer key, the task card and the Proof C reference are unchanged since before the run
Independence (E2)	Met: the plan was frozen before the first command that changed the environment; both transcripts are kept; the audit's hits were refused planning commands, waived by the owner with that evidence
Proof A: the agent's plan against the plan answer key written before the run	K1–K5 and K7 matched; of the K6/K8 sub-checks scored by the owner, 4 matched, 6 differed and 1 was missing, each with a recorded reason
Proof B: the AIP claims the plan cites (E4)	Not met. The bindings K1–K4 are covered, but one citation (a plan item that names only a snapshot id) does not resolve
Proof C: the after-move answer against the reference (E5)	Passed
Configuration checks and ground truth (E6)	Not met. The agent turned checkpoints off on the Kafka → Redpanda flow, which fails the checkpoint rules for that flow. Replication, consumer lag, the offset hand-off, the Helm change and the functional test passed
The report (E7)	Met
Replay of the frozen package (E8)	Qualified. The replay passes, but the snapshot ids and evidence refs depend on the declarations' absolute source_file paths, so it does not verify their exact equality or fresh citation resolution (deviation accepted by the owner)

The agent's checks failed twice before the cut-over. Each time it stopped and reported, and the owner
decided under the stop rule that it should continue with its own fix as a recorded amendment. Both
decisions are listed in the report.

The report

The showcase report is one static HTML page built only from the frozen inputs. It is attached to
this release as report.html, byte-identical to
i4-evidence/report.html (SHA-256
3e6e51a1714d54dc8526419cd60199572f14a78d01c643759aa739ce1139bb1f). The frozen run package, with
its SHA256SUMS, is i4-evidence/.

What changed in AIP

• Experimental get_binding_picture MCP tool and its REST twin (POST /api/binding-picture,
  POST /api/binding-picture/evidence). They exist only when config.yaml sets:

  architecture_intelligence:
    experimental:
      binding-picture: true

  With the setting off (the default), the tool list stays at six, the binding-picture routes do not
  exist, and the six tools' answers are unchanged for inputs that v0.7.2 accepted. See
  docs/mcp.md; the frozen schemas are in
  schemas/architecture_intelligence/v0.8/.

• EventCatalog source: domains, owners and sends/receives become a promise record kept apart
  from Current State.

• AsyncAPI: a Topic channel without operations is accepted. A document whose channels are all
  topic-only, rejected before, now imports; documents accepted before map to byte-identical output.

• get_destination_consumers: the destination_id and broker_id fields now have descriptions
  in its request and answer schemas. Its answers are unchanged.

• Import report schemas accept the event-catalog source kind and its five EVENTCATALOG_*
  reason codes (additive).

• The locked pydantic, fastapi, openai and neo4j move to newer patch or minor versions
  (CHANGELOG).

Product, Producer and MCP server version become 0.8.0. See the CHANGELOG.

Disclosures

• The EventCatalog and its owners are generated for the showcase from Sokol111's two architecture
  documents by a fixed rule. Its entries count as confirmed promises by assumption; the service teams
  did not make them.
• The topic inventory, the producer and Service declarations and the consumer group → Service
  mapping are authored from source and configuration.
• The second broker and the bridge are authored for the showcase: a local Apache Kafka stands in for
  a managed platform, and Sokol111 itself runs one Redpanda broker.
• Local adaptations, none committed to a Sokol111 repository: MinIO from frozen Bitnami images,
  Logto pinned by digest, the k3d host adaptations, a host DNS workaround, and the Logto seed run a
  second time.
• The agent saw a task card with the goal and the safety constraints only. It did not see the answer
  key, the reference runbook, the specifications or the web. Its transcripts were audited; the hits
  were planning commands that were refused before they ran, and the owner waived them with that
  evidence.

Known limitations

• An attachment establishes that a consumer group was attached to a topic at capture time. It does
  not establish which event types the consumer handles, or an end-to-end event flow.
• Producers are declared, not observed.
• AIP's snapshot id includes the absolute source_file path of each imported AsyncAPI declaration,
  so the same declarations at another path give another snapshot id and other evidence refs.
• The showcase is one run on one system with one agent. It is an observation, not a measurement.
• The public hosted instance is not redeployed with this release.

Evaluate it on your own architecture

This release shows one move in one system. The question applies to any change that crosses a
boundary: which bindings cross it, which are declared, and what the evidence establishes before and
after. We invite you to ask it of your own architecture with AIP.