Turning the Team’s Daily Repetitive Work Into a Toolset That Does the Math Itself

In one sentence: An engineering company doing geotechnical instrumentation monitoring, site investigation, and water treatment has a team that performs a large volume of repetitive manual work every day — transcribing readings, checking them against thresholds, compiling daily reports, organising borehole data, and assembling progress-claim paperwork. This work follows clear rules, comes in high volume, and is error-prone — exactly the kind of work that should be handed to a tool. This piece first lays out that repetitive work clearly, then explains how an internal toolset already built automates it. Behind it is a simple, reliable principle: AI handles writing the interface and doing the software-development work, driving cost down to the bare minimum; but every number and every judgement runs through hard-coded deterministic code, never left to AI to compute on the fly.

Companion: At the end there is a hands-on internal workbench demo you can click through yourself — all four tools accept real data and produce real outputs.

1. First, understand what data this company handles

To build the right tools, you first have to be clear about what data the team faces every day. The company has three business lines, each corresponding to a class of data:

① Geotechnical instrumentation monitoring (the core business) — burying sensors at MRT, tunnel, and deep-excavation sites to watch whether the ground is settling, whether buildings are tilting, and whether the struts are holding.

Each monitoring point generates readings every day (how many millimetres of settlement, how much pore water pressure, how many kilonewtons of strut axial force), and every one must be judged against three safety lines: the Alert line, the Action line, and the Suspension line. This “three-tier traffic-light” system is a mandatory requirement for deep-excavation monitoring in Singapore, and every monitoring report revolves around it.

② Site investigation — boring holes and taking soil samples before works begin, logging the strata, running Standard Penetration Tests (SPT), and testing soil samples. The data must be compiled into borehole logs and delivered to the designer in the industry-standard AGS4 format (a plain-text data format).

③ Water treatment (accumulated technical capability) — the company has a technical foundation in membrane-based water treatment (its own membrane brands PoraMax / PermaMax / PuroMax, plus consumer products such as Vavie alkaline water and disinfectant). This line deals with water-quality data: effluent pH, COD, BOD, and so on must be checked against PUB discharge limits to determine compliance, and the membrane system must be watched via trans-membrane pressure to decide when to clean.

The three lines differ in data form (time-series readings / structured tables / online water quality), but what they share is this: the judgement rules are all well-defined, all highly repetitive, and all done by hand.

2. What exactly does the team repeat every day

Laying out this repetitive work makes it clear what the tools should solve. All of the following follow clear rules and are well suited to automation:

Monitoring - Compiling readings each day / each week into the daily and weekly reports submitted to the client (the highest-frequency and most time-consuming) - Checking each point against the three-tier thresholds and flagging exceedances - Notifying and tracking exceedance events - Monthly trend charts and interpretation

Site investigation - Entering borehole logs and drawing borehole logs (strata columns) - SPT N-value → density / consistency classification (table lookup) - Generating and validating AGS4 deliverable files

Contracts / finance - Tracking completed-but-uninvoiced amounts (contract assets) - Preparing progress-claim supporting documents and chasing invoicing progress

Water - Checking effluent quality against discharge limits and producing compliance records - Tracking membrane-system operating-parameter trends

Among all of these, the one most worth building into a tool first is the “monitoring daily report” — the highest in frequency, the most labour-intensive, and the most rule-based. So the tooling starts there and then extends to cover the other three classes.

3. One principle: AI writes the interface, code computes the numbers

Before getting hands-on, let’s be clear about the single most important design principle for the whole toolset. It comes down to one sentence:

Use AI to write the code and do the software-development work, driving development cost down to the bare minimum; but all number-crunching, threshold judgement, and compliance comparison runs through hard-coding (fixed, deterministic logic), never left to AI to compute on the fly.

Why insist on this split? Because AI and “hard-coded code” each have their own nature:

• AI’s strength is “writing”: writing interfaces, writing copy, generating code — fast and good, able to compress months of a software team’s work into a few days, so development cost drops off a cliff.
• AI’s fatal weakness is “computing”: it “hallucinates” — fabricating numbers with a straight face, and possibly giving different results for the same input. But for things like threshold judgement, billing, and compliance, getting it wrong even once means an incident or a dispute.
• “Hard-coded code” is exactly the reverse: it does not write pretty interfaces, but it is deterministic, auditable, and reproducible — the same input always yields the same output, an engineer can review it line by line, can explain it to a regulator, and can sign off on the report and bear responsibility.

This is not theory; it is an approach already proven in practice. The same playbook has produced two real products:

The entire 3D editor, the whole interface, and the full multilingual translation were built by AI in a few days — work that used to take a team months. But the moment it touches “how much to charge” or “how much salary to pay”, it switches straight back to hard-coded code, and AI is not allowed to touch a single number. The monitoring tools follow exactly the same reasoning.

4. Four tools: actually finishing the repetitive work

Following the principle above, an internal workbench was built. The four tools correspond to the four classes of repetitive work above, and each one can take in data, compute automatically, and produce an output — they are not view-only display boards you cannot actually use.

Monitoring daily report · one-click report

Enter the day’s readings → the system applies each point’s three-tier thresholds in real time to determine status and computes the daily change → one click generates a printable, submittable formal daily report (with the firm’s letterhead, exceedance details, a written interpretation, and an engineer’s signature block). A report that used to take one person most of a day to compile now takes seconds to form; the engineer only needs to review and sign.

Borehole · AGS4

Enter the soil layers and SPT readings → draw the borehole log in real time and, by table lookup, turn the N-value into “loose / medium dense / dense” → generate and validate the AGS4 deliverable file (automatically checking whether depths are continuous, whether N-values are valid, and so on). The whole chain of manually organising investigation data, drawing the log, and assembling AGS4 is done in one pass.

Progress-claim ledger

Enter completed-but-uninvoiced amounts by status → automatically split them into “ready to invoice now / awaiting acceptance / retention / disputed” and compute ageing → generate a supporting-document checklist for each progress claim.

Water-quality compliance

Enter effluent quality → automatically check it against PUB discharge limits (switchable between discharge to watercourse / to sewer) to determine compliance → predict when the membrane should be cleaned from the trans-membrane pressure trend, and produce the compliance record directly.

The workbench also features automatic light/dark switching (following the system, with manual override), mobile adaptation, and an at-a-glance icon for every button.

👉 Try it hands-on: Tritech Internal Data Workbench (demo)

5. How these tools are actually built

It is no mystery — in fact, almost surprisingly plain.

Overall architecture: it is simply a web application (HTML + JavaScript), with all the core computation running in the browser, no server and no database required. It can be hosted as a static file on very cheap hosting, or even placed on the company intranet. AI (Claude / Codex) wrote all of the interface, charts, copy, and glue code — built in a few days; while the “computing the numbers” part is a set of hand-written deterministic functions, a few dozen lines that cover all the decision logic.

The data flow of each tool (all the same pattern: data in → deterministic function computes → result out):

Why this implementation approach matters: because it is “AI-written interface + a few dozen lines of deterministic functions”, one or two people can build and maintain it, with no need to keep a software team. To add a new type of monitoring point or change a threshold, you just change a few constant lines (the tool already lets you add monitoring points and change thresholds directly in the interface). This is exactly where the “AI writes the code, numbers are hard-coded” playbook drives development cost down to the bare minimum.

What still needs a person (stated honestly): data entry, or integrating an existing datalogger, still needs a person; the engineer’s review and signature step can never be removed; and each project’s thresholds must be set by an engineer according to that site. What the tool takes over is the repetitive labour of “organising, computing, and formatting” — not “judgement and accountability”.

6. Is this something the company genuinely needs? How much labour is it expected to save?

This is the question most worth being rigorous about — not “can it be done”, but “is it worth doing, and how much does it save”. I assess each one honestly against the real situation.

6.1 Of the four tools, which are genuinely essential

Conclusion: the one that should go live now and returns the most is the monitoring daily report; borehole and progress claim come next; the water-quality tool, frankly, sees little use right now — leave it for later.

6.2 How much labour it saves (a transparent model you fill with your own numbers)

Three honest caveats first: (1) “how many hours it takes to compile a monitoring report by hand” cannot be found as a third-party measured figure — the only public numbers are vendor claims like “automation saves 80% of admin time” (vendor-reported, not independently audited); (2) the tool runs on synthetic demo data — this is a demo, not a deployed system (see 6.3); (3) so what follows is not a “conclusion” but a model with every assumption on the table that recomputes once you plug in your real numbers.

The method is one multiplication chain: > Labour saved per site per month = manual hours per report × reports per month × proportion automated × fully-loaded hourly cost

Each factor stated as a low / base / high band (the last column is what you calibrate with real data):

Multiplied out (one site · per month):

This is one site. The total = the table above × your true number of concurrently active monitoring sites. E.g. 6 sites at the base case ≈ 1.1 FTE + about S$6,000/month of data-processing labour, plus more consistent report quality and fewer errors.

Subtract cost from the saving (TCO — don’t only count what’s saved): tool build / outsourcing, integration with existing datalogger/TEMS, staff training, post-launch maintenance and support, listed-company security review — these are one-off + ongoing costs that must enter the payback calculation. “One or two people, no server” keeps this low, but not zero.

“Takes seconds” and “saves 1.5–4 hours” are not in conflict: report generation is indeed seconds; what’s saved is the 1.5–4 hours of manual pull-readings + threshold-check + formatting that comes before it. The engineer’s review + signature time is not saved — that’s already excluded by counting only 50–70%, not 100%.

Progress claim is not in the table above: the paperwork hours it saves are small; its real value is faster invoicing and getting cash back sooner — which should be quantified separately via DSO (days sales outstanding), invoice-lag days, and contract-asset ageing (the tool already shows ageing buckets), not folded into “headcount saved”. Borehole / AGS4 is likewise per-project; vendors claim a single log drops from several hours to ~10 minutes (Civils.ai, self-reported), conservatively ~70% saved.

The largest and most stable labour-saving point is “that daily monitoring report”; the rest are bonuses. But before any rollout, every figure must be calibrated with a 2-week time-and-motion study on 1–2 of your real sites (before/after, itemised) — that is the only basis a CFO will trust, and the tool can log this time for you.

6.3 Is this a demo, a pilot, or production? Don’t blur the three

The “how data gets in” column in the §5 table (“can ingest datalogger CSV / TEMS exports”) is a pilot/production roadmap; the demo today uses manual entry — don’t read it as a current capability.

6.4 How it actually goes live (the production control layer — design before budget)

“No server, no database” is what lets the demo stay minimal; real deployment — ingesting TEMS, formal submission, listed-company compliance — needs a control layer on top, at minimum:

• Threshold registry: who sets each site’s three-level thresholds and on what calculation basis, versioned, approvable, traceable.
• Data ingestion: datalogger/TEMS field mapping, units, timestamps, duplicate/missing-reading handling, QA rules.
• Signing & compliance: identity authentication, audit trail, report version locking, e-signature legality, submission records — heavier than the demo’s blank signature box.
• Access & security: account/role permissions (RBAC), access audit, data-retention policy; user input is already escaped against injection, but a proper security review is still required for production.
• Integration with existing systems: accounting/ERP (progress claims), document management (report archive).

It needn’t all be built at once, but there should be at least a one-page architecture before budget is approved — otherwise “how do we go live once it’s approved” has no answer.

7. Why the numbers must be computed by code, not by AI

This is the bedrock of the whole toolset’s reliability, and it deserves to be set out on its own.

Monitoring reports submitted to clients and regulators must be signed off and made the responsibility of a licensed engineer (QP). If AI were left to “read” sensor data and write it into the report, and it hallucinated a reading that does not exist — turning 2 mm of settlement into 20 mm — that would be a serious incident.

So the correct division of labour has three parts, none of which can be omitted:

This way you capture the efficiency and low cost that AI brings, without moving the engineering red line of “reliable numbers, clear accountability” one inch. Click “Computation logic” in the top-right of the workbench to see the real decision code — just a few plain table lookups and if statements, with no AI involved at all.

8. What this toolset delivers

★ Three takeaways ─────────────────

First, list the work before building the tool. This is not using AI for the sake of using AI; it is first laying out clearly the work the team genuinely repeats (monitoring daily reports, borehole organisation, progress claims, compliance), then building tools to target it — each one aimed at a specific, high-volume, clearly-ruled task.

Second, AI writes the interface, code computes the numbers. This division lets one or two people build a tool that used to take a software team months, while guaranteeing that every number is auditable and can be signed off with accountability. What is saved is not some single sum of money, but the very need to “keep a development team”.

Third, the tool is there for people to use, not to bear responsibility for them. It takes over the repetitive labour, letting engineers move from “transcribing data and formatting reports” back to “reading trends, making judgements, signing off” — hours are saved, and quality is actually more consistent.

────────────────────────────────────

This approach is universal for any team that does repetitive work by hand: first find the step where “a person sits and shuffles data” and let code take it over; hand the interface and the text to AI and weld every number into the code; and finally leave one step for a person to review and sign.

To see what it actually looks like, click here and try it hands-on: Tritech Internal Data Workbench — all four tools take in data and produce real outputs, with automatic light/dark and mobile support.

Appendix · Sources of the criteria used in the tools: the three-tier monitoring thresholds (Alert/Action/Suspension) follow Singapore deep-excavation monitoring practice; the SPT classification and AGS4 data format are site-investigation industry standards; the water-quality limits reference the order of magnitude of PUB discharge standards (the demo uses synthetic data for illustration, not real project readings). StoreySG and Salon OS are actual products built with the same “AI writes the code, numbers are hard-coded” method.