Hi everyone,
thanks for the thoughtful feedback to John6666 - for the careful read and for framing the findings as contract questions rather than vague bug reports. That perspective has been very helpful for us.
Since that review, we’ve made a lot of progress on the trust layer. The current stack now includes:
a clearer separation between claim content, occurrences, and trust outcomes,
immutable run records with versioned policy and reproducibility metadata,
directed stale marking for exact outcome scopes,
a deduplicated recompute queue with claim/lease, retry backoff, and dead-letter handling,
and a service-level orchestration path from invalidation to recompute enqueueing.
That means the architecture now records not only what the system produced, but also which inputs, policy version, and run context produced each outcome. Operator-facing endpoints to query that provenance are on the roadmap but not yet exposed.
I still welcome help with:
reproducible edge cases,
contract-level review of the current trust boundaries,
regression fixtures across SQLite and PostgreSQL,
and any mismatch between intended semantics and actual behavior.
If you spot a problem, a missing invariant, or a boundary that should be tested more explicitly, please open an issue in the GitHub repository with a minimal reproduction and a clear description of the contract you believe is violated. That is the fastest way to help us turn this into a robust, evidence-based trust platform. I am especially interested in reports around:
claim content vs. occurrence separation,
independence and corroboration semantics,
idempotency and replay behavior,
stale marking and recompute scope,
and reproducibility across database backends.
Thanks again to everyone who has taken the time to review the work — it genuinely helps move the project from working infrastructure toward a measurable and auditable trust system.