Fornax v0.0.8 — Agent Epistemic Trust Kernel (Developer Preview)

Fornax v0.0.8 — Agent Epistemic Trust Kernel

Status: Real release. Readiness-gate verdict (FORNX-392): CONTINUE,
with 3 explicitly disclosed carryovers — this is not a clean pass, and
this document does not present it as one. Full gate evidence is recorded
in the FORNX-392 Jira ticket's evaluation comment; the summary below
reflects it honestly.

What this is

Fornax v0.0.8 (Stage 9, epic FORNX-376, HVDL-15) turns Fornax's local
verification loop into a broader agent epistemic trust kernel: claims
carry explicit proof obligations, verification depth adapts to risk,
adversarial evidence is tested against a real attack corpus, and
evidence-backed trust state can move safely across agents via a
proof-carrying delegation protocol.

• Epistemic Contracts (FORNX-377/378) — a versioned claim-ontology and
  proof-obligation schema, with a satisfaction engine that evaluates
  whether real evidence actually meets a contract's requirements. A
  critical-obligation safety floor means a recommendation cannot reach
  PROCEED merely because aggregate evidence looks strong while a
  required obligation is unsatisfied.
• Adaptive verification budgets (FORNX-379) — verification effort
  scales with risk and existing evidence coverage instead of running
  either minimal checks or maximum-depth monitoring for everything.
  Destructive, credential-bearing, and unapproved-network actions remain
  refused regardless of budget or information value. Measured against
  minimal/maximal baselines on synthetic fixtures only — no real
  production workload benchmark exists yet.
• Adversarial evidence corpus and authenticity hardening
  (FORNX-380/381) — a documented threat model and a 26-fixture attack
  corpus (forged provenance, replay, capability spoofing, source
  amplification, and more), plus provenance hardening so an untrusted
  adapter cannot promote its own evidence to a higher trust class by
  setting payload metadata.
• Self-integrity program (FORNX-382/383) — a registry of 10 required
  trust-kernel invariants, each with an owning test; property-based tests
  generalizing several of them; a real 64-task concurrency stress test
  proving session isolation; and 4 Kani-verified bounded-model-checking
  proofs on receipt/delegation freshness logic.
• Proof-carrying delegation and multi-agent shared-failure detection
  (FORNX-384/385) — a delegation envelope that lets a parent agent verify
  a child agent's result from serialized bytes alone, without trusting its
  prose summary; and cross-agent dependency tracking so several agents
  sharing one underlying source cannot manufacture independent
  corroboration. A collusion hypothesis can never be emitted without
  actual supporting evidence — never from correlation alone.
• Shadow execution (FORNX-386) — isolated pre-flight verification for
  file-mutation and SQLite-migration changes, entirely local and
  disposable, with tested negative controls against path traversal,
  symlink escape, network access, and credential exposure.
• Assurance cases (FORNX-387) — a structured claim/argument/evidence/
  limitations model projected deterministically from contract-satisfaction
  results, resistant to prompt-injection-shaped evidence text gaining
  structural authority.
• Meta-verification (FORNX-388) — semantic judges and monitors are
  evaluated as fallible evidence sources, not roots of trust; an
  overconfident, factually-wrong monitor cannot force a verdict past a
  real contradiction.
• Integrity incident intelligence (FORNX-389) — a real incident-to-
  regression knowledge loop, extending existing audit/receipt primitives
  rather than building a second incident store.
• Agent Evidence Protocol (FORNX-391) — a versioned, publicly
  documented wire protocol with a genuinely independent second
  implementation (zero dependency on this repo's internal types) that
  exchanges and verifies a real proof-carrying delegation result.

Federated calibration (FORNX-390) is a completed research
investigation, not a shipped feature. Its own decision record concluded
narrow/defer: the aggregation mechanism works on synthetic data, but
no real multi-tenant demand and no real local reliability-observation
producer exist yet to justify shipping it.

Readiness-gate verdict: CONTINUE, with 3 disclosed carryovers

FORNX-392 evaluated this candidate against 10 predeclared dimensions and
11 acceptance criteria. Most measurable dimensions passed on real,
independently-verified evidence. Three real gaps are carried forward
explicitly rather than resolved or hidden:

1. A real 4-of-26 (≈15%) escape rate on the frozen adversarial corpus.
   The four escapes: forged trust-class label authenticity, cross-claim
   evidence replay, and a known O(n² log n) scalability limitation in
   the evidence-independence module under very large evidence pools.
2. No daemon/acquisition-identity binding yet (FORNX-381's own
   disclosed AC2 gap) — cross-session attribution at that specific layer
   is not yet provably fail-closed.
3. One of two targeted formal-verification proofs is unverified
   (FORNX-383) — the acquisition-authorization state machine's Kani proof
   harnesses compile but hit a real CBMC memory limit, not a design flaw
   found. The other target (receipt/delegation freshness logic) has 4
   genuinely verified proofs.

None of this release's claims should be read as "adversarial evidence
cannot bypass Fornax" or "the trust kernel is formally verified" — neither
is true yet, and this document does not say otherwise.

What this does not claim

• Not an AI lie detector. Fornax checks agent claims against captured
  evidence; it does not infer intent or detect deception from text alone.
• No universal trust score. Every verdict/state vocabulary in this
  release (satisfaction states, delegation outcomes, multi-agent signals,
  attack outcomes) is closed and never collapsed into a single number.
• A delegation envelope's digest proves the message wasn't tampered
  with — it does not prove the underlying claim is semantically true.
  Authenticity and truth are deliberately distinct throughout this
  release.
• Kani's 4 verified proofs cover one state machine, not "formal
  verification of the trust kernel."
• Shadow execution's fidelity is exactly what its own metadata
  declares — a passing shadow run is not equivalent to a production
  proof when dependencies differ.
• The Agent Evidence Protocol is a real, independently-implementable
  spec — not a ratified or standards-body-endorsed protocol.
• Multiple agents citing the same underlying source are never presented
  as independent confirmation by default (FORNX-385).

Security

No unresolved Critical/High privacy/security/integrity blocker exists in
the code merged this release. The 3 carryovers above are real, disclosed
residual risk — not defects introduced by this release's own new code,
and not silently converted into a passing grade. See the FORNX-392 gate
evaluation for full per-dimension detail.

Migration notes

All new surfaces (epistemic contracts, verification budgets, the
adversarial corpus, provenance hardening, self-integrity checks, shadow
execution, assurance cases, meta-verification, incident records, and the
protocol crates) are additive. No breaking changes to existing Evidence,
Finding, Fusion, causal/replay, or policy contracts from prior
releases.

Known limitations

• No real human-adjudicated Gold Corpus data exists (FORNX-343 remains
  founder-paused for cost control) — no calibrated real-world accuracy
  claim is made anywhere in this release.
• Federated calibration (FORNX-390) is research-only; not shipped as a
  product feature.
• See "Readiness-gate verdict" above for the 3 items carried into future
  work.

Where to go next

• FORNX-392's full gate evaluation (Jira) for per-dimension detail.
• Prior release: docs/release/v0.0.7-release-notes.md.
• Tracking epic: FORNX-376. Discovery thesis: HVDL-15.

Fornax v0.0.7 — Audit, SIEM & Data Governance

Fornax v0.0.7 — Audit, SIEM & Data Governance

Status: Real, complete release. Full QA/security evidence:
docs/release/v0.0.7-qa-signoff.md. Candidate
manifest: release/v0.0.7-candidate-manifest.json.

What this is

Fornax v0.0.7 adds tamper-evident audit and compliance infrastructure on
top of v0.0.6's enterprise policy layer:

• Tamper-evident local audit ledger — hash-chained entries with
  independent divergence checks for missing sequences, relinked previous
  hashes, and hash mismatches, plus truncated-tail detection.
• Checkpoint witnessing — periodic submission to the cloud that
  honestly reports its own divergence rather than suppressing it.
• Compliance reporting — surfaces real ledger-integrity status
  end-to-end.
• Bounded, resumable retention sweeps — never process an unbounded
  backlog in a single call.

This is a real, complete release

Stage 6c's release gate — FORNX-323,
"[Audit Integrity Gate]" — is genuinely earned, the same standard as
v0.0.6's FORNX-124. It was closed with a real adversarial test suite
spanning both fornax-core and fornax-cloud, which found and fixed a real
cross-repo TOCTOU race in fornax-cloud's tenant-data-deletion legal-hold
check (already shipped in fornax-cloud v0.0.3). There is no unfabricatable
external-evidence gap here.

Security

A fresh, independent review — separate from FORNX-323's own adversarial
testing — covered SQL-injection re-verification of every manual safety
assertion introduced by a dependency upgrade, audit-log tamper-evidence,
retention/deletion correctness, compliance-report accuracy, and
checkpoint-submission resource bounds. Zero findings.
risk_class: TRUST_BOUNDARY reflects that this ships the audit/compliance
integrity guarantee downstream trust and legal/compliance claims depend on,
not any defect. See docs/release/v0.0.7-qa-signoff.md
for full detail.

Architectural note

fornax-core's local retention is a purely on-device data-lifecycle
boundary and does not implement a legal_hold concept — that control
exists separately in fornax-cloud, scoped to centrally-stored tenant data.
This is an intentional architectural boundary, not a gap.

Cross-repo pairing

This release pairs with
fornax-cloud v0.0.3,
which ships the cloud-side audit checkpoint receipt, SIEM delivery, and the
legal-hold fix this release's own gate testing helped surface.

Migration notes

No breaking changes to existing Evidence, Finding, Fusion, causal/
replay, or policy contracts. All new surfaces (audit ledger, checkpoints,
compliance reports, retention sweeps) are additive.

Where to go next

• Full QA/security evidence: docs/release/v0.0.7-qa-signoff.md.
• Candidate manifest: release/v0.0.7-candidate-manifest.json.
• Prior release: docs/release/v0.0.6-release-notes.md.
• Tracking ticket: FORNX-402.

Fornax v0.0.6 — Enterprise Policy & Fleet Governance

Fornax v0.0.6 — Enterprise Policy & Fleet Governance

Status: Real, complete release. Full QA/security evidence:
docs/release/v0.0.6-qa-signoff.md. Candidate
manifest: release/v0.0.6-candidate-manifest.json.

What this is

Fornax v0.0.6 adds enterprise policy authoring and fleet governance on top
of v0.0.5's causal/longitudinal verification layer:

• Signed policy authoring & distribution — versioned policy-as-data
  contracts, cryptographically signed and domain-separated bundles.
• Local verified cache — offline devices continue on documented
  last-known-good semantics; a rollback-safe sequence high-water mark
  prevents replaying a stale valid bundle.
• Staged rollout & rollback — target a canary cohort, roll back or
  supersede, observe fleet-wide convergence.
• Signed revocation lists — sticky, replay-resistant; a revoked bundle
  can never be silently un-revoked by an old list replay.
• Fleet health — active/stale/degraded policy state visibility across
  enrolled devices.
• Risk-classified enforcement — fail-open/fail-closed behavior by
  action/risk class, closed by construction against an unrecognized risk
  tier.

This is a real, complete release

Unlike v0.0.4 and v0.0.5's Developer Preview framing, Stage 6b's release
gate — FORNX-124,
[POLICY & FLEET READY] — is genuinely earned. It was closed with real,
live, end-to-end cross-repo verification: real Postgres, a real fornax-cloud
server, real fornax-daemon processes, real signed artifacts, real HTTP poll
cycles. That process found and fixed one real Critical defect
(a wire-contract mismatch between fornax-cloud and fornax-core over policy
revocation) before re-verifying live. There is no unfabricatable
external-evidence gap here, unlike v0.0.4/v0.0.5's calibration-data
blockers.

Security

A fresh, independent review — separate from FORNX-124's own live-verification
pass — covered signature verification, sequence-based rollback/replay
resistance, revocation-list integrity and replay resistance, fail-closed
risk enforcement, rollout-targeting injection surface, and resource
exhaustion. Zero findings. risk_class: TRUST_BOUNDARY reflects the
stakes of a new cryptographic bundle-verification trust boundary gating
real device behavior, not any defect. See
docs/release/v0.0.6-qa-signoff.md for full detail.

Cross-repo pairing

This release's device-side policy consumer pairs with
fornax-cloud v0.0.3,
which ships the cloud-side policy authoring, rollout, bundle-distribution,
and revocation endpoints. Both halves of this capability are now formally
released.

Migration notes

No breaking changes to existing Evidence, Finding, Fusion, causal/
replay, or CLI/API contracts. All new surfaces (policy bundle, cache,
rollout, revocation, fleet health) are additive.

Where to go next

• Full QA/security evidence: docs/release/v0.0.6-qa-signoff.md.
• Candidate manifest: release/v0.0.6-candidate-manifest.json.
• Prior release: docs/release/v0.0.5-release-notes.md.
• Tracking ticket: FORNX-401.

Fornax v0.0.5 — Causal & Longitudinal Verification (Developer Preview)

Fornax v0.0.5 — Causal & Longitudinal Verification (Developer Preview) — Release Notes

Status: DEVELOPER PREVIEW / PRERELEASE. Ships the verified Stage 5
engineering scope. Does not claim the [CAUSAL READY] gate (FORNX-107) is
satisfied — see "What this is not" below. Full evidence:
docs/release/v0.0.5-qa-signoff.md. Candidate
manifest: release/v0.0.5-candidate-manifest.json.

What this is

Fornax v0.0.5 adds causal and longitudinal verification infrastructure on
top of v0.0.4's multi-signal integrity engine:

• Evidence provenance classing — claims are structurally tagged as
  observational, replayed, or interventional, so a causal claim can never be
  silently confused with a passive observation.
• Reliability & drift computation — Wilson-interval statistics over
  adjudicated cohort outcomes with an explicit minimum-sample-support floor;
  refuses to produce a numeric estimate from sparse data rather than
  guessing.
• Sandboxed counterfactual experiment runner (fornax-experiment-runner)
  — stages an isolated, path-traversal-safe, symlink-safe worktree copy to
  run interventions without touching the source tree or executing any
  subprocess/shell/dynamic code.
• Local replay engine (fornax-replay) — recomputes a frozen manifest's
  verdict for regression comparison against a prior run.

What's included (all engineering-complete, independently re-reviewed)

See docs/release/v0.0.5-qa-signoff.md for the full
per-module breakdown and security review (risk_class: FEATURE, zero
findings).

What this is not

Not a proven causal-value claim. FORNX-107 ([CAUSAL READY]) —
"independently gate on demonstrated causal/longitudinal value and safe
experiment behavior" — remains open and deferred, not satisfied, not
waived. Its gate procedure requires representative intervention
experiments, passive-vs-counterfactual comparison on frozen cases, and
contextual-reliability/drift evaluation on held-out comparable cohorts —
none of which can be produced without a real causal-experiment corpus /
labeled longitudinal dataset that does not currently exist. This release
does not fabricate that corpus or lower the gate's evidence threshold. This
gap was escalated as a genuine research/product decision on 2026-09-05 and
reconfirmed on 2026-09-10, the same treatment given to v0.0.4's FORNX-97 gap.

If you enable the experiment runner or replay engine in this release,
treat their output as engineering infrastructure for building toward a
causal-value claim, not as evidence that intervention-based verification
already outperforms passive monitoring — Fornax does not yet have real
evidence of that.

Path to the real causal-readiness claim

FORNX-343
(Stage 8, "Gold Corpus Bootstrap") is the same shared path toward a real
labeled dataset that FORNX-97 (v0.0.4's deferred gate) also depends on —
this release does not attempt to substitute synthetic or fabricated data for
it. FORNX-107 depends on that same corpus effort.

Security

Independent security/QA review of the sandboxed experiment runner, replay
engine, causal-provenance types, reliability statistics, retention, and
privacy gating found no findings (risk_class: FEATURE, verdict: PASS).
A prior, separate privacy/security pass (2026-09-02, part of FORNX-107's own
gate procedure) found and fixed two gaps pre-freeze: an orphaned
staging-directory sweep that wasn't wired into the experiment runner
(Medium), and an observer trait signature gap that limited future
extensibility without being exploitable in the current call path (Low). See
docs/release/v0.0.5-qa-signoff.md for detail.

Migration notes

No breaking changes to existing Evidence, Finding, Fusion, or CLI/API
contracts. All new surfaces (causal provenance, reliability/drift
computation, experiment runner, replay engine) are additive. Two new opt-in
privacy/egress gates (longitudinal_reliability_collection_allowed,
replay_export_egress_allowed) default closed.

Where to go next

• Full QA/security evidence: docs/release/v0.0.5-qa-signoff.md.
• Candidate manifest: release/v0.0.5-candidate-manifest.json.
• Prior release: docs/release/v0.0.4-release-notes.md.
• Tracking ticket for this Developer Preview: FORNX-399.

Fornax v0.0.4 — Multi-Signal Integrity Engine (Developer Preview)

Fornax v0.0.4 — Multi-Signal Integrity Engine (Developer Preview) — Release Notes

Status: DEVELOPER PREVIEW / PRERELEASE. Founder-authorized 2026-09-24
scoped release: ships the verified 6/7 Stage-4 engineering scope. Does
not claim the full [MULTI-SIGNAL READY] gate (FORNX-97) is satisfied —
see "What this is not" below. Full evidence:
docs/release/v0.0.4-qa-signoff.md. Candidate
manifest: release/v0.0.4-candidate-manifest.json.

What this is

Fornax v0.0.4 begins evolving Fornax from deterministic claim checks into
a multi-signal integrity system: an inspectable evidence graph, additional
independent evidence sources beyond the coding agent's own self-report,
explicit evidence-quality metadata, a fusion engine that combines
heterogeneous evidence with visible uncertainty, an optional local
semantic judge, and a decision layer (PROCEED/REVIEW/BLOCK) that explains
its own rationale rather than hiding behind an opaque score.

What's included (all Done, engineering-complete)

• Evidence Graph (FORNX-89): claims linked to supporting/contradicting/
  missing evidence with explicit provenance; missing evidence modeled, not
  inferred from empty arrays.
• Evidence Explorer (FORNX-90): local/SaaS UI to inspect the evidence
  graph behind a finding, including missing/unavailable/correlated
  evidence.
• Independent Sensors (FORNX-91): two new evidence sources beyond the
  agent's own tool-call self-report — fornax-vcs (git-native
  working-tree/commit evidence) and fornax-ci (GitHub CI-status
  evidence).
• Evidence Quality (FORNX-92): freshness/expiry, trust class,
  dependence/correlation grouping so two model-authored signals aren't
  double-counted as independent.
• Fusion Engine (FORNX-93): combines evidence with explicit
  uncertainty; reproducible for a pinned policy/version; missing/failed
  sensors never silently treated as negative evidence.
• Semantic Judge (FORNX-94): an optional local, self-hosted LLM-judge
  evidence source — one signal among many, never the sole verifier, always
  labeled model-derived.
• Decision UX (FORNX-96): PROCEED/REVIEW/BLOCK recommendation with
  visible rationale, distinct from the underlying Finding/evidence graph.

What this is not

Not a proven multi-signal effectiveness claim. FORNX-97
([MULTI-SIGNAL READY]) — "at least one multi-signal configuration
demonstrates meaningful operational improvement over baseline under
predeclared metrics" — remains open and deferred, not satisfied, not
waived. The calibration/ablation harness that would measure this
(FORNX-95, fornax-bench) is itself engineering-complete — real
reproducible manifests, fixed-risk metrics, per-sensor ablation — but has
only ever been exercised against synthetic fixtures, which by design
cannot demonstrate real-world value. No human-adjudicated labeled
integrity-outcome dataset currently exists to run that study against, and
this release does not fabricate, lower the bar for, or substitute
synthetic data for that requirement. This gap was escalated as a genuine
research/product decision on 2026-09-05 and reconfirmed on 2026-09-24
rather than silently resolved.

If you enable the Semantic Judge or additional sensors in this
release, treat their output as additional inspectable evidence, not as
a calibrated confidence signal — Fornax does not yet have real evidence
that combining these signals improves decision quality over the v0.0.1
deterministic baseline.

Path to the real calibration claim

FORNX-343
(Stage 8, "Gold Corpus Bootstrap") is the existing path toward a real
human-adjudicated dataset — it requires genuine human review
(FORNX-342,
"Corpus Adjudication"), which this release does not attempt to
substitute for. FORNX-97 is linked in Jira as blocked by FORNX-343.

Security

Real security/privacy review performed on the three new sensors (see
docs/release/v0.0.4-qa-signoff.md for detail).
One Medium finding (a verdict-inversion bug in the Semantic Judge's
response parser) and one Low finding (a redact-before-truncate ordering
defect in the same module), both found and fixed within this pass with
real regression tests. No Critical/High finding.

Migration notes

No breaking changes to Evidence, Finding, or existing CLI/API
contracts. All new surfaces (Evidence Graph queries, Fusion Engine,
Semantic Judge, Decision UX) are additive.

Where to go next

• Full QA/security evidence: docs/release/v0.0.4-qa-signoff.md.
• Candidate manifest: release/v0.0.4-candidate-manifest.json.
• Prior release: docs/release/v0.0.3-release-notes.md.
• Tracking ticket for this Developer Preview: FORNX-398.

Fornax v0.0.3 — Extensible Evidence Platform

Fornax v0.0.3 — Extensible Evidence Platform — Release Notes

Status: RELEASED. Epic FORNX-138 and all its children (FORNX-155–162,
FORNX-289–293) are Done. QA/Security sign-off (FORNX-244) is Done,
PASS — see docs/release/v0.0.3-qa-signoff.md and
docs/release/v0.0.3-security-signoff.md. Candidate frozen at
f551ec0140ba545210af2e891796f17d12ccdd21 (release/v0.0.3-candidate-manifest.json),
promoted to main via PR #161 (merge commit 40a61f4), tagged v0.0.3.
Single-repo release — fornax-core only; unrelated to fornax-cloud's own
pre-existing v0.0.3 tag ("Enterprise IAM, Compliance & Self-Hosting"),
which shares the version number by coincidence, not coordination.
Deferred to the next release: FORNX-85 (capability UX) and FORNX-301
(capability wire export), which landed after this candidate's sign-off
and are unverified against it.

What this is

Fornax v0.0.3 does not add a new user-facing capability on top of v0.0.1's
core loop (observe → extract claim → verify → report, still five honest
verdicts, still local-first with no cloud dependency on the critical path).
It answers a different, structural question: can a new provider or a new
kind of evidence be added to Fornax without rewriting core domain logic?

The answer, demonstrated rather than asserted: yes. This release generalizes
the two-provider (Claude Code, Codex) capability/evidence model into an
explicit, versioned extension contract, then proves that contract by adding
a third, architecturally distinct provider — opencode CLI — through it.

Why extensibility matters here

Fornax's core promise (checking an agent's claims against captured evidence)
is only as credible as its evidence pipeline is honest about what each
provider can and can't expose. Before this release, "what a provider can
expose" was six fixed booleans and evidence collection was ad hoc code
inline in each adapter. That worked for two providers whose integration
mechanisms happened to be somewhat similar (external hook process; file
tail) — it would not have scaled cleanly to a third with a genuinely
different mechanism, and it gave no accepted place for provider-specific
evidence to live without either forcing it into a premature "canonical"
field or throwing away its structure entirely.

This release replaces that with:

• An open, three-state signal taxonomy (Available / Unsupported / Unavailable,
  plus Unknown for "not yet assessed") instead of six fixed booleans —
  see docs/research/adapter-capability-matrix.md.
• A uniform EvidenceSensor/EvidenceSource contract with named trust
  classes and structured provenance (collection method, freshness, tamper
  boundary) — see docs/research/evidence-sensor-contract.md.
• A versioned, opt-in ExtensionEnvelope for genuinely provider-specific
  evidence, with an explicit promotion-to-canonical path and a documented
  deprecation ritual — see docs/adr/0005-schema-evolution.md.
• A practical, worked checklist for adding a new adapter —
  docs/contributing/adding-an-adapter.md.

The third-provider proof: opencode CLI

opencode (open-source, TypeScript, provider-agnostic) was selected and
integrated as an architecture-fitness test, running against a local Ollama
backend at zero API cost. It is a genuinely different integration mechanism
from both existing adapters: an in-process plugin the provider's own runtime
loads and invokes directly, rather than an externally spawned hook process
(Claude Code) or a tailed transcript file (Codex).

Headline finding: adding Provider::OpenCode and running
cargo check/cargo clippy --workspace --all-targets -- -D warnings found
zero unexpected core coupling — no file in fornax-daemon,
fornax-store, or fornax-verify needed to change to add a third provider.
opencode's exit-code signal (tool.execute.after's output.metadata.exit)
is also a first for Fornax: a literal, non-heuristic exit code, where both
existing adapters rely on a heuristic (Claude Code) or a provider-shape-
dependent partial signal (Codex).

The transport leg — plugin → adapter binary → daemon over a Unix domain
socket — was built in the same ticket but explicitly disclosed as not yet
run end-to-end. A follow-on ticket (FORNX-291) closed that gap: a real
opencode session was driven through the real shipped plugin file, the real
fornax-hook-opencode binary, and a real running daemon, with the daemon's
own on-disk SQLite store inspected afterward as independent proof of
receipt. That work found and fixed one real bug (an unhandled error on the
spawned child process could crash opencode itself, not just the capture
pipeline) and left a permanent CI regression
(crates/fornax-adapter-opencode/tests/live_transport.rs); a second ticket
(FORNX-292) fixed a flaky assertion in that same test's polling logic. See
docs/research/0003-opencode-live-transport-verification.md for the full
evidence trail.

Exact supported scope

Provider	Status	Primary integration mechanism
Claude Code	Supported	External hook process (PreToolUse/PostToolUse/Stop/SessionStart/SubagentStart/SubagentStop)
Codex CLI	Supported, real capability gaps vs. Claude Code	Rollout-file tailing (hooks are opt-in/admin-suppressible, secondary at best)
opencode CLI	Experimental — architecture-fitness proof, not production-hardened parity with the other two	In-process plugin, spawning a long-lived companion binary over stdin

See docs/research/adapter-capability-matrix.md's "Consolidated
compatibility matrix" for the exact, code-grounded per-signal support table
across all three providers — do not assume symmetry between any two of
them.

Known, disclosed limitations of the opencode integration (not silently
rounded up to "supported"):

• Fully autonomous local-Ollama tool-calling under opencode's real
  production-size system prompt does not work reliably on any model tested
  — both the fixture-capture work and the live end-to-end proof stand a
  deterministic stub in for only the LLM's own turn. Everything downstream
  of that one stubbed response (the real process opencode spawns, its real
  exit code, every hop through the real plugin/binary/daemon) is genuine,
  unstubbed code.
• FinalResponse is Unavailable: the real event stream carries it, this
  adapter version doesn't yet translate it.
• SubagentLifecycle is Unsupported: no such hook exists in opencode's
  Hooks interface at all.
• fornax export-spool of an opencode session will be rejected (HTTP 422)
  by fornax-cloud's ingest API today — that repo's ingest boundary still
  enforces a closed, 2-variant Provider enum. Local monitoring is
  unaffected; cloud sync of an opencode session is not yet supported.

Not shipped, and not implied by this release: a plugin marketplace, a
dynamic/runtime extension-loading system, or general third-party adapter
distribution. opencode is one concrete, demonstrated integration built and
shipped by this project, proving the architecture generalizes — not a
mechanism for arbitrary external code to attach to a running Fornax daemon.

Security review findings (FORNX-244) — both fixed before release

Found and fixed during this release's QA/Security sign-off pass, not
shipped as known limitations:

• ExtensionEnvelope redaction bypass (SEC-v0.0.3-0001):
  fornax-daemon's redaction boundary (docs/privacy-redaction-policy.md)
  scanned Evidence::payload before persistence but not
  Evidence::extension. ExtensionEnvelope::fields is deliberately
  untyped, provider-specific JSON — this release's opencode adapter is the
  first real producer of one (tool-call title/timing telemetry) — so this
  was a real, structural gap. Fixed: redact_json now applies to
  extension.fields/.unknown the same way it already applied to
  payload.
• Cross-provider capability-cache spoofing/downgrade
  (SEC-v0.0.3-0002): fornax-daemon's in-memory capabilities cache was
  keyed only on provider-controlled session_id, so a same-session
  announcement from a different provider could silently overwrite another
  provider's cached capabilities — a real downgrade path that could
  suppress verification. Fixed: a cross-provider overwrite of an
  already-cached session is now refused.

See docs/release/v0.0.3-security-signoff.md for the full findings,
evidence, and regression tests.

Migration notes

Nothing in this release breaks an existing v0.0.1 adapter, client, or
on-disk record. Every schema change is additive:

• runtime_capabilities gained nullable schema_version/signals columns
  (0003_capability_signals.sql); the original six boolean columns are kept,
  not dropped.
• evidence gained nullable source (0004_evidence_source.sql) and
  extension (0005_evidence_extension.sql) columns.
• Every new field added to an existing struct across this release
  (EvidenceSource's collection_method/collector_version/freshness/
  tamper_boundary, Evidence::extension) either defaults to None or to
  an explicit, honestly-named "unknown"/"pre-provenance" value on
  deserialize — never a fabricated-looking guess. No existing row needs
  backfilling and no existing consumer needs to change to keep working.
• No adapter's public trait surface (AgentAdapter, CapabilityProbe)
  changed shape; Provider gained a third variant (OpenCode) additively —
  FORNX-161 confirmed cargo check/clippy --workspace pass with zero
  changes required outside fornax-types itself.

$FORNAX_HOME's on-disk schema stability caveat from the v0.0.1 release
notes is unchanged by this release: these migrations were verified additive
on top of a schema that already includes the v0.0.1-era tables, not
independently re-verified against an untouched v0.0.1 database file. If in
doubt, the v0.0.1 guidance still applies — back up or discard
$FORNAX_HOME before upgrading.

Where to go next

• Addi...

Fornax v0.0.2 — Real Beta Product (Stage 2)

Fornax v0.0.2 — Real Beta Product — Release Notes

Status: RELEASED. QA/Security sign-off (FORNX-241), Release Docs
(FORNX-218) and the Stage 2 epic (FORNX-64) all passed/Done — see
docs/release/v0.0.2-qa-signoff.md for the full evidence. See
release/v0.0.2-candidate-manifest.json for the frozen 5-repo SHA pin.
Tags: v0.0.2 on fornax-core/fornax-infra/fornax-docs/fornax-website;
fornax-cloud's pre-existing v0.0.2 tag (created 2026-09-18, before this
candidate's frontend deployment/TLS work existed) is a historical
premature marker left untouched — the authoritative fornax-cloud release
marker is v0.0.2+corrected.fd5a543. FORNX-242 (Release) is complete;
FORNX-243 (Post-Release) follows.

What this is

Fornax v0.0.2 turns the locally-proven v0.0.1 vertical slice into the
backend and API surface for a real Internet-facing Beta product, without
weakening the local-first trust boundary: raw evidence stays local by
default, upload is policy-controlled and redacted before it ever leaves
the machine, and the local hot path never requires cloud access.

This release is about fornax-cloud (the companion cloud-side repo) far
more than fornax-core. fornax-core has no v0.0.2-specific scope — the
v0.0.2 candidate pins it at the same commit as v0.0.1.

What's included (fornax-cloud)

• Device onboarding (FORNX-150/151): self-service device
  register/rotate/revoke over HTTP, least-privilege ingest credentials, a
  device list with self-reported and empirically-observed capability
  metadata. See fornax-cloud's README.md "Beta device onboarding" section
  for the exact API contract.
• Authenticated ingest hardening (FORNX-75/282): the ingest gateway
  requires a valid device credential; uploader token failures fail fast
  instead of silently quarantining every item (FORNX-283).
• Beta observability (FORNX-77/153): structured logging reaching
  stdout correctly, alerting groundwork for Cloud Run/Pub/Sub/DB.
  Diagnosable-from-telemetry failure modes, no raw payloads in operational
  logs.
• Privacy fixtures and migration coverage (FORNX-79/78): local privacy
  fixtures for redaction testing; migration tests covering both fresh and
  previous-schema Alembic states.
• Evidence Explorer + decision UX (SaaS) (FORNX-301/303/305):
  capability-driven frontend/backend split, evidence explorer, decision UX
  for the hosted dashboard.
• Reliability fixes: pub/sub device-check hardening, sensitive-path
  redaction (FORNX-284/286), accepted-counter no-op conflict fix
  (FORNX-58), LRU cache settings leak fix (FORNX-294), backend startup
  without Application Default Credentials (FORNX-300).
• Provider-neutral billing foundation (FORNX-46, landed under
  fornax-cloud's own v0.0.3 branch prefix per its actual PR history —
  see release/v0.0.2-candidate-manifest.json's notes and
  docs/adr/0003-billing-entitlement-and-provider-boundary.md): sandbox-only
  Dodo checkout/webhook/entitlement, not part of v0.0.2's shipped scope.

What this is not

• Not self-service today via SSO. SSO is the intended primary sign-in
  path (FORNX-111/FORNX-309) but has no live Keycloak instance in this
  environment yet; the documented break-glass device-credential path is
  the only one exercised live so far. Device registration itself is
  genuinely public and self-service (POST /v1/devices/register,
  unauthenticated by design, create-only, 409-on-collision) — verified
  live against the real public Beta endpoint, not merely implemented.
• No user/tenant/account system beyond device identity and
  session/org membership. Confirmed by FORNX-151's implementer: device
  identity plus the session/org model added since are the identity
  primitives that ship in v0.0.2 — there is no separate "user account"
  concept beyond that.

What's now live and verified (see docs/release/v0.0.2-qa-signoff.md for full evidence)

FORNX-241 (QA/Security assurance) has run across three passes (2026-09-18
partial, 2026-09-19 post-FORNX-137-cutover, 2026-09-19 frontend
deployment) and passed. Summary — full evidence, real commands, and
disclosed gaps are in the QA sign-off doc, not repeated here:

• Real, publicly reachable Beta backend (fornax-backend/fornax-ingest
  on Cloud Run, horonomy-lab/products/fornax/beta), public ingress
  (FORNX-137, owner-approved 2026-09-19).
• Real, publicly reachable Beta frontend (fornax-cloud/frontend, a
  static Vite/React SPA) deployed to Cloudflare Workers static assets at
  https://fornax.horo.run (FORNX-241, founder-approved architecture
  decision 2026-09-19).
• A real Claude Code session (this campaign's own) and a real Codex
  session synced end-to-end through the public ingest pipeline, including
  live proof that local pre-upload redaction is a real, non-bypassable
  privacy boundary (1478 real items quarantined, never uploaded).
• fornax-cloud backend: 598 passed/9 skipped/0 failed, clean
  ruff/mypy. Rust workspace: 91 passed, clippy clean. Frontend: 86/86
  tests, typecheck/lint clean, plus a live XSS-negative render check.
• Two real defects found and fixed live during this QA work (FORNX-369,
  FORNX-370), each with a regression test.
• Genuinely disclosed remaining gaps (not rounded up to a pass): no load/
  sustained-traffic test; api.fornax.horo.run/ingest.fornax.horo.run
  have no TLS certificate yet — root-caused to a Workers Route vs. Custom
  Domain distinction (only a Custom Domain auto-provisions a cert) plus a
  pre-existing DNS record blocking the fix, which needs an owner-granted
  DNS-write-scoped token (see docs/release/v0.0.2-qa-signoff.md); both
  have a working alternate path today (same-origin proxy for the
  frontend); no live SSO/OIDC test (no Keycloak instance in this
  environment).

Migration notes

No fornax-core schema or client changes in this release (no v0.0.2
fornax-core scope). fornax-cloud's Alembic migrations are additive and
covered by test_migrations.py's fresh-and-previous-schema tests.

Where to go next

• Beta device onboarding API contract: fornax-cloud/README.md.
• Billing/entitlement boundary: docs/adr/0003-billing-entitlement-and-provider-boundary.md.
• v0.0.2 candidate manifest: release/v0.0.2-candidate-manifest.json.
• v0.0.1 release notes (prior release): docs/release/v0.0.1-release-notes.md.
• Release execution record: FORNX-242. Post-release verification: FORNX-243.

Fornax v0.0.1

Fornax v0.0.1 — Local Evidence MVP — Release Notes

Status: published. Tag v0.0.1 at 9e75d95ea290223b8ca143cb1e4fd9756dc675e8
(fornax-core) and 84f02a0c8c0a14ca64176c22799ba9f4b50c1b4f (fornax-cloud).
See release/v0.0.1-candidate-manifest.json for the machine-checkable
manifest and docs/release/v0.0.1-qa-security-signoff.md for the QA/Security
sign-off evidence this release is built on.

What this is

Fornax v0.0.1 is the first tagged release of an evidence-first integrity
system for coding agents. It answers one question in real time: what
should I believe about what this agent is telling me, given the evidence
currently available?

It watches a Claude Code or Codex CLI session, captures immutable evidence
(tool calls, exit codes, transcripts) as the session runs, and checks the
agent's own claims against that evidence — surfacing one of five verdicts,
never a made-up trust score:

VERIFIED · UNVERIFIED · CONTRADICTED · REVIEW · UNAVAILABLE

What's included

• A local daemon (fornax-daemon) with an on-disk SQLite store, a Unix
  domain socket, and a localhost HTTP API + dashboard. No cloud
  dependency on this path.
• Adapters for Claude Code and Codex CLI. These are not equivalent —
  see docs/research/adapter-capability-matrix.md for the exact,
  empirically verified differences (Codex's primary integration is
  rollout-file tailing, not hooks; several Claude Code hook capabilities
  have no Codex equivalent yet).
• A CLI (fornax status / fornax detail) and dashboard showing the same
  claim/evidence/verdict/rationale.
• Optional export to a local, cloud-shaped stack
  (fornax-uploader → ingest → Pub/Sub emulator → backend → Postgres →
  SaaS UI) for anyone who wants to run the full pipeline locally. Cloud
  sync is off by default and opt-in
  (FORNAX_CLOUD_SYNC_ENABLED).

Reproduce the core "aha moment" from a clean checkout with the Quick Start
in README.md — no cloud account, no external service, one terminal.

What this is not

• Not a hosted Beta or production SaaS product. Nothing is deployed for
  you; the cloud-shaped stack above is something you run locally if you
  choose to.
• Not an enterprise governance product.
• Does not perform causal verification or deception/lie detection. Fornax
  checks stated claims against captured tool-call evidence — it does not
  infer intent.
• Not a finished, stable on-disk format. $FORNAX_HOME's schema may change
  in a later version without a migration path yet.

Known limitations

• Codex CLI support has real capability gaps versus Claude Code (see the
  adapter capability matrix linked above) — hooks on the Codex side are
  opt-in, unstable, and can be admin-disabled; the durable integration
  point is the rollout-file tailer.
• npm audit on the docs site (Docusaurus dev-server dependency chain)
  currently reports findings that affect the local dev server only, not
  the published static site — see
  docs/release/v0.0.1-qa-security-signoff.md for the full disclosure.
• No live fuzzing, no live Playwright script-injection pass, and no full
  live-stack redaction-pipeline run were performed for this release — this
  is disclosed explicitly, not rounded up to a pass, in the sign-off
  record.

Where to go next

• Quick Start: README.md.
• Architecture invariants: docs/adr/0001-architecture-invariants.md.
• Adapter capability matrix: docs/research/adapter-capability-matrix.md.
• Full QA/Security evidence: docs/release/v0.0.1-qa-security-signoff.md.
• Frozen candidate manifest: release/v0.0.1-candidate-manifest.json.