# About Trinity

Project overview for Trinity as a Hermes-first autonomous acquisition platform.

Status: implemented
Version: latest
Review: source-backed

## Summary

Trinity is a production-grade autonomous acquisition operating system built on Elixir, Phoenix LiveView, Postgres, Oban, hosted Hermes, NVIDIA/Nemotron, Stripe, Gmail, ToolRouter, and a narrow Jido policy firewall.

The system is designed around one concrete business loop: a buyer or lead requests an acquisition snapshot, Stripe turns that request into revenue proof, Trinity creates CRM and order records, Hermes plans the work, NVIDIA reviews/scoring layers produce structured decisions, Gmail drafts or approved sends execute through project-scoped account mailboxes, and the ledger shows exactly what happened.

## Revenue Mode offer

| Step | System of record | Agent role | Proof boundary |
| --- | --- | --- | --- |
| Snapshot request | Landing/request controller and built-in CRM | Identify lead context and propose next action | Contact, company, deal, source event |
| Stripe payment | Revenue context and Stripe webhook event | Prepare checkout/follow-up only through approved tools | Checkout session, order, RevenueEvent |
| Paid opportunity | Built-in CRM | Maintain deal stage and evidence | Deal, activity, order intake |
| Acquisition run | Project/run context | Plan, draft, score, request approvals, create artifacts | RunEvent, Hermes session, approval, artifact |
| Model review | ModelRouter and NVIDIA route | Score leads, review copy, QA deliverables | ModelDecision and ModelInvocation |
| Outreach | Gmail adapter and inbox primitives | Draft or reply only after policy approval | Draft, thread, message, ToolCall |
| Delivery | Artifact and proof contexts | Generate documents, summaries, and graphs | ProjectArtifact, ledger, audit event |

## Hermes-first platform stance

Trinity treats hosted Hermes as the agent runtime and Phoenix as the product control plane. Hermes receives bounded task packages, project context, source refs, approval state, and tool outputs. Phoenix keeps durable state, account boundaries, approvals, provider readiness, and audit proof.

| Layer | Responsibility | User-facing label |
| --- | --- | --- |
| Phoenix and LiveView | Public pages, operator UI, approvals, proof, account controls | Trinity |
| Hosted Hermes | Agent work, planning, task execution, skill reuse | Hermes |
| Jido content firewall | Narrow policy execution and data-poisoning checks before runtime handoff | Hidden safety layer |
| NVIDIA NIM and Nemotron | Structured model scoring, safety review, QA, decision evidence | NVIDIA intelligence layer |
| ToolRouter | Audited boundary for Stripe, Gmail, Hermes, NVIDIA, and other side effects | Tool proof |

## What makes the system unusual

| Capability | Why it is hard | Trinity approach |
| --- | --- | --- |
| Agents that earn | Payment must create durable, idempotent business records | Stripe checkout/webhook path writes orders, revenue events, deals, and ledger proof |
| Agents that spend | Autonomous purchases need caps, identity, approvals, and replay protection | Spend requests become ApprovalRequests and ToolRouter calls with idempotency keys |
| Agents that operate | Email, CRM, docs, and artifacts need real side effects without credential exposure | ToolRouter adapters execute only after provider readiness and policy gates |
| Agents that learn safely | Skills and memories can leak between tenants if stored globally | Hermes profiles and skills are scoped to project/account/global-core boundaries |
| Agents that read external docs | Email/docs can contain indirect prompt injections | Jido-backed content firewall quarantines unreleased content until human release |
| Agents with visible proof | Model and tool outputs are often opaque | ModelDecision, ToolCall, AuditEvent, ledger, and artifact records preserve evidence |

## Technology posture

Trinity uses Phoenix LiveView because operators need live control over approvals, runtime state, CRM work, inbox work, and ledger proof without giving browser code business authority. It uses Postgres and Ecto for tenancy, constraints, source-of-truth records, and idempotency. It uses Oban for durable retries and background work, PubSub for live updates, and BEAM supervision for resilient runtime processes.

Gmail follows the same posture. The platform owns one Google OAuth application, each account connects its own mailbox, each project selects an account-owned sending alias, and OAuth tokens stay behind credential-vault refs. Hermes receives readiness and mailbox/alias refs, not raw OAuth token material.

The vendor stack is intentionally composed rather than decorative: [Hermes](/docs/hermes) performs hosted agent work, [NVIDIA](/docs/nvidia) produces model decisions and safety review, [Stripe](/docs/stripe) powers revenue and future guarded spend, [Jido](/docs/jido) protects runtime handoff, and [ToolRouter](/docs/concepts/toolrouter) controls all external side effects.

## Public documentation contract

- Deep agent research by Hermes-style crawlers.
- Clear separation between implemented, configured, fallback, and planned behavior.
- Direct links to official vendor documentation.
- Source-backed claims tied to local modules and runbooks.
- No credential values, private account data, raw model context, or hidden reasoning.

## Primary source links

- [Vendor and integration reference](/docs/reference/vendor-map)
- [Technology stack reference](/docs/reference/tech-stack)
- [Hermes Agent docs](https://hermes-agent.nousresearch.com/docs/)
- [Phoenix LiveView docs](https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html)
- [NVIDIA NIM API reference](https://docs.nvidia.com/nim/large-language-models/latest/api-reference.html)
- [Stripe Checkout Sessions API](https://docs.stripe.com/api/checkout/sessions)


Source paths:
- `README.md`
- `docs/ARCHITECTURE.md`
- `docs/TRUE_VALUES_READINESS.md`