No citation, no claim.
AI summaries and decision records should link back to the source artifacts that support them. Trust is earned through traceability, not tone.
Public trust and data boundaries
What Verachi reads, what it stores, and how trust stays visible.
Verachi is a cited memory layer for delivery decisions. It is designed to sit on top of the systems your team already uses, keep primary sources primary, and make evidence traceable instead of opaque.
Primary systems stay primary.
Verachi stores a memory layer of cited summaries, metadata, and relationships so teams can find and reuse decisions without moving their source systems into Verachi.
Prospects can verify the trust path before login.
This page, the public product story, privacy, and terms are available without an auth redirect so trust review can happen before rollout.
Connected Systems
Launch support is narrower than the full vision on purpose.
The current public posture focuses on the decisions wedge. Verachi connects to the systems that make that wedge useful, then keeps the evidence boundary explicit.
| System | What Verachi reads | What Verachi writes | What stays primary |
|---|---|---|---|
| Slack | Decision discussions, capture cues, and linked evidence needed for cited records. | Launch posture is read-first. Any Slack-side write behavior should remain explicit and reviewable. | The original thread, participants, and source conversation history. |
| Jira | Issues and work context linked to decisions. | Launch posture is link-and-reference first, not silent workflow mutation. | The system-of-record for work items and operational workflow state. |
| GitHub | Pull requests, commits, and related engineering context used as decision evidence. | Launch posture is read-first. | Code review, repository history, and implementation artifacts. |
| Uploaded documents | Files you intentionally upload as evidence sources. | Verachi stores the uploaded artifact metadata and the extracted evidence needed for retrieval. | Your existing docs remain primary if they already live elsewhere; uploads are an explicit evidence path. |
| Verachi | Cited summaries, metadata, relationship edges, audit events, and trust signals inside the workspace. | Decision records, links, audit history, notifications, and trust-facing summaries inside Verachi. | Primary source systems still own the original conversations and work artifacts. |
Storage Posture
Verachi stores the memory layer, not a shadow copy of your operating systems.
Decision records that can be cited and reused.
That includes summaries, relationship edges, confidence signals, audit events, and other metadata needed to make decisions findable and explainable across the workspace.
A wholesale copy of every connected system.
The product direction is layer-first. Teams should be able to move faster because evidence is connected, not because Verachi tries to replace Slack, Jira, or GitHub.
Trust language should match implementation.
When product posture changes, the in-app trust UI, public trust docs, and operator runbooks should move together. Drift is treated as a product problem, not just a copy issue.
Citations & Confidence
Trust comes from nearby evidence, not hidden model behavior.
The product contract is simple: users should be able to see why an answer exists, what evidence supports it, and how certain the system is.
Each claim should point back to source artifacts.
Slack threads, Jira issues, pull requests, and uploaded documents remain the verification path. Users should be able to inspect the original evidence instead of trusting a black box summary.
Confidence should explain itself.
High confidence means the answer is well-supported by direct evidence. Low or missing confidence should be visible and should push the user toward the source, not hide uncertainty.
Relevance should be explainable.
Notifications, summaries, and related-decision surfaces should make it clear which artifact, rule, or event caused the system to surface something to the user.
Evaluate Before Login
Use the public path for trust review, buyer evaluation, and rollout prep.
Trust and data boundaries
Use this page as the source of truth for what is connected, what is stored, and how citations and confidence are meant to work.
Review connected systemsProduct story and demo path
Use the public story and sales surfaces to evaluate the current launch wedge and determine whether it matches your team's first rollout case.
Open the product storyLegal and operator review
Privacy and terms remain public. The goal is to avoid a dead-end auth redirect when procurement, security, or legal review starts before a workspace is created.