PretzelPort — home
solution

Answers on your data

Ask in your own words. Get an answer with its sources attached — not a dashboard to interpret.

the situation

The people with the questions cannot write the queries

The scientists, engineers and buyers who need answers cannot write queries. The people who can write queries do not know the science or the machine. So questions get queued, translated, half-understood, and answered a week late.

Or they are never asked at all, which is the more expensive outcome and the one nobody measures. Dashboards were supposed to fix this. A dashboard answers the questions somebody anticipated two years ago, which is rarely the one in front of you now.

what we do

Search and assistants that speak your vocabulary

We put a natural-language layer on the connected data — retrieval over linked records, not a general-purpose model guessing at your terminology. It knows your part numbers, machine types, compound identifiers and document conventions, because those were modelled rather than inferred.

Every answer carries its sources, so it can be checked instead of trusted. That is the difference between a tool people rely on and one they quietly stop opening.

The honest limit: this works because the data underneath it is connected. A language model pointed at a file share produces confident nonsense, and we will say so rather than sell it.

a case

Finding the drawing, the change, and the reason behind it

An engineer needs the last variant of a part someone designed years ago. It exists — in a PDM system, an email thread, and a folder nobody named well. So the part gets redesigned, gets a new number, and now there are two.

What we build: search across drawings, change records and specifications that understands part numbers and machine types, so what already exists gets found and reused.

What it is worth: engineering hours, plus slower part-number growth. Every new number carries stocking, purchasing and documentation cost forever.

typically includes

What an engagement actually contains

  • Retrieval over your linked records, not over a pile of documents.
  • Provenance on every answer — which record, which document, which version.
  • Your domain vocabulary: identifiers, synonyms, abbreviations, the names only your people use.
  • An evaluation set of real questions, so “is it good enough” has an answer other than a vibe.
  • Guardrails and access control that mirror who is allowed to know what.
what this is not

Three things it is worth ruling out

  • Not a chatbot bolted onto a file share.
  • Not a replacement for the people who understand the domain — it is a shorter path to what they already know.
  • Not a demo. If it cannot answer a real question from a real user on real data, it is not finished.
regulated by default

Compliance is an architecture decision

We work where traceability matters — GxP environments among them — so the audit trail is part of the first design rather than a phase bolted on at the end. Here that shows up in the answers themselves: every derived value carries provenance back to the record it came from, and every question asked leaves a trail that can be reviewed later.

Access control mirrors how the organization is actually structured, so an assistant never becomes a way around a permission. Validation is treated as a normal engineering activity, not a document exercise once the software is finished.

What would your team ask first?

Tell us the question nobody can answer today.

Get in touch