Forward-Deployed Engineering05
Your systems of record,connected and modelled,with the access walls intact.
We connect the workflow to the systems it needs, model the data as the system will read it and build retrieval that shows a person only what they are allowed to see. Each system is scoped and priced on its own.
- Scope
- Per system, priced each
- Reads
- Live, from the system of record
- Writes
- Back, attributed, as the person it acts for
- Access
- Your existing walls, kept
FDE / 01What we connect
Four kinds of system.
Every workflow touches some of these. Each connector is scoped on its own, because each is a different amount of work.
Systems of record
ERP, CRM, HR, finance and the line-of-business systems that hold the truth. Read live through their APIs or their database, written back to through the same path a person would use, with the action attributed.
Documents
Shared drives, document stores, mailboxes, scanned PDFs. Parsed with their structure kept, indexed with the permissions of the folder they came from, and traceable back to the page.
APIs and services
Internal services and third-party APIs the workflow has to call. Wrapped as tools the system can use, each with its own permission scope, rate limit and log line.
Identity
Your identity provider. The system acts as the person it works for, no more; every read and write carries their identity, and revoking the person revokes the system's access on their behalf.
FDE / 02The data
As it is, and as the system reads it.
The connectors are the smaller half. The larger half is making the data mean one thing across systems, and knowing where each value came from.
Data as it is
- Three customer identifiers across three systems, none of them primary
- The field that is always wrong, and the one person who knows why
- Documents in a shared drive with no owner and every permission
- A monthly export in a spreadsheet that is the real source of truth
- History that changes shape at the year the system was migrated
Data as the system reads it
- One model, with each entity resolved across the systems that hold it
- Provenance on every field: which system, which record, when
- Retrieval that returns only what the person asking may see
- Live reads from the record; the spreadsheet export retired
- A data quality register: the known faults, and what the system does with each
FDE / 03What you keep
6 ITEMS
The onboarding manifest.
Six things, in your accounts, for every system connected.
- The connectors
One per system, in your repository, with its permission scope, rate limits and tests against the live system.
- The data model
Entities resolved across systems, documented, with the rules for each join written down.
- The retrieval index
Documents and records indexed with their permissions, so a query returns only what its reader may see.
- The provenance
Every value the system uses traceable to a system, a record and a time; every answer traceable to its sources.
- The write-back path
How the system writes to the record: as whom, with what approval, logged where, reversed how.
- The data quality register
The faults found in the data, their cause where known, and what the system does when it meets each.
FDE / 04Specified
10 FIELDS
Onboarding, specified.
The terms as they stand before the first call. The systems move the detail; they do not move the rules.
- Scope
- Per system; each connector, model and index scoped and priced on its own
- Start
- A scoping call, then a read of the systems, their APIs and their access model
- Engineer
- One named senior engineer; a data engineer where the modelling needs one
- Where it runs
- In your cloud account and your repository; data stays in your region
- Access needed
- API or database credentials per system, scoped to what the workflow needs, and a person who can grant them
- Identity
- The system acts through your identity provider, as the person it works for
- Write-back
- Through the same path a person would use, attributed, approved where the record needs it, reversible
- Retrieval
- Indexed with the source's permissions; a golden set of queries with known answers to score it against
- Tests
- Each connector tested against the live system in your pipeline; the data quality register kept current
- Ends with
- Connectors, model and index in your accounts, documented, with a runbook per connector
FDE / 05Fit
Whether to call us
Call us when
- A workflow needs more than one system and none of them talk to each other
- A pilot works on an export and stops at the system of record
- Documents hold the answers and nobody can search them by permission
- Access rules differ by system and the workflow must respect each
- A Production Sprint needs a connector its six weeks cannot absorb
Do not call us when
- You need a data warehouse built before anything else; that is a different engagement
- The system of record itself is being replaced this year
- No one can grant credentials to the systems inside a fortnight
- The workflow does not yet exist to be connected
- The data is owned by a third party who will not grant access
FDE / 06Proof
1 ROWS
Case studies
Illustrative engagements written end to end, chapter by chapter.
FDE / 07Questions
6 QUESTIONS
Asked about onboarding.
Do you use MCP servers or your own connectors?
Whichever your stack and the system support. Where a system has a maintained server or SDK, we use it and wrap the permissions; where it does not, we write a connector in your repository. In both cases the code is yours.
How do the access walls stay intact?
Documents and records are indexed with the permissions of where they came from, and every query is made as the person asking, through your identity provider. A person cannot retrieve through the system what they could not open themselves.
What about data quality?
We do not clean the data before starting; we read it as it is and write down what we find. The register lists each fault, its cause where known and what the system does when it meets it. Fixes at the source are yours to schedule.
Does our data leave our perimeter?
No. Connectors, indexes and models run in your cloud account and your region. Where the requirement is stricter, the environment is scoped with Regulated & Secure Deployment.
Can the system write to the record, or only read?
Both, if the workflow needs it. Write-back goes through the same path a person would use, as that person, with an approval step where the record needs one, and every write is logged and reversible.
How is it priced?
Per system, as a fixed fee per connector, model or index, agreed before the work starts. A system whose access does not arrive is paused, not invoiced.
FDE / ENDStart
Connect the record,and the workflow can run on it.
Book a scoping call and bring the list of systems; you leave knowing what each would take.