How we work
The answers your procurement team is going to ask for
How the work is built, process, security, data protection and intellectual property — written down before you have to ask. Most providers this size cannot show you a page like this, and that is usually the tell.
An engagement, start to finish
Ten steps, each with the document it produces. The documents are the point — they are what makes the process repeatable instead of dependent on everyone remembering the same conversation.
Scope call
Thirty minutes. What the work is, which systems it touches, what done looks like, and an honest answer about whether we are the right fit.
No document — a conversation
NDA, if you want one
Mutual, so it protects you and us. Some clients want this before the scope call rather than after; either is fine.
Mutual NDA
Written quotation
Scope, deliverables, exclusions, timeline, commitment and price. Valid until a stated date. This is the only place a binding price exists.
Quotation
Onboarding
One form collects the people, systems, access, data position, working rhythm and billing details — instead of chasing each one halfway through the build.
Client onboarding form
Agreement
A Services Agreement with a scope schedule and acceptance criteria. A Data Processing Agreement alongside it where personal data is involved.
Services Agreement + Schedule A, DPA
Access granted
The narrowest role that lets the work happen, each item recorded so it can be revoked cleanly rather than forgotten.
Access & credential record
Build, with weekly reporting
What shipped, what is blocked, hours used against any cap. Anything outside the signed scope stops and becomes a Change Order first.
Weekly report, Change Orders
Handover
A runbook covering how it works, what breaks, what to check and which changes you can safely make yourself. Plus the architecture diagram and credential list.
Runbook
Acceptance
Signed sign-off against the acceptance criteria. This starts the warranty period and unlocks the final invoice.
Project acceptance certificate
Then either retainer, or closeout
A maintenance retainer if the system needs keeping alive, or a documented closeout with access revoked and data dealt with. Never silence.
Maintenance retainer / offboarding record
How the work gets built
Machine assistance on the mechanical work, a person on every decision
Most of what goes into an automation is repetitive engineering: scaffolding, wiring, transformation code, documentation. We build that with machine assistance against written standards, and we check the result automatically before it reaches you. What we do not delegate is the judgement — what is worth automating, what the exceptions should do, and where a human belongs in the loop.
The build standard is written down, not remembered
The rules for building correctly on these platforms — expression syntax, node configuration, error-handling patterns, code conventions — are encoded as 9 machine-readable standards rather than held in one engineer's head. That is what makes the output consistent across builds instead of varying with who was available and how tired they were.
Encoded build standards
AI drafts the repetitive engineering
Scaffolding a workflow, wiring the connections, writing the transformation code, drafting the runbook. This is the part that is mechanical, high-volume and easy to get subtly wrong by hand, which is exactly where machine assistance earns its place.
Draft workflow and documentation
A person makes every judgement call
Which steps are worth automating and which are cheaper left manual. What the exception handling should do. Where a human belongs in the loop. Those are decisions about your business, and they are not delegated to a model.
Scope schedule
Every workflow is validated before you see it
Each build is checked against 476 known node types — 437 platform nodes and 39 AI nodes — drawn from real platform schemas, plus 470 pinned type versions. Wrong node type, wrong version, a node left unconnected, a workflow with no error handling: caught by the check, not by you in production.
Validation report
Issues come out graded, and nothing ships with a critical
The validation report grades what it finds as critical, high or low. Critical and high are fixed before handover. Low issues are listed for you rather than quietly closed, so you inherit a known state instead of a clean-looking one.
Graded issue list
Documentation comes out of the build, not after it
The runbook and the architecture diagram are produced from what was actually built, which is why they still describe the system a year later. Documentation written from memory a week after handover is the reason most automation becomes unmaintainable.
Runbook and architecture diagram
Where your data sits in all of this
Building with machine assistance raises a fair question about what happens to your information. These are the four commitments, and they are the same ones written into the privacy policy rather than a softer version for a marketing page.
- Your data does not go into our AI tooling
- Machine assistance operates on workflow structure, code and documentation. Your live records, your customers' personal data and the contents of your systems are not fed into it. Automations are built and tested against sample or synthetic data until the logic is right.
- Nothing you give us trains a model
- Client data is never used to train or fine-tune AI models, by us or through us. This has been our position since before we described how we build, and describing it has not changed it.
- A named engineer is accountable for the whole build
- However a line was drafted, a person reviewed it, tested it and put their name to the handover. AI-assisted is not AI-decided, and there is no point in the process where nobody is answerable for what shipped.
- The same rules apply to anyone we bring in
- Contract engineers work to the same encoded standards and the same data boundary, under written agreements that include IP assignment. The standard does not loosen because capacity was added.
The full position is in the privacy policy.
What this does not buy you
- It does not make the work instant. The scope call, the parallel run against your live process and a proper handover take the time they take, and compressing them is how automation ends up trusted before it has earned it.
- It does not remove the need to understand your process. Watching how the work really happens — including the exceptions people have stopped mentioning — is a human job, and it is the part that determines whether an automation is worth building at all.
- Validation catches structural defects, not strategic ones. It will tell you a node is misconfigured. It will never tell you that you automated the wrong process, which is why the second step above exists.
Security
Access and credentials
Automation work means holding keys to systems that matter. How a provider handles that is worth more scrutiny than their tech stack.
Credentials
Held only in a platform's own credential store or an encrypted password manager. Never in plain text, chat, email, or as a literal inside a workflow node. Anything sent to us by an insecure channel is treated as compromised and rotated.
Least privilege
The narrowest role that lets the work happen. An admin seat issued for a one-workflow job is the access everyone forgets to revoke, so we do not ask for one.
Recorded and revoked
Every item of access is logged with the date granted, then revoked against a written offboarding checklist — including releasing platform seats so they stop billing you.
Production changes
Built and tested in a sandbox first. Changes to production need your approver's written go-ahead, per change. Test first, always.
Personal data
Where an automation touches personal data, we act as your processor under a Data Processing Agreement, not on our own account.
- We process personal data only on your documented instructions, and only as far as the work requires.
- Client personal data is never used to train, fine-tune or evaluate any machine-learning model.
- Sub-processors — the automation and AI platforms the service runs on — are listed by name in the DPA annexes, with notice before any change.
- Breach notification to you without undue delay, on a timeline short enough for you to meet your own obligations.
- On termination, data returned or deleted within an agreed window, with written confirmation.
Intellectual property
The chain of assignment is the part that actually determines whether you own what you paid for.
- On full payment, we assign to you the rights in the workflows, configurations, code and documentation built for you.
- Contract engineers assign their intellectual property to us at the moment of creation — a present assignment, not a promise to sign later. That is what makes our assignment to you valid.
- Pre-existing components, open-source dependencies and any generative AI tooling used are disclosed, so nothing arrives with a licence you did not know about.
- We keep our own general methods and reusable patterns, and license them to you as embedded in your deliverables. You are not buying our toolkit; you are buying your system.
- Naming you publicly requires your written consent. Where we do not hold it, work is described without identifying you.
Reporting
You should never have to ask how it is going
Every active engagement gets a written weekly update: what shipped, what is blocked and on whom, and hours used against any agreed cap. It takes us fifteen minutes and removes the single most common source of friction in outsourced work.
Maintenance retainers get a monthly summary instead — runs, failures, hours used, and anything that needs your attention. An invoice that matches a report nobody wrote is how retainers quietly overrun, on both sides.
If a deadline is going to slip, you hear it when we know, not on the day. That is uncomfortable to send and much cheaper than the alternative.
Due diligence, answered
Do you use AI to build our automations?
Yes, on the mechanical parts, and we would rather describe it than leave you to guess. Scaffolding, wiring, transformation code and first-draft documentation are produced with machine assistance against 9 written build standards. Every build is then checked automatically against 476 known node types and 470 pinned versions before handover. What is not delegated is judgement: what to automate, what the exception handling does, and where a person belongs in the loop are decided by an engineer who is accountable for the result.
Does our data go into your AI tooling?
No. Machine assistance operates on workflow structure, code and documentation — not on your live records or anyone's personal data. Automations are built and tested against sample or synthetic data until the logic is right, and nothing you give us is used to train or fine-tune a model. The same boundary applies to any contract engineer we bring in.
How do we know an AI-assisted build is not worse than a hand-built one?
Because it is checked in a way a hand-built one usually is not. The validator flags wrong node types, wrong versions, unconnected nodes and workflows with no error handling, and grades what it finds. Critical and high issues are fixed before handover; low ones are listed for you rather than quietly closed. That said, no automated check catches a strategic mistake — it will tell you a node is misconfigured, never that the wrong process was automated. That is what the scope call is for.
Can we see your agreements before committing?
Yes. The Services Agreement, mutual NDA and Data Processing Agreement are available on request before any commitment, so your lawyer can read them on your timetable rather than under deadline. Ask on the scope call and they will be sent the same day.
How do you handle access to our production systems?
At the narrowest role that lets the work happen, recorded on an access register with the date granted, and revoked at closeout against a written checklist. Work is built and tested in a sandbox first; changes to production need your approver's written go-ahead per change.
Who owns what we pay you to build?
You do, on full payment. That includes anything a contract engineer touched, because they assign their IP to us at the moment of creation under a signed subcontractor agreement. Without that chain, a provider cannot validly assign the deliverable on to you — it is worth asking every provider you evaluate how they handle it.
What stops the scope quietly growing?
A scope schedule with written acceptance criteria, and a Change Order for anything outside it agreed before work on the change begins. Raising a Change Order is not friction; it is the professional response to a change request, and it protects your budget as much as our margin.
What happens if we want to leave?
You get current exports of the systems, up-to-date documentation, and a list of the credentials we held; then we surrender or delete our access within the agreed window. Nothing is held hostage and nothing is obscured to make you dependent. Handover work beyond that is chargeable, which is stated up front rather than discovered.
Do you carry professional indemnity insurance?
Not currently. We would rather tell you that than imply otherwise. Liability is capped in the Services Agreement at the fees paid over a defined period, which is stated in the agreement you sign. If your procurement process requires insurance, say so on the first call so we can tell you honestly whether we can meet it.
Want the agreements before you commit?
Ask on the scope call and the Services Agreement, NDA and DPA go out the same day. Repomanta Information Technology Services contracts in its registered name, and Repomanta Digital Lab is the trade name on the work.
Book a scope call