Skip to content

AIP v0.6.3

Choose a tag to compare

@michaelegner michaelegner released this 11 Oct 18:47
· 90 commits to main since this release
0372797

Release story

v0.6.3 is a maintenance release: two bounded robustness fixes, no new capability. It adds no
architecture question, source family, canonical relationship, schema, claim type, limitation code or MCP tool.
The v0.6 answers are semantically unchanged.

  • Telemetry no longer stalls everything else. POST /v1/traces used to ingest a batch on the event loop, so
    REST, MCP and UI requests waited for the whole batch. Ingestion now runs in a worker thread, still one batch at a
    time.
  • One unsupported number no longer crashes the import. A source document holding an integer outside RFC 8785's
    safe range (for example an int64 or uint64 maximum) used to abort POST /api/import with an uncaught
    IntegerDomainError (#305). That
    source is now rejected with a diagnostic.

What changed for integrators

  • POST /v1/traces ingestion runs off the event loop. The request and response are unchanged (same status codes,
    same body, same evidence). Batches are still ingested one at a time, because the cross-batch HTTP correlation buffer
    depends on it; waiting batches queue on a lock, not in worker threads.
    Measured with benchmarks/traces_stall.py (real app over HTTP, real Neo4j, 3 runs per
    point; measurement, not a service-level objective or a release threshold):

    Spans in the batch Worst other-request latency during the ingest, before after
    30 about 0.4 to 1.4 s (the whole ingest) 19 to 155 ms
    300 about 1.7 to 2.2 s 18 to 31 ms
    3000 about 14.7 to 16.6 s 193 to 366 ms

    Other requests are now answered during an ingest. The ingest itself did not get faster: at 3000 spans its wall time
    was about 21 to 24 s after, against about 15 to 17 s before, with the benchmark's probe loop running continuously
    alongside it.

  • A source with an out-of-range integer is rejected, not fatal. The source gets REJECTED_INVALID and one
    DOCUMENT_PARSE_INVALID diagnostic that names the JSON Pointer of the first such integer and never its value. It
    contributes no model and no semantic-input digest. Hashing of documents inside the safe range is unchanged, and the
    value is never coerced or re-encoded.
    The discovery run is still PARTIAL: one out-of-range integer still prevents that run from committing anything.
    v0.6.3 changes an uncaught crash into a deterministic, diagnosed outcome; it does not make such a document
    importable, and it does not change the rule that only a COMPLETE run commits. Previously accepted state is left
    as it was. Each configured directory is its own run, so a bad source in one directory no longer stops the others.
    The Kubernetes mapping was affected as well (a spec.ports[].port of that size reached the same hash) and is
    covered by the same rejection.

  • Other changes since v0.6.2 (metadata and example client material only): server.json, the
    metadata-only entry for the MCP Registry, whose version is pinned to the release version by a test; a Claude Code
    marketplace for the Pitstop demo plugin and the optional mod, with a sensitive aip_token setting for installed
    plugins.

Unchanged: exactly four MCP tools in the same order, schemas/import/v0.5/*, the v0.5 and v0.6 answer schemas, the
v0.6 golden path.

Known limitations

  • Out-of-range integers are not supported. Coercing them to doubles, encoding them another way or migrating
    canonical hashes would change identity semantics and is deferred to its own decision. A document that has one is
    rejected, and its run is PARTIAL.
  • Other canonicalization failures are not covered by this fix. Only the out-of-range integer case is turned into a
    source rejection.
  • Ingestion is one batch at a time. Batches queue behind each other; there is no bound on how many wait.
  • No per-Subscription qualification. Every claim carries the publisher's qualification; per-receiver evidence
    shows only as observed references on its route. Receipt is per messaging destination (the exchange), never per
    event type.
  • AIP holds no payload or field-level knowledge and models no Intent, Assessment or document staleness.
  • Snapshot ids differ between runs (they move with ingestion); the bounded drill-down protocol (at most three
    attempts) handles a stale snapshot.
  • run.sh --live for the Pitstop demo needs the private instrumented fork; CI does not run it.
  • The plugin and the mod are example client material, removable without changing any AIP answer. The mod uses Claude
    Code's typed mod API, so it is tied to the Claude Code build.
  • Inherited: a Broker is declared evidence only (no runtime observation) and destinationBrokerMappings stays
    unimplemented.

Links