Skip to content

v0.3.3 - Agent-Ready CTI Contracts

Corrobore v0.3.3 publishes the agent-facing CTI contract corrections merged after v0.3.2. It makes confidence units explicit at every write boundary, requires agents to treat relationships as evidence-bearing assertions in their own right, and documents a deterministic readiness sequence before STIX export.

The release does not relax CTI correctness gates or make export mutate graph state. Its purpose is to remove ambiguity for tool builders and LLM workflows while preserving the engine's evidence, lifecycle, and authorization barriers.

Highlights

  • Cypher and native memory operations now document and enforce confidence on the 0..=1 scale. A rejected STIX-style value such as 90 returns guidance to use native 0.9 instead.
  • STIX objects and POST /v1/import/stix annotations continue to accept 0..=100; the OpenAPI contract and import errors now state that 90 is normalized to native 0.9.
  • Agent guidance now requires every relationship assertion to carry its own retained evidence, confidence, and lifecycle status rather than inheriting readiness from either endpoint.
  • CTI extraction guidance distinguishes source-backed Indicator -> Observed Data: based-on assertions from Indicator -> CTI domain object: indicates assertions and requires an explicit relationship-coverage pass.
  • The documented export sequence is now: complete authorized writes, read back nodes and relationships, audit relationship metadata, promote eligible records, then attempt strict export. Any late write starts a new readiness and promotion pass.

Contracts

  • Native graph metadata remains normalized. Cypher does not guess whether a number was expressed as a fraction or a percentage and rejects confidence outside 0..=1 with an actionable conversion example.
  • The STIX import adapter remains the public 0..=100 to native 0..=1 conversion boundary for both object confidence and import annotations.
  • Evidence and confidence are assertion-local. A relationship without its own valid evidence references and confidence cannot become export-ready merely because its source and target nodes are ready.
  • The documented missing-metadata and candidate-status relationship queries are executable against the supported Cypher subset and use named endpoints.
  • GET /v1/export/stix remains read-only and never promotes candidates. Strict mode remains the default correctness gate; permissive export is an explicit diagnostic partial-bundle choice, and force=true remains an explicit operator decision rather than an automatic LLM fallback.
  • Force still cannot bypass lifecycle, identity, retained-evidence integrity, relationship endpoint, licensing, provider-readiness, or authorization gates.
  • The public OpenAPI version and all workspace-owned package versions are 0.3.3; the storage manifest and record format remain V1 and JsonLinesV1.

Upgrade notes

No storage migration is required from v0.3.2. Existing HTTP and embedded callers retain the same route shapes and strict-by-default export behavior.

Tool builders should keep the boundary conversion explicit: send 0.9 through Cypher or native memory operations and 90 in STIX objects or STIX import annotations. Workflows that write relationships through Cypher should set the relationship's own evidence_refs, confidence, and candidate status, then perform readiness and promotion only after all authorized writes are complete.

Callers that already use permissive or forced export must continue to request those modes explicitly and inspect every returned diagnostic.

Known boundaries

  • Corrobore does not infer or fabricate missing based-on or indicates relationships. Source parsing and model-driven extraction remain upstream; unsupported bridges must be reported as gaps.
  • This release improves contracts, diagnostics, tests, and agent guidance; it does not add an export-side auto-promotion or retry mutation.
  • Corrobore does not parse PDF files. OCR, document segmentation, and extraction remain upstream responsibilities before evidence ingestion.
  • GitHub release archives and container tags are publication evidence only after their tag-triggered workflows complete; pushing the tag alone does not prove that those artifacts were published.
  • Enterprise CTI provider binaries remain external licensed artifacts and are not bundled in the OSS release.

Validation and provenance

Release preparation is accepted only after the merged release commit passes:

  • Rust formatting and Clippy across the complete workspace and all features;
  • the complete locked workspace test suite, including Cypher confidence, relationship diagnostic, STIX import, and export safety contracts;
  • JavaScript agent, documentation, release-note, distribution, security, and acceptance contracts;
  • a strict MkDocs build;
  • every required pull-request check on the exact commit that receives the tag.

The annotated v0.3.3 tag must identify that synchronized merged main commit. Per the release operator's instruction, successful tag push is the completion boundary for this task; the long-running tag-triggered workflows are not part of this validation pass.

Full comparison: v0.3.2...v0.3.3.