1Why the foundation must be open
We will keep buying AI: from model providers, specialist vendors and products that do not exist yet, and our own engineers will build some. Each of those is built to be excellent inside its own boundary. None of them is responsible for the ground they share: our knowledge, prepared once, governed once, and served to all of them. Trilivy proposes to be that ground. A foundation has obligations a normal product does not:
| A foundation must be… | Because… | So Trilivy provides… |
|---|---|---|
| Inspectable | Everything above it inherits its behaviour; our architects must read the logic, not a description of it | Full source, plus instrumentation that shows the real payload of a live request |
| Open to anything | Next year's tool is not on anyone's compatibility list | Source access, so an integration is ordinary engineering, not a request to a vendor |
| Neutral | A foundation that favours one model provider becomes that provider's sales channel | LLM-agnostic design: providers are configuration, routable per workload |
| Durable beyond its supplier | Everything we build accumulates on it | Technology transfer: our team can operate and extend it without Trilivy |
2Three commitments
Open source
We receive the source of what we run: not an API surface or a plugin sandbox, the system. We can verify instead of trusting, satisfy an auditor with evidence, and change what does not suit us.
Reverse engineering
Explicitly permitted and actively supported. We can take it apart, trace the calls, instrument it, and see exactly how an answer was produced, while it runs.
Technology transfer
Our engineers are taught the system until they can operate, modify and extend it without Trilivy. Source we cannot maintain is an archive; transfer makes it a capability.
3Reverse engineering in practice
The platform is built to be inspected live, not only read:
- The DEV switch. On the production chatbot page, an administrator clicks DEV and gets a second row of controls: pick the model, the grounding mode, the knowledge group, simulate a lower security clearance, turn agents on and off. Ask the same question again and compare.
- Debug payload and prompt inspector. Every call behind a message, the passages retrieved, the system prompt section by section, and the exact request sent to the model.
- The grounding ladder. One question in four modes (raw model, model with our rules, our documents plus model, our documents only) shows how much of each answer comes from our knowledge.
- Every pipeline stage is a readable file (load, split, embed, index, retrieve, rerank, ground), with 111 technical documents beside it and a live API reference listing every endpoint on our instance.
The DEV row is gated on the server: ordinary users see the production page, and debug data is never sent to their browser.
4Building on the platform with AI coding agents
Because we hold readable source, our developers or our integrator can point an AI coding agent (for example Claude Code, GitHub Copilot or Cursor) at the platform and have it explain the system before it changes anything. The coding agent runs at build time, in the developer's editor; the applications it helps build do not depend on it.
The sequence Trilivy recommends
- Map an existing app. Ask the agent to explain an example application end to end, quoting the lines it relies on.
- Isolate the difference. Ask what differs between a simple app and a richer one, and why. This is the highest-value question.
- Learn the platform contract. Have it read the retrieval endpoint and helper interfaces, so the new app calls them instead of re-implementing them.
- Build from a written specification. Paste the specification, ask for the file list and a plan first, and approve before any code is written.
Four rules to give the agent every time
| Rule | Why |
|---|---|
| Read freely, write in one place | It may read anything in the tree but writes only in the new app's own folder |
| Import, don't copy | Reuse the platform's helpers and endpoints; a copied helper drifts |
| Never edit a shipped file | Extensions live beside the platform, so updates stay easy to take |
| No hardcoded configuration | Keys, models, providers and paths come from the configuration table, never from code |
A five-second check closes every session: version control must show changes only in the new app's folder. For agents rather than apps, the platform's Agent Factory provides versioned blueprints with cost caps, a mandatory test file and an uninstall path.
Coding agents are a reason to buy the foundation, not to skip it
AI coding tools make writing code much cheaper. They do not remove the need to decide what the system should do, how its parts fit, how retrieval quality is measured, how knowledge is governed, and how it survives production use. That is the 450–650 person-months in Part B3. The fastest path is to buy the finished foundation and let coding agents build our specific applications on top of it. And when a coding agent needs our architecture documents, security standards or runbooks, it can read them through Trilivy's MCP connection, like any other assistant.
5Objections, answered
| Objection | Answer |
|---|---|
| "If we hold the source, we become responsible for it." | Holding source does not oblige us to maintain it; it removes the need to ask. We can still buy updates, support and development, as a service we could do ourselves and choose not to. |
| "Open source means weaker security." | The cryptography that protects global finance is fully published. Strength comes from keys and scrutiny, not secrecy. Our security team can verify the authentication path, data flows and logging instead of accepting a vendor's statement. |
| "Competitors could get the same platform." | They could, and it would not give them our advantage. The machinery turns knowledge into answers; the advantage is what we feed it. |
| "How do we know Trilivy will exist in five years?" | We do not need to. The source is ours, our team is trained, and our data is in our own databases. |
| "Our team is not equipped for a platform this size." | That is what technology transfer, the Workshop, the documentation and a certified integrator are for. Coding agents shorten the learning curve further. |
| "If we can change everything, how does it stay supportable?" | Extend at defined boundaries, keep our changes in our own version control, and take upstream improvements deliberately. The four rules above enforce that. |
6Questions to put to Trilivy, and to any AI foundation
- Can we read the source of what we run?
- If we stopped paying, what would we still have? (Get it in writing.)
- Can our engineers extend it without the vendor? What may not be touched, and why?
- Can we change model provider ourselves, today? (Ask for a live demonstration.)
- Where do our documents, vectors and conversations physically live?
- Can we connect a product the vendor has no relationship with?
- Show us exactly why the system gave that answer.
7What our team and Legal should confirm
| Check | Our finding |
|---|---|
| The license agreement states that everything we build on the platform belongs to us | [p_c6_1] |
| Our rights to the licensed version survive non-renewal and vendor failure, perpetually | [p_c6_2] |
| The technology-transfer scope and its completion test are written down (e.g. our team ships an agreed change unaided) | [p_c6_3] |
| A coding agent, pointed at the source, correctly explained one platform module | [p_c6_4] |
| Our team built a small extension at a defined boundary, with changes only in its own folder | [p_c6_5] |
| Our change-control rule for platform customizations | [p_c6_6] |