Principles

Operating principles

Evidence before build

We do not start a build until the operational question is written, the data that can lawfully be used has been identified, and a baseline has been measured on a sample the client controls. Where the evidence shows that the question cannot be supported, we stop at the end of assess and record the reasons. A demonstration on a static file is not treated as evidence that a production path exists. The steering group sees the same material that the delivery team used to form the recommendation.

One accountable owner

The client names a single accountable owner for the engagement. That person has authority over scope, data access, the exception process and the go-live decision. Committees may advise, and specialists may contribute, but decisions are recorded against one name. Without that owner we will not open a foundations phase, because later disputes over access and review cannot be resolved in the time a build requires. The owner remains the counterpart for change control after go-live.

Everything documented

Model cards, data lineage, evaluation results, prompts, change records and the decision log are produced as the work proceeds. Documentation is a deliverable of each phase, not a closing exercise. The client receives the files at phase end in open formats. Internal audit and group risk should be able to read them without a briefing from us. If a step cannot be written down, it is not finished. Handover includes the decision log so that later reviewers can see what was accepted and why.

A defined human review point

No system goes live without a defined human review point. The reviewer is a named role on the client side. The cases they must see, the time they are expected to take, and the action they may take are written before go-live. Automation that cannot be paused by that reviewer is outside the scope we will operate. Review is treated as part of the operating procedure, with logging of the decision.

Phases

Four delivery phases

Assess · 2–3 weeks

Assess

Inputs are the operational question, the systems of record, a first view of data sources, and the policies that already constrain the work. Activities include interviews with the process owner, a data and access review, a lawful-use discussion for any personal data, and a written risk register. Outputs are a go or no-go recommendation, a draft statement of work for foundations, a named owner, and a list of access items that must be granted before the next phase.

Foundations · 4–8 weeks

Foundations

Inputs are the approved scope, granted access, and the residency and retention constraints. Activities include pipeline design, quality rules, environment build, a labelled or held-out sample, and the first model card. Outputs are a working data path, an evaluation baseline, access-control mapping, and a build plan with integration points. If the baseline cannot support the question, the phase closes with a narrower recommendation rather than an automatic build.

Build · 8–12 weeks

Build

Inputs are the foundations artefacts and the approved integration list. Activities include model or retrieval development, exception-queue design, integration with the applications staff already use, logging, and a rehearsal of rollback. Outputs are a production candidate, complete documentation, a reviewer procedure, and a go-live recommendation. Go-live is a client decision recorded in the decision log.

Operate · continuing

Operate

Inputs are the signed operating agreement, production access, and the monitoring design. Activities include drift checks, retraining under change control, incident response, and scheduled review with the model owner. Outputs are monitoring reports, change records and an updated model card. The phase ends when the agreement ends, at which point access is revoked and handover is confirmed in writing.

Oversight

Governance model

A steering group meets on a fortnightly cadence during foundations and build, and monthly during operate. The standing agenda is progress against the statement of work, open risks, data-access items, and decisions that require the owner. Minutes are short and are filed in the decision log with the date, the options considered and the decision taken.

The model owner is a client role. That person is accountable for intended use, for approving retraining, and for pausing the system if monitoring shows a breach of the agreed limits. Singaporewithai does not act as model owner. Our engagement lead prepares the material the owner needs and records the outcome.

Change control covers prompts, features, training data, evaluation sets, dependencies and access. A change is proposed in writing, reviewed against the original intended use, and either accepted, delayed or declined. Emergency rollback does not require a full change cycle, but it does require a record within one working day.

Escalation runs from the engagement lead to the client owner, then to the steering group sponsor. If a disagreement concerns personal data or production risk, work on the affected path pauses until the sponsor records a decision. The decision log is the system of record for those events.

Controls

Risk and assurance controls

Access segregation

Engineers use named accounts in the client's identity system. Shared passwords and unmanaged copies of extracts are not used.

Prompt and output logging

Prompts, retrieved sources, outputs and reviewer actions are logged at the level the client's policy allows, with retention agreed in the statement of work.

Test datasets

Evaluation uses a labelled or held-out set the client controls. Production data is not used as the sole proof of quality.

Bias testing

Where protected or sensitive attributes are available and lawful to use, we test for differential error and record the result, including the decision not to use an attribute.

Rollback plan

A rollback path is written and exercised before go-live, including who can trigger it and how users are told that the system has been paused.

Vendor dependency register

Each third-party model or interface is listed with region, data-processing terms, an alternative and the owner who would enact that alternative.

Retention schedule

Training snapshots, logs and labelled samples are kept only for the period agreed with the client, then deleted or returned according to that schedule.

Incident procedure

An incident covering data, quality or availability has a named client contact, a severity scale and a first-response window stated in the operating agreement.

Measurement

How we measure progress

Progress measures are defined with the client before work starts and are written into the statement of work. They are a mix of process measures and adoption measures. Process measures include whether access was granted on the planned date, whether the evaluation sample was labelled, whether documentation was delivered at phase end, and whether the rollback rehearsal was completed. Adoption measures include whether the exception queue is staffed, whether the reviewer is completing the agreed cases, and whether the output is being read in the system of record rather than in a side file.

Quality measures sit on the client-controlled sample: precision and recall by document type, forecast error on held-out periods, or answer faithfulness on an evaluation set of questions. Thresholds are set with the process owner. They can be changed only through change control.

We do not publish client outcome figures. We do not use percentages, time-saved claims or return figures on this website or in marketing material. Figures that appear in an engagement stay inside that engagement. If a prospective client asks for references, we describe anonymised patterns of scope and duration, which is the same standard used on our overview page.

Team reviewing a written plan — Measures are agreed in writing before a phase opens

Commercial

Commercial framework

Work is contracted as fixed-scope phases. Each phase has a written statement of work that names the engagement lead, the client owner, the deliverables, the duration, the assumptions about access, and the notice period. A later phase does not start automatically. It starts when the owner accepts the previous phase and signs the next statement of work.

The engagement lead is named and is the day-to-day counterpart for the client owner. Substitutions are notified in advance except where illness or an incident requires a short cover arrangement. Notice periods for ending an operate agreement are stated in that agreement. We do not publish prices on this website. Indicative effort is discussed once the process, systems and constraints are clear enough to write a scope.

Discuss a programme with Singaporewithai

A scoping call is used to establish whether an assess phase is warranted. Bring the operational question, the system that must receive the output, and the policy constraint that the work must meet.

Request a scoping call