Seven areas of work are specified as one programme so that a production system has data, a model, an owner and a review point. Clients draw on the combination that the use case actually requires, rather than buying isolated tools.
Capabilities are combined around a single operational question
Singaporewithai is engaged when a large organisation has a concrete process that is slow, opaque or dependent on a small number of specialists, and when leadership wants a system that can be inspected after it goes live. The seven areas below are the work we actually perform. They are not a catalogue of products. A typical programme starts with readiness, spends most of its effort on data and the chosen system type, and closes with model operations or an assurance review if the system already exists.
We insist on a written use case, a named client owner and a statement of the decision the system is expected to support. Without those three items, a model can be trained and still fail to enter production. Document intelligence, forecasting and assistants look different in the interface, yet they share the same requirements: lineage, access control, evaluation, a human review point and an operating procedure. That is why the areas are offered together.
Scope is fixed by phase. If the data cannot support the original question, we say so at the end of assess and propose a narrower question or a foundations phase. We do not expand into adjacent processes unless the statement of work is amended in writing.
Capability
AI readiness review
An AI readiness review is a time-boxed assessment of whether a stated operational question can be supported by the data, systems and governance the organisation already has. We inventory sources, describe their quality and lawful use, and identify the applications that must receive an output if the work is to change how staff actually operate. Use cases are shortlisted against feasibility, cost, data risk and the presence of an owner. A feasibility and cost estimate is written so that a steering group can approve, decline or sequence the work without waiting for a second study.
The review also produces a governance gap list. Gaps commonly include the absence of a model owner, missing retention rules, unclear access to production logs, or a policy that speaks about artificial intelligence in general terms without naming a review step. The list is mapped to the client's internal risk policy and, where relevant, to the IMDA Model AI Governance Framework as a reference for practice.
Capability
Data foundations
Data foundations are the pipelines, lineage, quality rules, access control and warehouse or lakehouse structure that later models depend on. Without them, a pilot can look convincing on a static extract and still be impossible to retrain, audit or restrict by role. We design the minimum structure required for the approved use case, inside the client's existing estate, rather than proposing a new platform as a precondition.
Lineage is recorded so that an internal auditor can see which source fed which feature and which model version. Quality rules are written with the data steward and fail loudly enough that silent drift is visible. Access control follows the client's identity system. Where the client requires data residency in Singapore, storage, processing and backup locations are treated as design constraints. Open formats are preferred so that handover does not depend on a tool we uniquely operate.
Capability
Decision and forecasting systems
Decision and forecasting systems cover demand, capacity, pricing and risk models that a planning team will actually use. The work includes feature definition with the process owner, back-testing on held-out periods, and integration with the planning tools already in the operating rhythm. A model that exists only in a presentation does not meet the standard for this capability.
Human review is placed on outputs that carry material operational, customer or financial impact. The reviewer is a named role, and the cases that require review are defined in writing before go-live. We document intended use, known limitations and the conditions under which the forecast should be paused, for example a supply shock that takes the inputs outside the range seen in training. Change control covers features, training windows and any third-party model that the forecast depends on.
Capability
Document intelligence
Document intelligence is the classification, extraction and validation of contracts, claims, shipping and compliance documents. The operational value sits in the exception queue as much as in the automatic path. Low-confidence extracts are routed to a human reviewer with the source page visible. Accuracy targets are set with the process owner against a labelled sample the client controls, and they are reported by document type rather than as a single headline figure.
We plan for multilingual files, mixed scans and templates that change without notice, which is the normal condition of trade and claims work in Singapore and the wider region. Validation rules encode the checks staff already perform, so that the system does not invent a new operating procedure on the day it goes live. Logging retains the model version, the confidence, the reviewer action and the final fields written to the system of record.
Capability
Enterprise assistants
Enterprise assistants are retrieval-augmented systems over internal knowledge. Retrieval-augmented generation means the model is required to search an approved corpus and to ground its answer in retrieved passages, rather than answering from an unbounded training set. Source citation is mandatory for answers that staff may act on. Permissioning follows the access controls already applied to the underlying documents, so that an assistant does not become a path around records management.
Logging captures the question, the retrieved sources, the answer and the user identity at a level the client's policy allows. The cost of a wrong answer is treated as an operational risk, which is why we define refuse conditions, a human escalation path and a corpus owner. Assistants are not deployed against unrestricted internet content on this programme type. The corpus, the roles and the evaluation questions are agreed before build.
Capability
Model operations
Model operations, often called MLOps, is the practice of deploying, monitoring and retraining models in production with a documented rollback. A system without these procedures is a pilot that happens to be reachable on a network. We implement deployment paths that the client's platform team can operate, monitoring for data and performance drift, retraining schedules agreed with the model owner, and a rollback procedure that has been exercised at least once before go-live.
Alerts are routed to a named role, not to a shared inbox that nobody owns. Dependency on a third-party model or application programming interface is recorded in a vendor register with a stated alternative. Retention of logs and training snapshots follows the schedule agreed for the use case. This work continues only under a signed operating agreement. Without that agreement we complete handover and revoke our production access.
Capability
Assurance review
An assurance review is an independent inspection of an existing artificial-intelligence system, whether we built it or another vendor did. We read the documentation that exists, reconstruct what is missing, test bias and robustness where the relevant attributes are available and lawful to use, and map controls to the client's risk policy. The output is a findings report and a remediation plan with a suggested sequence and named owners on the client side.
The review is not a certification and is not an endorsement of the system. It is a working document for group risk, internal audit and the model owner. Where we find that a system cannot be documented well enough to review, we say so and recommend that documentation be completed before further feature work. Remediation can be performed by the original vendor, by the client, or by Singaporewithai under a separate statement of work.
Formats
Engagement formats
Typically three to twelve monthsAdvisory retainer
A retained advisory engagement supports a standing steering group, reviews proposals from other vendors, and keeps the decision log and policy artefacts current. The team is a senior delivery lead with scheduled specialist time. It is used when the client already has build capacity and needs an independent view on scope, risk and go-live readiness.
Typically two to four weeksDiscovery sprint
A discovery sprint tests whether a stated question is feasible on the data and systems that can be reached in that window. The team is a delivery lead and one engineer, working with the client owner and data steward. The output is a go or no-go recommendation, a draft scope and a list of access items that a later foundations phase would require.
Typically fourteen to twenty-three weeks plus operateBuild programme
A build programme runs assess, foundations and build for a single approved use case, then operate if an agreement is signed. The team is an engagement lead, two to four engineers depending on integration depth, and a documentation analyst. Client counterparts are the owner, a data steward and the reviewer who will sit on production outputs.
Typically three to six weeksAssurance review
An assurance review inspects an existing system and returns findings and a remediation plan. The team is a lead reviewer and one engineer, with access arranged by the client model owner. Duration depends on the completeness of documentation and on whether test datasets can be produced without a new extract of personal data.
Formats are chosen after the operational question is written down
Technology
Technology posture
Singaporewithai is cloud-agnostic and model-agnostic. We work within the client's existing estate and do not require a platform migration as a condition of delivery. Where a control cannot be met on the current platform, that fact is recorded and options are presented to the client owner. We do not standardise every engagement on a single foundation model or a single vendor.
Where the client requires data to remain in Singapore, storage, processing, logging and backup locations are designed to honour that requirement. We prefer open formats for documents, tables and model artefacts so that handover does not depend on a tool only we operate. All code, prompts, evaluation sets, runbooks and decision logs produced under the statement of work are delivered to the client at the close of each phase.
Third-party model services are treated as vendors with a recorded dependency, an alternative and a region. We do not place production credentials in shared notebooks. Environments used by our engineers follow the client's access-control and logging standards.
Boundaries
Scope boundaries
We do not resell licences for models, clouds or productivity suites. Clients contract those licences directly with the vendor so that support, region and data-processing terms remain under the client's control. We do not take custody of production systems without a signed operating agreement that names owners, access, incident hours and notice periods.
We do not deliver work that cannot be documented and reviewed. If a requested system has no accountable owner, no evaluation set and no human review point, we will not take it to go-live. We do not publish client outcome figures, conversion claims or performance percentages. Progress measures are defined with the client before work starts and remain inside the engagement.
We do not provide legal advice, and we do not present alignment with the Personal Data Protection Act or the IMDA Model AI Governance Framework as a certification, accreditation or endorsement.
Questions
Frequently asked questions
How long before a first production system?
A first production system typically follows assess, foundations and build. Assess takes two to three weeks. Foundations take four to eight weeks depending on the state of data access and quality rules. Build takes eight to twelve weeks for a single, well-bounded use case with a defined human review point. Elapsed time is longer where personal data approvals, vendor contracts or integration slots sit on the client calendar. We do not treat a notebook demonstration as production. Production means the system is documented, monitored, owned, and able to be rolled back.
Do you work with our existing cloud provider?
Yes. We are cloud-agnostic and model-agnostic. Work is carried out inside the client's existing estate wherever that estate can support the required controls. We do not require a migration as a condition of engagement. If a control cannot be met on the current platform, we record that as a constraint in the statement of work rather than switching provider on our own initiative. Where the client requires data to remain in Singapore, we design storage, processing and logging to honour that requirement on the platforms already approved by the client.
Who owns the models and code?
The client owns the models, prompts, documentation and code produced under the statement of work, together with the labelled datasets the client supplied or approved. Third-party model licences remain with their vendors; we do not resell those licences. At the close of each phase we hand over repositories, model cards, data lineage notes, runbooks and the decision log. Access credentials used by our engineers are revoked when the phase ends unless an operate agreement says otherwise.
How do you handle personal data during discovery?
Discovery uses the minimum subset required to test feasibility. We agree that subset, the lawful basis the client will rely on, and the retention period before any extract is made. Where a synthetic or strongly masked sample can answer the question, we prefer it. Our engineers access client environments under the client's access-control policy. We do not copy personal data onto unmanaged devices. Notes that could identify an individual are kept in the client's workspace. The Personal Data Protection Act obligations remain with the client as the organisation that determines the purpose of the processing.
Can you review a system another vendor built?
Yes. An assurance review is a defined engagement. We inspect documentation, training and evaluation data, access control, monitoring, rollback, and the mapping of controls to the client's risk policy. We run bias and robustness tests where the relevant attributes are available and lawful to use. The output is a written findings report and a remediation plan with owners and suggested sequence. We do not require that the original vendor be replaced. If documentation is missing, the first recommendation is usually to reconstruct it before further model work.
What does the client team need to provide?
A single accountable owner with authority to decide on scope, data access and go-live. A data steward who can explain sources, quality and lawful use. Access to the systems that will receive the output, and time from the staff who will operate the exception queue or review step. For document work, a labelled sample of sufficient size and recency. For assistants, an approved corpus and a permission model that already exists or can be stated. Steering time of about ninety minutes every fortnight is typical during build.
How do you price work?
Work is priced as fixed-scope phases with a written statement of work for each phase. The statement names the engagement lead, the deliverables, the client owner, the duration and the notice period. We do not publish a rate card on this website. Indicative effort is discussed in the scoping call once the process, systems and constraints are clear. Advisory retainers are scoped in months. Discovery sprints are scoped in weeks. Build programmes are scoped by the approved use case, not by an open-ended backlog.
What happens after go-live?
Go-live is not the end of the system. Model operations cover monitoring, drift detection, retraining schedules, rollback and incident procedure. Those activities continue only under a signed operating agreement. If the client prefers to operate the system with internal staff, we complete a handover of code, documentation and runbooks and remain available for a defined hypercare window. We do not retain production credentials after handover unless the operating agreement says we must.
We use one cookie to remember whether you accepted this notice. No analytics or advertising cookies are set. See our cookies page for details.
