Deployed by an engineer, not downloaded.

Why an engineer is in the room

Three parts of this cannot be handled by a product that ships and waits:

• Your documents are not clean. Every corpus breaks the ingest layer in its own particular way, and the failure is usually silent — a table flattened into nonsense, a heading swallowed, a scanned appendix that yields nothing.
• “Working” is your definition, not ours. The acceptance bar for a security questionnaire is written by your compliance team. Someone has to turn that into an evaluation set with real questions and real expected answers.
• The human gate has to fit your process. Who signs, in which system, with what audit expectations. That is an integration, not a setting.

None of that is a professional-services upsell. It is the difference between a demo and something a person is willing to put their name on.

How a deployment runs

1 · Scope — before any documents move

Which questions matter, who signs the answers, where the deployment lives, and what your data-handling requirements are. Written down and agreed before a single file changes hands. For a security team, an engineer who asks about data handling before asking for the files is the one worth continuing with.

2 · Stand it up in your environment

One Compose file, two containers, one Postgres. Inside your VPC, on your infrastructure. Documents mount read-only; embeddings are generated locally; nothing leaves your account except retrieved passages going to the model provider — and, if that is unacceptable, that is a conversation about self-hosted models rather than a dead end.

3 · Ingest, and meet the mess

This is where the week goes. Ingest fails loudly rather than quietly: if any citation offset does not round-trip against the stored text, the document does not load. Better a blocked ingest than a corpus that answers with citations pointing at the wrong sentence.

4 · Build the evaluation set with you

Questions you already answer today, with the answers you already give — plus questions your documents deliberately cannot answer. That second half is the valuable half, and it is the only way to measure whether the system invents things under pressure.

5 · Measure on your corpus

Grounding rate, retrieval hit rate, correct-refusal rate, and fabrication rate — from your documents, not ours. The numbers from a public framework document say nothing about how it performs on yours.

6 · Wire the gate into your process

Reviewers work in your tools. The review call is an API endpoint, so the approval can happen in a ticketing system, an internal portal, or the bundled interface — whichever one your reviewers already have open.

7 · Hand over

Runbook, the evaluation set as a regression suite, and the measured baseline. You should be able to re-run the evaluation after a document update and see whether anything moved.

What we need from you

Data handling

When this is the wrong tool

It costs four model calls and tens of seconds per answer, and it stops to ask a human. If your failure mode is a mildly unhelpful reply, that is overhead you should not pay — a straightforward retrieval assistant will serve you better and cost a fraction as much.

This is built for the case where the output is written down, signed, and read later by someone deciding whether to trust you.

Get in touch

Tell us what you would point it at.

The useful first message is short and concrete: what kind of documents, what question you answer today by hand, and who signs the answer.

Prefer email? chinnam@techarchinc.com. Submissions are stored on our own server — no third-party form service.