1. Home
  2. Services
  3. Tech integration and data

Tech integration and data

The system is only as current as the records under it.

We name the source of each fact, keep the permission attached to it, and put the index in an account you control.

  • Source of truth
  • Ingestion
  • Identity and permissions
  • Knowledge graphs
  • Movement between systems

Source of truth

Each fact has one home.

Before any index is built, the design says where each fact the workflow needs lives, and which way a conflict resolves. The model is not a place facts are stored.

01

Subscription quantity

The billing system.

02

Contract terms

The contract.

03

Ticket status

The ticket tool.

04

Account owner

The CRM.

Ingestion and identity

An explicit corpus. An index that remembers who could open the file.

01

The corpus is a list, and so are the exclusions

These folders, these ticket views, these tables, refreshed on this cadence. Credentials, human-resources files, material under legal hold, and anything the workflow does not need stay out. A document that arrives later does not enter the index because it happens to sit nearby.

02

The index inherits the permission of the source object

Passages, embeddings, and the metadata that make them safe to retrieve, including source, timestamp, and the permission of the original, sit together. Retrieval checks that permission for the person asking, before the model sees a passage.

03

An embedding is derived data, not a boundary

It is not an anonymized form of the document and it is not a security control. A shared “company knowledge base” that ignores who could have opened the file is a defect, even when the answers sound right.

Knowledge graphs

Built when the question is about relationships. Not before.

Search over a named corpus answers “what does the policy say.” A graph answers “how these records connect”: which contract covers this product, which account owns this invoice, what depends on this service. Most first systems at this size do not get one. Building the second before the first has failed an evaluation is how a small company acquires a system it cannot feed.

When a graph is in the path, the schema stays small. Entities and edges point back at the source record and carry a permission. Extraction the model proposes is reviewed before it is treated as a fact. The graph is rebuilt from the source, and every hop on it is authorized again. A graph nobody maintains is removed.

Vector search finds the candidates. The graph walks only the links they justify.Permission is checked at every hop.

Movement between systems

Boring on purpose.

Where the workflow has to read or write a system you already pay for, the integration is built to be unremarkable.

Idempotent writes

The same instruction applied twice produces the same record once.

Retries that do not double-apply

A failed call is retried against a key, not against hope.

A dead letter a person can see

What could not be delivered waits where someone will notice it.

A credential scoped to the operation

Held in your secret manager, limited to the one thing it does.

Where your data goes

Four places. The design names the vendor, the region, and the product.

The site states the rule. A vendor matrix would be stale in a quarter.

01

Your source systems stay the system of record

The CRM, mailbox, ticket tool, drive, and database remain where you already keep them. Birdeye does not become a second copy of the business.

02

The index lives in an account you own

Often in the database you already run. A separate vector host is a subprocessor, and adding one is a decision recorded in the design.

03

A bounded context goes to the model API

The retrieved passages and tool results for that question. Not the corpus, not credentials. The commercial APIs we use do not train on customer content by default; their retention windows and zero-retention arrangements are a term of the design. When your data cannot accept the default, the design uses an approved zero-retention arrangement or a model hosted inside your cloud account, or that data is not sent.

04

Our records are the engagement, not your data

Architecture notes, the runbook, and the decision log stay with the firm and are written so they contain no raw customer content. Samples for the evaluation set stay in your project. Working copies of production data do not live on personal machines or in personal chat tools.

How it is protected

Protection is a property of the path.

  • Retrieval is filtered by the caller’s existing permissions before the model sees a passage
  • If a graph is in the path, every hop is authorized again
  • Tool credentials stay on the server that performs the call
  • Write tools wait for an explicit approval on that action
  • Document text is untrusted input; it cannot widen the tool list, the credentials, or the approval rule
  • Traffic to the model and between services is encrypted in transit
  • The index is encrypted at rest with your cloud controls, and your own key management when you have it
  • Instructions, tool definitions, and the evaluation set are versioned; a failed set blocks the change
  • Our access is named, time-bounded, and removed when the work pauses
  • If you need a data processing addendum, a business associate agreement, or a specific region, that is a term of the design, agreed before any data moves. We do not claim a certification we have not published.

Questions

About tech integration and data.

If yours is not here, ask. We answer plainly, including when the answer is that this is not the right engagement.

Do we need a knowledge graph?

Most first systems at this size do not. Search over a named corpus answers “what does the policy say.” A graph answers “how these records connect.” We build the second when a measured task has shown the first cannot hold the relationship still, and we keep the schema small.

Where does the index live?

In an account you own, often in the database you already run. A separate vector host is a subprocessor; adding one is a decision recorded in the design, not a library install.

What is sent to the model provider?

At request time, a bounded context: the retrieved passages and the tool results for that question. Not the corpus. Not credentials. The design names the vendor, the region, and what that product retains.

Our data cannot leave our cloud.

Then the design chooses a path that carries the constraint: an approved zero-retention arrangement on an eligible endpoint, or a model hosted inside your cloud account. If neither is available, that data is not sent.

Can staff see things they should not?

Retrieval is filtered by the caller’s existing permissions before the model sees a passage. The index inherits the permission of the source object. A shared knowledge base that ignores who could have opened the file is a defect, even when the answers sound right.

Is this a data-platform project?

No. It is the work of connecting the systems the model depends on: a named corpus, idempotent writes, retries that do not double-apply, a dead letter a person can see. A general implementation of your CRM or a warehouse program is a different engagement.

Tell us which systems hold the facts.

We will write the source-of-truth table and the corpus list before anything is indexed.

Start a conversation