Our approach
Our research engineering process
Five phases that keep scope clear, data protected, and results checkable.
This page describes how we aim to work. Specific arrangements for each engagement are agreed in writing.
Five phases
From first conversation to handover
1. Discovery and feasibility
We read your project summary, ask about the data, definitions, and deadlines, and give an honest view of whether the work is feasible and a good fit.
Typical outputs
- Shared understanding of goals and constraints
- Feasibility notes and open questions
2. Scope and data permissions
We agree the deliverables, what is out of scope, and how data will be accessed and protected. Where data has restrictions, we assess permissions and controls before accepting the work.
Typical outputs
- Written scope and acceptance criteria
- Data access and handling arrangements
3. Implementation and reviews
We build in increments, starting with a pilot sample. Regular reviews with your team catch misunderstandings early.
Typical outputs
- Working increments for review
- Version-controlled code
4. Quality assurance and acceptance
Automated checks run on every build. A manual review sample is compared with sources. You then review the work against the agreed acceptance criteria.
Typical outputs
- Validation and test results
- Signed-off acceptance checklist
5. Documented handover and agreed support
Delivery includes the documentation your team needs to run and maintain the work. Post-delivery support is provided only where the contract defines it.
Typical outputs
- Documentation and runbook
- Agreed support terms, if any
Workflow
A typical research data workflow
Sources
- PDFs and reports
- Spreadsheets and survey files
- Authorized APIs
Extract & harmonize
- Structured extraction
- Common schema and codes
- Documented mapping
Validate
- Automated checks
- Source reconciliation
- Exceptions for review
Deliver
- Research-ready dataset
- Data dictionary
- Versioned code and runbook
Sample artifacts
What the documentation looks like
Examples of the format of artifacts we deliver. The content below is synthetic and shown for illustration only.
Data dictionary (excerpt)
| Variable | Type | Unit | Source | Validation rule |
|---|---|---|---|---|
| total_assets | numeric | currency units | Balance sheet, page reference stored | Must be non-negative; must reconcile with liabilities plus equity |
| fiscal_year | integer | year | Report cover or header | Four digits; one record per entity and year |
| extraction_confidence | category | high / review | Pipeline | Set to review when a check fails |
Acceptance checklist (example)
- Deliverables match the written scope
- Automated checks pass or each exception is explained
- Review sample compared with sources and results recorded
- Code runs from the documented steps on a clean environment
- Documentation reviewed by your team
- Known limitations listed and understood
Code documentation
Each delivered code base includes a README covering setup, inputs, how to run each step, how to run the tests, and what each output means. Where it helps, a short runbook explains the recurring tasks your team will perform.
Data responsibility
How we approach data and security
Permissions first
We check what you are permitted to share and what we are permitted to do with the data before accepting work. Data acquisition uses authorized sources only.
Sensitive data
Sensitive or restricted data is accepted only after we assess permissions and controls for the engagement. Please do not send sensitive datasets or participant data through the website form.
Controls and legal terms
Security controls and legal terms are assessed per engagement and set out in the contract. This website makes no formal security or compliance certification claims.
Operating principles
How we intend to work
These describe our approach. They are not externally verified achievements.
Scoped ownership
Each engagement has clearly defined deliverables and a named owner for the technical work.
Verifiable data quality
We aim to make quality checkable: explicit checks, reconciliation to sources, and reported limitations.
Reproducible, maintainable deliverables
Versioned code and documentation, so results can be re-run and the work can be handed on.
Researcher-approved definitions
Definitions and methods belong to your research team. We implement them and flag ambiguity.
Contract-defined continuity
Maintenance and support after delivery are agreed in writing, not assumed.
Start with a short project summary.
We will respond with questions or an honest view on fit.