The shape of a Vectyr system
The systems we build follow a consistent pipeline. Understanding it is usually enough to answer most architectural questions in a review.
1. Connect. The system authenticates to the client’s own systems using an app registration the client creates and controls — commonly Microsoft Graph for Teams meetings, Teams chat, SharePoint, and OneDrive, plus whatever line-of-business APIs matter for the engagement. Permissions are requested at the narrowest scope that satisfies the use case, and the client’s administrator grants consent explicitly and can revoke it at any time without involving us.
2. Ingest. Source material is retrieved on a schedule or by subscription to change notifications, and normalized into a common internal representation. Each ingested item keeps a permanent pointer to its origin — the meeting identifier and timestamp, the message identifier, the document path and version — because that pointer is what makes every downstream assertion traceable.
3. Extract. Inference turns unstructured material into candidate structured records: a status change, a risk, a decision, an action with an owner, a dependency, a date. Deterministic parsing handles anything a parser can do reliably. Each candidate record carries its source pointer and a confidence signal.
4. Verify. Candidate records are routed to the person best placed to confirm them, as a short queue of confirm-or-reject items rather than a form to fill in. The human decision is the authoritative event. Confirmations, edits, and rejections are all attributed and retained.
5. Serve. Verified records populate the views people actually use: programme and initiative dashboards, timelines, risk and issue registers, decision and action logs, resource views, generated reports, and natural-language question answering over the connected knowledge.
The security-relevant consequence of this shape is that the system is read-heavy against client sources and write-light into them. In most engagements, the system reads from the client’s estate and writes only into its own store; writing back into a client system of record is a separately scoped decision, not a default.
Where things run
In the default deployment model, the application runs on the Cloudflare developer platform: application logic in Workers, relational data in D1, files and artifacts in R2 object storage, secrets in the platform secret store, and outbound model calls routed through an AI gateway that gives us a single controlled egress point with logging and rate limiting. Each client gets its own instance and its own datastores.
Where an engagement needs dedicated compute — most often GPU capacity for self-hosted models — that runs on AWS or DigitalOcean alongside the primary platform, still within infrastructure we operate. Hosting, isolation, and AI processing sets out where things run and which claims hold for each AI processing option.
Trust boundaries
There are four boundaries worth naming, because most real risk sits at one of them.
Client estate to Vectyr system. Crossed by authenticated API calls using client-granted credentials, over TLS. Controlled by the scope of the app registration, which is the single most important control in the whole architecture — a read-only, narrowly scoped grant limits the blast radius of everything downstream. Client administrators can inspect and revoke it independently.
Vectyr system to inference provider. Crossed only when enterprise API inference is in use, only for the minimum content required, under enterprise terms prohibiting training and providing zero or minimal retention. With self-hosted models this boundary does not exist: no external provider receives content.
System to human reviewer. Crossed by authenticated user sessions, ideally federated to the client’s identity provider so that authentication, multi-factor policy, and deprovisioning follow the client’s existing controls rather than a separate account list we maintain.
Operator access. Vectyr engineers reaching production for support and operation. This is deliberately narrow, limited to the three founders, authenticated with phishing-resistant multi-factor, and logged as an attributable action.
Identity and permissions
Wherever the client’s platform supports it, we derive end-user visibility from the client’s own group memberships and file permissions rather than maintaining a parallel permission list. If someone loses access to a Teams channel or a SharePoint site in the client’s tenant, they lose the corresponding visibility in our system, without an administrator having to remember to make a second change.
This matters more than it sounds. A separate permission list in a second system is the most common way access control quietly rots. Inheriting from the source of truth means there is only one thing to keep right. Identity and single sign-on covers federation options including SAML 2.0 and Shibboleth for institutions that require it.
What we deliberately do not do
We do not build a shared cross-client data store or a shared vector index. We do not connect to production control systems that operate physical equipment. We do not copy entire file repositories when a scoped subset satisfies the requirement. We do not maintain long-lived static API keys where short-lived, rotatable credentials are available.
Related detail
The confidential architecture and data flow detail document contains component diagrams, per-model egress paths, data-store schemas at the category level, and the full list of network flows. Connector inventory lists each integration with its exact permission scopes. Microsoft 365 integration security covers Graph permissions in the detail a Microsoft administrator will want.
