On-premises
Runs in your own data centre, on hardware you procure and keep.
- Runs onyour racks
- Hardwareyou own
- Data egress0 bytes
Architecture
Read in place. Reason on your hardware. Write back with a receipt.
That is the whole system in one line. The rest of this page is the detail an architect asks for: which API a connector calls, how permissions are enforced at query time, where a model actually runs, what a write is allowed to change, and what lands in the audit log afterwards.
01Read in placequeried at the source412 contracts · 1,840 usage records
02Reason on your hardwareinference on your GPUs3 renewals flagged as at risk
03Write back with a receiptwritten as a.okaforCRM updated · owner notified
AOa.okaforReceipt
- ran this
- 3 records changed
- model held on your racks
- every call logged
starting run · scope=sales.renewals0 B egress
0Native connectors
0Deployment topologies
0Bytes of egress
Layer 01 · Connect
The data never gets a second home.
Connectors query source systems over their own APIs and carry the caller’s identity on every request. There is no staging bucket, no vendor-side replica, no overnight dump. The record you query is the record in the system of origin.
- No shadow copy. Retrieval hits the source system directly; nothing is bulk-loaded into a store PFLabs controls.
- Identity is forwarded, not mapped. Each call executes as the requesting user, so the source system’s own ACLs remain the enforcement point.
- Change-data capture. Updates stream as they occur, so freshness is bounded by the connector’s poll interval rather than a nightly batch.
SAP S/4HANACustomer 4471- Account
- Meridian Logistics
- Owner
- R. Mehta
- Open orders
- 14
- Credit limit
- $2.0M
- Margin
- 31.4%
- Renewal contact
- r.mehta@ ••••••
AOA. OkaforSales · 4 of 6 fields
JRJ. ReyesFinance · 5 of 6 fields
same record · no copy made · ACLs enforced at the source0 B egress
Layer 02 · Unify
Resolution happens at query time.
The Brain is a graph over your sources, not a copy of them. Identifiers are matched into entities, conflicting values are kept alongside their provenance instead of being overwritten, and every result is cut against the caller’s permissions before it is returned.
- Provenance survives the merge. Where two systems disagree, both values are retained with their source and timestamp. The conflict stays visible instead of being silently picked.
- Deterministic joins run first. Records match on shared keys before any probabilistic matching is attempted, and low-confidence merges are surfaced rather than assumed.
- Filtering is post-retrieval. Results are checked against the caller’s rights at query time, so revoking access takes effect on the next request, not the next re-index.
ERP recordsCRM accountsDocumentsTicketsWarehousePeople dataConversations
Company Brain
0 entities resolvedinherited ACLs
Layer 03 · Reason
Routing is a decision you can audit.
Each request is classified and dispatched to whichever model scores best on that class of work. The routing decision, the model version and the parameters are recorded with the run, so an answer can be reproduced later on the model that actually produced it.
- One interface, many models. Open-weight and licensed models sit behind the same contract, so replacing one does not invalidate work done on another.
- Weights and activations stay put. Inference executes on your hardware, so there is no outbound API call to log, throttle or subpoena.
- Versions are pinned per run. Upgrading the fleet never silently changes a historic result, because each run remembers what produced it.
- Contract analysisLong-context reasoning
- Code generationCode-specialised
- Invoice extractionStructured extraction
- Board-level summaryDeep reasoning
PFLabs picks the model. You keep the infrastructure.no token bill
Layer 04 · Act
Every write is a reversible decision.
Execution is a sequence of scoped, logged operations against systems you already control. Each write is attributed to the person who invoked it, gated wherever policy demands it, and recorded in enough detail to reconstruct, or reverse, what a run changed.
- Writes inherit the caller. An agent can never reach further than the person who invoked it; there is no privileged service account behind it.
- Gates are policy, not prompt. Approval steps are declared on the workflow and enforced by the runtime, so no instruction can talk its way past one.
- Replayable to the step. Every run records its inputs, tool calls, model version and outputs, so a disputed result is reconstructed rather than argued about.
0 steps · scoped by RBAC0 B egress
Measured, not asserted
The hard tier is the only one worth quoting.
0%
GAIA · hardest tier
Level 3 tasks chain a dozen or more dependent steps across tools, and most agents lose the thread partway and return something confidently wrong. This figure is from the shipping configuration: same routing, same boundary, no bench-only settings. Public method, public numbers. Audit them yourself.
- Benchmark
- GAIA, Level 3: the tier that chains the most dependent steps.
- Configuration
- The shipping default. No bench-only routing, prompts or tool access.
- Compute
- Customer-owned hardware, with no external inference call in the loop.
- Reproducibility
- Published task set and scoring, so the run can be repeated against your own deployment.
Deployment
Three topologies. One guarantee.
PFLabs installs where your data already is. The sovereignty guarantee does not change between them. Only the walls around it do.
In your VPC
Deployed inside your own cloud tenancy. Your account, your network policy, your region.
- Runs inyour tenancy
- Runs inyour account
- Data egress0 bytes
Fully isolated
Installed into a fully isolated environment. Updates arrive through your existing controlled-media process.
- Networkisolated
- Updates viayour process
- Data egressimpossible
Security & trust
Verifiable at the network layer.
The claim is falsifiable, which is the point of making it. Stand the deployment behind a default-deny egress policy and it runs unchanged: no degraded mode, no feature that quietly needs a callback. Your egress monitoring has nothing to report because there is nothing to report.
The test is simple: watch the boundary while it works, and see what crosses it. Nothing does.
Egress, tested
Stand the deployment behind a default-deny egress policy and nothing degrades. There is no allow-list to maintain and no exception to review.
Federated, not duplicated
PFLabs keeps no user directory of its own. Accounts, groups and revocations stay in your IdP and are read from it.
Checked at the call, not the index
Rights are evaluated per request against the source system, so a revocation takes effect on the next query rather than the next rebuild.
An export, not a dashboard
The trail is queryable and exportable in full, so it can go to an examiner directly without a vendor sitting in the loop.
Capacity, not consumption
You size the hardware once. There is no meter turning a more productive team into a larger invoice.
Residency follows the rack
Jurisdiction is settled by where you install, not by a clause in a contract that a change of ownership can revisit.
Technical fact sheet
The details your architects will ask for first.
- Deployment targets
- Bare metal, your own tenancy, or a sovereign region, on GPU capacity you procure and keep.
- Identity & access
- SAML or OIDC against your existing provider. PFLabs stores no passwords and issues no accounts of its own.
- Model execution
- Every task is routed by difficulty. Routine steps go to small models, hard reasoning to large ones, and anything you have fine-tuned yourself is available to both. No vendor lock and no reasoning rates for simple questions.
- Connectors
- 100,000+ connectors, plus a documented interface for the internal systems that were never given one.
- Data residency
- Determined entirely by where you deploy.
- Audit & logging
- Immutable audit trail covering every retrieval, decision and write.
- Network posture
- Default-deny compatible. There is no outbound call to allow-list, because none is made.
Own your intelligence.
See PFLabs running inside your own environment: your systems, your models, your controls, on your infrastructure.