Your water
Enter it once — every answer below uses it.What are you treating?
Picks the chemistry that matters and highlights the right tools.Will this water scale?
How far it can concentrate before something drops out.
—cycles
Enter or pick a water to see the limit.
What should I do?
The lever that lets it run — and what to check.
—
Segment chemistry
Sour, acid-drainage or oxygenated water carries scales the standard read doesn't cover.
Go deeper
Four tools, in the order you'd use them. Highlighted for your segment.Every number carries its assumption. Simple hides the working; Expert shows it. Need the full console? Open the advanced console →
Water analysisiYour makeup water, as analysed. Alkalinity is mg/L as CaCO3; everything else is mg/L as the ion. Ba and Sr matter far more than their size suggests — barite scales at fractions of a mg/L and is effectively irreversible. Leave a field at 0 only if you know it is absent: 0 means absent, not unmeasured, and the two produce different answers.
Paste a water analysis — a lab CSV (
ca,mg,alk,... with a value row) or a two-column field,value export. Aliases like “Calcium”, “Alkalinity”, “Conductivity” are recognised. Imported data is tagged caller-supplied and validated — an impossible value is rejected, never guessed.charge balanceiA quality check on the analysis, not on the water. Cations and anions must balance; a large error means an ion is missing, mistyped, or reported in the wrong units. Policy: the industry treats an imbalance over 5% as not lab-usable — under 5% is good, 5–10% means verify the lab report before trusting anything below, over 10% means the analysis is unreliable and the indices should not be trusted. We show the imbalance and still compute, so you can see exactly how far off the analysis is rather than have it silently reconciled — but the label tells you when the input itself is the problem.—
ConditioniThe operating point you are asking about — makeup water after cycling (cooling) or concentration (RO). For RO this is reported at the membrane wall (CF × β), not the bulk concentrate, because scale nucleates at the wall. The engine tag shows which model produced it.Davies
Mineral saturationiSI = log(IAP/Ksp). SI > 0 means the water is supersaturated and can scale; SI < 0 means it cannot. SI is a thermodynamic tendency, not a rate. It tells you whether scale is possible, never how fast — kinetics, nucleation and induction time are not modelled. Silica is reported against amorphous SiO2. A blank means the element was not supplied.SI = log₁₀ IAP/Ksp · >0 scaling
Operating-range simulationiThe same calculation swept across cycles (or recovery), so you can see where the limit actually falls rather than testing one point. The limiting phase is whichever crosses SI = 0 first, and it is often not the one you expect — silica ends the argument more often than calcite on Indian borewell water. A gap in a line is a point PHREEQC could not converge, shown as a gap rather than a plausible wrong number.
Scroll to zoom · drag to pan · pinch on touch · hover for values
These numbers answer what can happen. The intelligence layer answers what is happening and what to do — cycle limit, sensitivity, cycles balance and program cost. Microbial control answers what your biocide is actually doing — halogen speciation at this pH, holding time, and the phosphorus ledger. Both run from this analysis.
Incompatible-water mixingiTwo waters that are each safe alone can scale badly when mixed. The classic case is seawater injection: sulfate-rich seawater meeting barium-rich formation water precipitates barite (BaSO₄) at the mixing front — each water is undersaturated on its own, but the blend has both ions, and the risk is often worst at an intermediate ratio. This tool fabricates no chemistry: it conservatively blends the water above (A) with a second water (B) across the mixing range and runs each blend through the same saturation engine as the rest of the console. SI is a thermodynamic tendency, not a rate; pH and temperature are blended linearly (a labelled approximation).A = the water above · enter water B
Water A is the analysis on the left. Enter water B below — the second stream you would mix with it.
Barite scales at fractions of a mg/L and is effectively irreversible — enter Ba/SO₄ carefully.
Enter water B and scan — the tool finds scale the mixture forms that neither water forms alone.
Candidate moleculeiAny molecule, as SMILES. This is a structure-based pre-screen: it needs no data about the molecule beyond its structure, which is exactly why it can rank things nobody has tested — and exactly why it cannot tell you how well they work.
Structure-based pre-screen — two axes. Corrosion inhibition and scale inhibition work by different mechanisms, so they are scored separately and never combined. Both axes are uncalibrated.iTwo different limitations. Descriptors are exact RDKit output. Corrosion axis (N/S/aromatic lone-pair donation to metal) is a real but uncalibrated proxy — wet-lab data would improve it. Scale axis (Ca-binding groups per heavy atom) is likewise uncalibrated. Applying either axis to the other mechanism is not a calibration gap — it is inapplicable: threshold scale inhibition has no nitrogen term, so no amount of data would make the corrosion score predict it. Neither sets dose.
StructureiRDKit's parse of your SMILES, drawn back. Its only job is to let you catch a typo before you read anything into the numbers — a misplaced bracket is still valid SMILES, just a different molecule.
—
Mechanism scoresiScored on two axes, never merged. Corrosion = adsorption-centre proxy. Scale = anionic-density proxy. Both uncalibrated; each is meaningless for the other mechanism. A molecule scoring high on the wrong axis tells you nothing.
—% corrosion axis
adsorption proxy · uncalibrated
adsorption proxy · uncalibrated
—% scale axis
Ca-binding proxy · uncalibrated
Ca-binding proxy · uncalibrated
DescriptorsiExact, computed, not estimated. MW, logP, TPSA, atom and motif counts come straight from RDKit and are the most trustworthy numbers on this page. The scores are derived from these; the descriptors themselves are simply facts about the structure.
Compliance screeniPolicy, not chemistry. These are discharge and compatibility rules you choose — they say nothing about whether a molecule works. Note that P-free rejects every phosphonate, which means it rejects the best CaCO3 threshold inhibitors known. That is a deliberate consequence of your envelope, not a verdict on the chemistry. RO adds exclusions cooling has no concept of — cationic charge irreversibly fouls polyamide membranes.
Reference library — ranked within mechanismiReal actives, grouped by how they work and ranked only inside that group. Cross-mechanism ranking is meaningless: it is what once put a caffeine control above HEDP. Entries marked “(unit)” are polymer repeat units and are not rankable at all — their score moves with how many units you draw, and most real antiscalants are polymers.never across
Segment species — sour / acid-drainage / boiler (optional; leave blank for cooling & RO)
All ions mg/L. This water is used by every step below and never touches the Scale & Corrosion tab.
Tools in Diagnose
Pick a tool above to see it — or show all.
01
Cycle limitiThe limiting salt sets the ceiling. Bisects to the highest cycles of concentration at which every phase stays under its practical limit. Run it with and without an antiscalant — the gap between the two is what the chemical actually buys you. Kinetically inhibited phases (dolomite, talc) are excluded: they are supersaturated almost everywhere and never form, so left in they would limit every answer.
How high can this water cycle before something drops out?
Uses the makeup water above.
Run it to find the limiting salt and the ceiling it sets.
02
SensitivityiWhere to spend lab budget. Each input is perturbed and we watch the limiting phase move. Most analyses have one number doing all the work and several that could be badly wrong without changing the decision. This tells you which is which.
Which measurement is deciding that answer — and is it the one you trust least?
Uses the makeup water above.
Run it to rank every input by how much it moves the limiting phase.
02
Thermal performance · approach-efficiency & fouling factoriWhat fouling has cost you in cooling capacity — from the temperatures you already log. Two textbook, deterministic reads. Tower effectiveness: range = hot-in − cold-out, approach = cold-out − wet-bulb, effectiveness = range/(range+approach) — a tower cannot cool below the wet bulb. Heat-exchanger fouling resistance: Rf = 1/Uservice − 1/Uclean, the added thermal resistance from deposits (Uservice entered, or derived from duty÷(area×LMTD)). The honesty seam: every quantity is closed-form heat-transfer arithmetic — no fitted model, no fabricated coefficient. The commissioning design approach and the clean-design U are ENTERED from your datasheet, never from memory; without a baseline the current metric still computes but the degradation / fouling-resistance piece is INCOMPLETE, never a fabricated default. Impossible readings (cold water below the wet bulb, a service U above the clean U) are flagged with a reason, never computed into a plausible-wrong number. Cooling only.
Turn your operating temperatures into a thermal-condition read — the tower's approach-efficiency and the exchanger's fouling resistance. Baselines are yours; nothing is assumed.
All deterministic heat-transfer arithmetic; the design approach and clean U are your entered baselines, never from memory; a missing baseline is flagged, never guessed.
Tower thermal effectiveness (from temperatures)
Heat-exchanger fouling resistance (from overall U)
Deterministic; baselines yours; a missing baseline or an impossible reading is flagged, never fabricated.
Enter the tower temperatures (hot-in, cold-out, wet-bulb) and/or the exchanger coefficients (clean U with service U, or duty + area + LMTD) to read the cooling thermal performance.
03
SDI / pretreatment screeningiIs this water fit to feed the membranes? The Silt Density Index — the standard RO feedwater fouling-potential screen, computed exactly from ASTM D4189: %P = (1 − ti/tf)×100, SDIT = %P/T. The honesty seam: the SDI is exact ASTM arithmetic — no fitted model, no fabricated coefficient. The ASTM validity is enforced: above 75% plugging the result is unreliable and flagged (repeat with a shorter T), never reported as a plausible-wrong SDI. The acceptability band uses the spiral-wound guideline (SDI15 warranty ≈5, preferred ≈3) as a LABELLED default, overridable by your membrane's own warranty limit — never dressed up as calibrated to a plant. The pretreatment recommendation is a class from published selection practice; the SDI a pretreatment will ACHIEVE is never predicted — that needs a pilot. RO-only (the test is defined for pressure-driven membrane feedwater).
Run the bench test into a fouling-potential band — and, where the water isn't fit, the class of pretreatment to consider. Limits are the guideline default or yours; nothing is assumed.
Exact ASTM D4189 arithmetic; the <75% plugging validity is enforced; the band uses a labelled, overridable guideline; the achieved-SDI-after-pretreatment is never predicted.
Exact ASTM arithmetic; validity enforced; band from a labelled guideline; the achieved SDI after pretreatment is never predicted.
Enter the initial and final sample times (seconds) and the test time (minutes) to compute the ASTM D4189 SDI and screen the feed.
04
NORSOK M-506 · CO₂ corrosion rateiA second published CO₂-corrosion band, beside the de Waard–Milliams estimate. NORSOK M-506's semi-empirical rate for carbon steel: CR (mm/yr) = Kt·fCO₂0.62·(S/19)0.146+0.0324·log fCO₂·f(pH). The honesty seam is the point of this tool: the method is assembled deterministically here — CO₂ partial pressure by Dalton (x·P), fugacity, the shear term, the product — but the two most error-prone, strongly-tabulated NORSOK constants are NEVER supplied from memory: Kt (the 9-point temperature table) and f(pH) (the pH polynomials) are ENTERED from your copy of the standard. They are standardized values in the same class as ASME limits — reproducing a safety-relevant published polynomial from memory, subtly wrong, would be worse than requiring it. Without Kt the rate is INCOMPLETE. The stable method exponents (0.62, 0.146/0.0324) are LABELLED NORSOK defaults, overridable — verify against the standard. The fugacity coefficient and f(pH) default to a conservative 1.0 (LABELLED); enter the real values. This is a published-model ESTIMATE, not calibrated to your field, and it can diverge from de Waard–Milliams; localized/pitting attack, H₂S/sour cracking and inhibitor availability are not covered. Sour (O&G) only.
Assemble the NORSOK M-506 rate deterministically — you supply the standard's Kt and pH factor; nothing is invented. A second band beside de Waard–Milliams.
The method is assembled deterministically; Kt and f(pH) are entered from the standard, never from memory; without Kt the rate is INCOMPLETE; not calibrated to your field.
Deterministic assembly; Kt and f(pH) are yours from the standard; not calibrated to your field.
Enter the CO₂ partial pressure (or mole fraction + total pressure) and the NORSOK Kt for your temperature to assemble the M-506 corrosion-rate estimate.
01
Cycles balanceiThe only thing here that measures a RATE. Chloride and conductivity concentrate but never precipitate; calcium does. So cycles measured on calcium reads LOW when calcium is leaving the water, and the gap is the deposition rate. If calcium and alkalinity fall by the same fraction, that is CaCO₃ stoichiometry — the pattern names the scale, not just its presence.
Steps 01 and 02 are theory. This is what your tower is actually doing.
Makeup is the analysis above. Enter the same ions measured in the tower.
Needs a tower analysis. You need at least one tracer — chloride or conductivity — plus the ion you suspect. Without a tracer there is no way to know the true cycle count, and the answer would be a guess. No tower data to hand? Load the worked example.
02
Program costiThe operator’s question is economic. Acid, antiscalant, or fewer cycles — priced per day. Water and acid are arithmetic. The antiscalant line assumes a 5 ppm dose, which this product cannot justify — thermodynamics does not set a dose. Its ranking is indicative until dose-response data exists.
So what do you do — and what does each option cost per day?
Target and current cycles carry forward from steps 01 and 03 once you run them.
Run it to price acid against antiscalant against simply cycling lower.
05
Correlation · identify the depositiThree instruments, one tower, and they share no inputs. Thermodynamics ranks the phases by driving force — it says what could form. The ion ledger from step 03 says which ions are leaving, from your logbook. The phosphorus ledger says whether phosphorus is involved and whether your oxidiser is the reason. Joined, they identify the deposit stoichiometrically: calcium and alkalinity leaving 1:1 is a carbonate; calcium and phosphate at 5:3 is apatite; magnesium and silica at 4:6 is sepiolite. The ratios are the mineral formulae — nothing is fitted. Today you identify a deposit by sending a scraping to a lab and waiting weeks for XRD.
What is the scale actually made of — and do two independent methods agree?
Uses the tower analysis from 03 Cycles balance — enter it there. The phosphorus and halogen figures below are optional: supply what you have and the correlation uses what it can.
Makeup water and rate come from the case bar above.
Run 03 Cycles balance first — the ion ledger is the input to this.
03
Binding constraint · what actually limits cyclesiThe cycle ceiling is rarely the scale you watch. Step 01 finds the chemistry ceiling. But as the tower concentrates, three kinds of limit tighten at once: scale saturation, biocide holding time (residence time — a microbiological risk factor for your assessment, not a Legionella prediction), and your discharge consent (blowdown concentration against your permit). The first to bind sets the real ceiling — and it is often the discharge consent, or apatite created by your own corrosion inhibitor, not carbonate. This couples treatment to environmental compliance in one envelope; scale-prediction tools model these separately, so the true ceiling stays hidden. Discharge consents are entered by you from your permit — never supplied from memory.
Five constraints tighten as you concentrate. Which one stops you first?
Uses the makeup water above. Enter your dosed phosphate and your discharge consents.
Makeup water comes from the case bar above.
Run it to see all five constraints tighten and which one binds first.
04
Segment chemistryiFor sour, acid-drainage and oxygenated waters. When the water carries dissolved sulfide (O&G sour), low-pH metals (mining acid drainage), or dissolved oxygen (boilers), the engine runs the WATEQ4F thermodynamic database to evaluate the phases those segments care about — barite and iron-sulfide scaling, aluminium-hydroxide and jarosite, and oxygen redox. Phases that are thermodynamically favoured but kinetically too slow to form now are flagged as watch-indicators, never as present risk. The saturation thermodynamics are validated against the database; per-site dose calibration is not yet earned.
Sour, acid-drainage, or oxygenated water? The segment-specific scales appear here.
Uses the makeup water above, including any segment species (sulfide, O₂, Al, Mn) you entered.
Only active when the water carries redox species.
For sour / acid-drainage / oxygenated waters, run this to see the segment-specific phases. A normal cooling water has none — that is expected.
05
Net acidity · does this water self-neutralise?iThe entry point for acid mine drainage. Net acidity — not pH — decides whether a water self-neutralises or needs added alkalinity, because a circumneutral water can carry high dissolved metal (latent acidity) that appears as the metals hydrolyse. This is the deterministic Kirby-Cravotta / Hedin calculated acidity: proton acidity from pH plus the metal load (Fe, Mn, Al by charge), minus your measured alkalinity. Net acidic → will not self-neutralise, treat; net alkaline → self-neutralises. If you give total iron it is treated as ferrous — a labelled default; split it into Fe(II)/Fe(III) for the exact value (ferric carries more acidity). The lime figure is the stoichiometric CaO demand; real plant demand is higher by a plant-specific factor that is not fabricated here. Recovery, sludge and purity are not computed — this sizes the chemistry, not the plant.
For acid-drainage water. Enter the metal analysis; net acidity decides treat-or-not.
Uses the makeup water above for pH and metals; set the measured alkalinity here.
pH comes from the makeup water above.
For acid-drainage water, run this to see whether it self-neutralises and the acidity breakdown.
03
Operating setpoints · from this water, not a tableiFixed universal setpoint tables are wrong. The safe pH ceiling is not a constant — it is set by this water's scaling limit at your operating cycles. A generic “pH up to 8.8” will scale a hard, alkaline water and needlessly restrict a soft one. Here the pH ceiling is bisected against the real engine, the conductivity ceiling is the cycle limit naming the limiting salt, and the ORP target is residual-driven (it moves with pH). Where a value genuinely is a metallurgy default — the corrosion-side pH floor — it is labelled a default, not dressed up as computed. Every setpoint says how it was derived.
The setpoints this water can actually hold — each with its basis.
Uses the makeup water above. Set the metallurgy and the chlorine residual you hold.
Makeup water comes from the case bar above.
Run it to see the water-specific setpoint table, each value with its basis.
05
Phosphate-pH control · coordinated / congruentiThe daily control decision for a drum boiler on phosphate treatment. The Na:PO₄ molar ratio sets the pH the phosphate produces and the corrosion risk: above 3.0 there is free caustic (gouging risk); 2.2–2.8 is the congruent in-control band; below 2.2 is acid-phosphate (corrosion / maricite). This is the coordinated-phosphate diagram computed, not read off a chart — the deterministic phosphate acid-base equilibria (pK₁/pK₂/pK₃ at 25 °C, labelled). It backs out your effective ratio from measured phosphate and pH, and gives the target pH to sit at the congruent centre. The pressure-specific phosphate band is NOT supplied from memory — those limits come from your plant's chemistry program / current EPRI guidance; only the ratio, regime, target pH and the hideout principle are computed. Give a second load reading and it flags the hideout signature (phosphate down + pH up at load).
For boiler water. Enter phosphate, pH and drum pressure; the Na:PO₄ ratio names the regime.
pH is the cooled-sample (25 °C) boiler-water value. Phosphate is as PO₄.
The pressure-specific phosphate band is deferred to your plant's chemistry program.
For boiler water, run this to see the Na:PO₄ ratio, the control regime and the target pH.
14
Boiler cycle twin · blowdown & limitsiThe boiler analogue of the cooling dynamic twin. A drum boiler concentrates dissolved solids just like a tower — feedwater in, steam out nearly pure, blowdown the only path out — so this reuses the cooling twin's validated implicit-Euler integrator, but watches boiler chemistry: silica, TDS/conductivity and alkalinity against the unit's boiler-water limits. Deterministic (ships): maximum cycles of concentration = min(limit÷feedwater) over those species (a ratio), and the boiler-water transient — cut blowdown to save energy and see how fast each species climbs to its limit and when it crosses. COC is an OUTPUT (feedwater÷blowdown), never assumed. Gated (honest gap): the phosphate-hideout, deposition and embrittlement RATES are not predicted — the hideout signature is routed to the validated boiler phosphate read, and silica carryover into steam is emitted only against an entered distribution ratio. Limits are entered (your ASME/EPRI/OEM spec for the pressure); the defaults are illustrative and loudly labelled.
For boilers. Enter the feedwater and flows to see the cycle limit and blowdown transient; the hideout and deposition rates stay gated.
Cycle limit and the concentration transient are deterministic. The rates — hideout, deposition, embrittlement — are gaps, never invented.
Feedwater (mg/L)
Boiler operation
Boiler-water limits default to illustrative low-pressure values — enter your unit's ASME/EPRI/OEM limits for the operating pressure to forecast against the right numbers.
Cycle limit and transient are exact; the hideout and deposition rates are gated.
For a boiler, enter the feedwater and flows to see the cycle limit and blowdown transient.
15
Boiler control regime · mode, deadband & failsafeiThe boiler analogue of the cooling control-regime tool. A boiler HAS real closed-loop control — so this recommends the control mode, deadband floor and failsafe for each chemical-feed loop: blowdown (conductivity/cycles), oxygen scavenger (residual O₂), and phosphate/pH. It reuses the same mode-selection kernel as the cooling tool (dead-time÷lag rule + actuator binding + deadband floor). The blowdown gain d(cycles)÷d(blowdown) is computed from the same mass balance as the cycle twin; the phosphate target is routed through the validated phosphate read. Failsafes are reasoned per loop: blowdown fails open (protect the turbine from carryover), scavenger and phosphate fail last-good (protect the metal / don't chase hideout). The scavenger dose target stays uncalibrated (mode only, never a dose number), and every limit is entered. Hard boundary: the SIL-rated life-safety interlocks (drum level, over-pressure) are NOT modelled — this is chemistry control, not the safety system. Boiler-only.
For boilers. Recommends the control mode, deadband and failsafe for the blowdown, scavenger and phosphate loops; the SIL interlocks are out of scope.
Mode and failsafe are reasoned from physics and the loop hazard. The scavenger dose target and the SIL interlocks are gaps — never invented.
Blowdown gain (from the mass balance)
Phosphate loop (routed to the validated read)
Mode and failsafe are exact; the dose target and SIL interlocks are out of scope.
For a boiler, choose a loop and enter the loop dynamics to see the recommended control regime.
06
Oxygen-scavenger dose · feedwater deaeration chemistryiThe chemical dose that removes residual dissolved oxygen from boiler feedwater. Dissolved O₂ pits and corrodes; a scavenger reacts it away. The dose is set by reaction stoichiometry with O₂ — exact published chemistry: sulfite 7.88 ppm/ppm O₂ (2 Na₂SO₃+O₂), hydrazine 1.00 (N₂H₄+O₂), carbohydrazide 1.41; DEHA is a labelled published ~1.24 (its oxidation is not a clean 1:1). Any target residual and excess are yours and are added to the stoichiometric demand — the specific residual band by pressure comes from your plant's program, not from memory. It does not pick a scavenger — that is a program call; it doses the one you choose and states the trade-offs. Hydrazine is flagged as a suspected carcinogen / controlled substance every time.
For boiler feedwater. Enter the dissolved O₂ and pick a scavenger; the dose follows the stoichiometry.
Dissolved O₂ is the feedwater residual after the deaerator. Residual and excess are your programme's, not ours.
It computes the dose for your chosen scavenger; it does not pick one.
For boiler feedwater, enter the dissolved O₂ and a scavenger to see the dose and its basis.
05
Condensate amine / AVTiThe carbonic-acid corrosion of the condensate return, and the neutralizing-amine demand. CO₂ carried over with the steam dissolves in the condensate as carbonic acid, drops its pH and corrodes the carbon-steel return. Deterministic (ships): the acidified condensate pH from the carbonic-acid equilibrium ([H⁺] = (−Ka₁+√(Ka₁²+4·Ka₁·C))/2), and the neutralizing base demand to a target condensate pH = [HCO₃⁻]+2[CO₃=]+[OH⁻]−[H⁺] — closed-form carbonate arithmetic, ~1 eq of base per mol free CO₂ to the bicarbonate endpoint. The honesty seam: the carbonate constants are the standard 25 °C reference values, LABELLED; the CO₂ carryover from feedwater alkalinity uses the published 0.79 factor as a LABELLED theoretical upper bound (actual carryover entered); the amine equivalent weight is a labelled library value; and the amine distribution ratio is ENTERED, never from memory — without it the condensate amine still computes but the feedwater dose is INCOMPLETE, never fabricated. The tool does not choose the amine, model the condensation profile, or claim a corrosion rate. Boiler-only.
Compute the condensate acid load and the neutralizing base demand deterministically — the amine and its distribution ratio are yours, and the feedwater dose is honestly gated without them.
Carbonate arithmetic is deterministic; the 0.79 carryover factor and amine EW are labelled; the distribution ratio is entered, never assumed; no DR → the feedwater dose is INCOMPLETE.
Deterministic carbonate arithmetic; the distribution ratio is yours; the feedwater dose is gated without it.
Enter the condensate CO₂ (or the feedwater alkalinity) and a target pH to see the condensate acid load and the neutralizing base demand.
07
RO array balance · recovery, concentrate & fluxiThe system-level design read for a reverse-osmosis array. From the feed, the target recovery and the membrane area, the system mass balance is exact: concentration factor CF = (1−R(1−r))/(1−R), concentrate and permeate TDS, permeate/concentrate flow, and average flux. At 75% recovery CF ≈ 4 — the rule of thumb, computed. The per-stage split is a labelled uniform-flux approximation. The element-by-element profile (lead-element over-flux, per-element dP) is NOT computed — that needs the full element-hydraulic model (the Wave-3 build) and is returned as an honest gap. Salt rejection, element area and β are labelled defaults. It reports the concentrate concentration, not whether it scales — run the concentrate through Scale & Corrosion for that. A CIP regime follows deterministically from the foulant; the specific doses/temps are membrane-specific and deferred.
For reverse osmosis. Enter feed, recovery and array size; the concentrate and flux follow the mass balance.
The system balance is exact; the per-stage split is a labelled approximation; the per-element profile is a stated gap.
This gives the concentrate concentration, not the saturation — check that in Scale & Corrosion.
For an RO system, enter the feed and recovery to see the concentrate, flux and CIP regime.
08
RO element-by-element profile · lead over-flux, tail under-fluxiResolves a pressure vessel SPATIALLY — per-element flux, recovery, TDS and pressure, so the lead-element over-flux and tail-element under-flux become visible instead of averaged away (the lead element is where fouling/scaling start; the tail is where brine peaks). A first-principles solution-diffusion marcher (FilmTec form): Jw = A·NDP, Js = B·ΔC, pf = exp(0.7·Y), ΔP = 0.01·q1.7. A and B are back-calculated from the element's public datasheet (permeate flow, rejection, test conditions) — a clean, new-membrane value, labelled, NOT fitted to a plant and NOT the aged state; the fouling factor is your assumption. Accuracy: ~5–10% vs a manufacturer projection, ~10–20% vs a real aged plant. Validated against the Johnson & Busch (2010) published seven-element case.
For reverse osmosis. One pressure vessel: enter the feed, element count and target recovery, and either A/B or a datasheet spec.
A/B are clean-new-membrane datasheet values, labelled — not the aged/fouled state. The profile shape and recovery are the reliable read.
To back-calculate A/B, clear A and B and fill the datasheet nominal: permeate m³/d, rejection %, test TDS & pressure.
The profile shape and recovery are reliable; the absolute pressure carries the stated ~10–15% uncertainty.
For an RO vessel, enter the feed, elements and recovery to see the per-element flux profile.
13
RO fouling twin · CIP-cycle forecastiThe RO analogue of the cooling dynamic twin. It answers when to clean, not how fast the membrane will keep fouling from the feed chemistry — that mechanistic rate is a gap the platform is honest about. Deterministic (ships): each operating point is normalised against the reference by ASTM D4516 (routed through the platform's own normaliser), giving normalised permeate flow (NPF), salt passage (NSP) and pressure drop (NPD); a least-squares trend on each — with an R² noise guard, so noise is never called a decline — is projected to its entered cleaning threshold to give the CIP-due day. The soonest indicator sets the schedule; the moving indicator names the foulant class (the D4516 verdict). Gated (honest gap): the mechanistic fouling rate, remaining membrane life, and whether a clean will recover performance are NOT predicted — they need a membrane autopsy or fleet data, and are never fabricated. A MEMBRANE_DEGRADATION signature is flagged as cleaning will not restore it.
For RO trains. Enter a reference reading and a time series of operating points to project the cleaning schedule; the fouling rate and membrane life stay gated.
CIP-due is a projection of the OBSERVED normalised trend. The fouling rate, membrane life and clean recovery are gaps — the tool never invents them.
Reference reading (clean baseline)
Time series (points)
One JSON object per point, with elapsed days t and the same reading fields. Paste the operating log:
Trend projection is deterministic; the fouling rate and membrane life are gated.
For an RO train, enter a reference reading and a time series to project the CIP-due schedule.
16
RO control regime · mode, deadband & failsafeiThe RO analogue of the cooling / boiler control-regime tool. An RO train HAS real closed-loop control — so this recommends the control mode, deadband floor and failsafe for each loop: antiscalant (flow-paced), acid/pH (LSI), dechlorination (residual oxidant/ORP), and CIP trigger. It reuses the same mode-selection kernel as the cooling tool (dead-time÷lag rule + actuator binding + deadband floor). Dechlorination is the inverted oxidiser: free chlorine destroys the membrane fast and irreversibly, so — unlike the cooling oxidiser (no safe default) — this loop HAS a safe default: keep removing oxidant, protect the membrane. Antiscalant is flow-paced feed-forward with the dose target uncalibrated (mode only). The CIP trigger routes through the RO fouling twin (crosses the entered cleaning threshold); if the signal is lost it falls back to the time-based schedule. Every limit is entered. Hard boundary: the high-pressure safety interlocks are NOT modelled — chemistry control, not the safety system. RO-only.
For RO trains. Recommends the control mode, deadband and failsafe for the antiscalant, acid, dechlor and CIP loops; the high-pressure safety interlocks are out of scope.
Mode and failsafe are reasoned from physics and the loop hazard. The antiscalant dose target and the high-pressure interlocks are gaps — never invented.
Mode and failsafe are exact; the dose target and high-pressure interlocks are out of scope.
For an RO train, choose a loop and enter the loop dynamics to see the recommended control regime.
09
Passive AMD treatment sizing · train selection & areasiRecommends a passive treatment TRAIN and SIZES each unit from published design criteria. Selection uses the Hedin/Nairn/Kleinmann (1994) decision tree: net-alkaline → aeration + settling + aerobic wetland; net-acidic with DO/Fe(III)/Al all < 1 mg/L → anoxic limestone drain (ALD); otherwise → RAPS / vertical-flow pond. Sizing from published loading rates: aerobic wetland Fe 10/20, Mn 1/2 g/m²/d; RAPS acidity 25–35 g/m²/d; ALD limestone = the larger of a 15 h retention hold and life-neutralisation; settling 24–48 h. Rates are empirical medians with wide variance — the compliance basis is ~2× conservative. COST is not computed: unit prices are region-specific and uncalibrated by design — it names the cost-driver structure, not prices. It sizes; it does not predict effluent quality.
For acid mine drainage. Enter the flow and net acidity (from Diagnose) plus DO, Fe, Al, Mn; it selects and sizes the train.
Net acidity comes from the AMD net-acidity tool in Diagnose. Loading rates are published medians, labelled — not guarantees.
It sizes the train from published criteria; cost is out of scope (uncalibrated by design).
For AMD, enter the flow and net acidity to select and size a passive treatment train.
13
Limestone depletion clock · remaining bed lifeiThe dynamic companion to passive sizing. A passive AMD bed has no control loop — it just slowly depletes as the limestone neutralises the acidity load. This tells you when it needs replacement. Deterministic (ships): remaining life = installed limestone ÷ consumption, where consumption = acidity load ÷ (purity × efficiency) via the same neutralisation stoichiometry as the sizing tool (1 g CaCO₃ per 1 g acidity-as-CaCO₃). This is the stoichiometric upper bound — the real life is at or below it. Gated (honest gap): the armoring rate (Fe/Al hydroxide coating shortens the real life) and end-of-life effluent quality are not predicted — supply an entered armoring de-rating factor from field data to shorten the estimate; the tool never fabricates one. Net-alkaline water reports no depletion. AMD-only.
For AMD. Enter the flow, net acidity and the installed limestone mass to see remaining bed life; the armoring rate stays gated.
The stoichiometric clock is deterministic and an upper bound. The armoring rate that shortens it is a gap — entered only, never invented.
Optional armoring de-rate (0–1) is applied only if you enter it from field/autopsy data — it is never assumed.
The clock is exact; the armoring rate is gated.
For AMD, enter the flow, net acidity and installed limestone mass to see remaining bed life.
14
Sludge generation · dry mass & disposal volumeiHow much sludge the treatment makes — the disposal cost driver. Sludge handling is a major, often-overlooked annual cost, and disposal is billed by volume. Deterministic (ships): the dry-solids mass — each dissolved metal precipitates as its hydroxide by a fixed molar-mass ratio (Fe(OH)₃, Mn(OH)₂, Al(OH)₃), 100% at the design pH endpoint (the AMDTreat convention). Iron is taken as ferric hydroxide Fe(OH)₃ (aerated active-treatment basis, labelled) — a passive/anoxic flag warns this over-states iron. Not fabricated: the wet volume needs the site-specific percent-solids of the thickened sludge (and, optionally, its density) — supply it and the volume is computed; leave it blank and only the dry mass is returned, the volume an honest gap. Gypsum / calcite / excess-lime solids are not estimated (they need the reagent dose and are saturation-dependent) — enter them if you have them. AMD-only.
For AMD. Enter the flow and the dissolved Fe/Mn/Al to see the deterministic dry-solids mass; add the sludge percent-solids to get the disposal volume.
Dry mass is deterministic stoichiometry. The wet volume needs your percent-solids — entered only, never invented.
Volume is computed only if you enter the sludge percent-solids — it is never assumed.
Dry mass is exact; the disposal volume needs your entered percent-solids.
For AMD, enter the flow and dissolved Fe/Mn/Al to see the dry-solids mass; add percent-solids for disposal volume.
10
Scale-inhibitor squeeze design · envelope & lifetimeiDesigns a scale-inhibitor squeeze in three layers, each with its own honesty status. (1) Scaling driver — which scale the squeeze protects against, ROUTED through the platform's own saturation + incompatible-mixing engine (supply formation water + seawater). (2) Reservoir geometry — deterministic: radial penetration r = √(rw² + V/(π·h·φ·S)), treated pore volume, inhibitor mass placed. (3) Squeeze lifetime — the frontal-advance model Vlife = 1 + ρ(1−φ)/φ·(k/n)·MIC(1/n−1). This is deterministic ONLY given a lab-measured isotherm (Freundlich k, n) and MIC from a static-adsorption bottle test + coreflood. Those are rock-and-brine-specific and cannot be predicted from water chemistry — without them the tool returns an explicit lab-data-required gap, never a fabricated isotherm or lifetime.
For oilfield produced water. Enter the reservoir geometry and treatment; add a lab isotherm + MIC to get lifetime.
The geometry and scale risk are deterministic. Lifetime needs a lab isotherm + MIC — the tool will not invent them.
Lifetime inputs — from a LAB static-adsorption test + coreflood only (Freundlich Γ = k·C(1/n), Γ in mg/g). Leave blank for the honest gap.
Geometry + scale risk are deterministic; lifetime is deterministic only with a lab isotherm + MIC.
For an oilfield squeeze, enter the reservoir geometry and treatment to see the design envelope.
17
Sour progression twin · scaling onset on breakthroughiThe sour analogue of the dynamic twin — built around the one sour progression that is deterministic: scaling onset as injection water breaks through. As sulfate-rich injection water (seawater) mixes into Ba/Sr-bearing formation water, the blend becomes supersaturated in barite/celestite that neither water forms alone — the classic produced-water problem. Deterministic (ships): the scaling onset is routed through the validated mixing scan (the platform's own saturation engine) — the smallest seawater fraction at which each emergent scale crosses SI > 0, the binding scale named, and (against an entered breakthrough curve) the field-life time it is reached. Gated (honest gap): the souring rate (biogenic H₂S), scale deposition rate and corrosion rate are not predicted (reservoir-/lab-specific) — an entered souring trajectory is walked as-is, never generated. Sour-only.
For sour (produced-water) systems. Enter the formation and injection waters to see when scaling begins as injection water breaks through; the souring and corrosion rates stay gated.
The scaling onset is deterministic mixing thermodynamics (engine-routed). The souring and corrosion rates are gaps — entered only, never invented.
Formation water (mg/L) — the Ba/Sr-bearing water
Injection water (mg/L) — the sulfate-rich water (e.g. seawater)
The scaling onset is exact; the souring and corrosion rates are gated.
For a sour system, enter the formation and injection waters to see when scaling begins as injection water breaks through.
11
Control regime recommendation · mode, deadband & failsafeiPer cooling-tower loop, recommends a control MODE + deadband + alarm/failsafe. The process gain is engine-computed (the oxidiser gain dHOCl%/dpH from HOCl speciation); the actuator class (relay vs analog) gates which modes are physically possible; the dead-time/lag ratio selects within it (<0.1 on/off, 0.1–0.3 PID, 0.3–1 pseudo-PID/band, >1 band/timer — tight PID oscillates when dead-time-dominated). Dead time, actuator min-on-time and noise are entered; alarm/failsafe limits are the entered, edition-stamped surface — it computes WHERE a variable crosses them, never the limit itself. Failsafe is reasoned per loop: acid & non-ox FAIL-CLOSED, inhibitor FAIL-LAST-GOOD, and the oxidiser has NO safe default (failing off risks Legionella, failing on risks over-oxidation + consent) so it is never auto-set — the human sets it. Recommends; the human commits.
For cooling towers. Pick a loop and actuator, enter dead time / lag / noise; it recommends the mode and failsafe.
Design-time companion to the setpoint window and the runtime control decision. The oxidiser failsafe is never auto-set.
Mode & gain are computed; limits are entered; the oxidiser failsafe crosses the human seam.
For a cooling tower, pick a loop and actuator to see the recommended control mode and failsafe.
12
Sensor drift & service scheduling · confound breaker & time-to-limitiTells sensor DRIFT from real SERVICE NEED — and never confuses them. A pH probe that ages and reads low looks exactly like rising acid demand; dose acid to “correct” it and you have driven the water acidic on a lying probe. The confound breaker: a real process change moves MULTIPLE correlated streams together (pH and ORP and calcite SI); instrument drift moves ONE. A stream that departs from what its partners predict is a sensor fault — recalibrate, do not act; a stream that moves with them is real — act. Scheduling by time-to-limit, not calendar: time_to_L = (L − now)/rate, where the limit L is entered with its edition, never from memory. The water clock (soonest limit) and instrument clock (soonest recal) merge into one visit. Full multi-point drift series (with the R² noise guard) ingest via the service-visit API; low-confidence readings SHORTEN, never lengthen, the interval.
For cooling towers. Enter the recent per-stream trends to break the confound, and a variable + entered limit to schedule.
The confound breaker uses the tower's own coupled physics as the drift detector — no extra hardware. Limits are entered, never from memory.
Confound breaker — recent per-stream trend (slope per day) and the noise floor below which a move is not a move:
Time-to-limit — a controlled variable heading toward an ENTERED limit:
A lone-moving stream is a sensor fault; a co-moving set is a real change. Limits are entered.
For a cooling tower, enter the recent per-stream trends and a variable to break the confound and schedule.
12
Dynamic twin · driving-force forecastiThe honest cooling-tower digital twin. Sim A (ships now) forward-integrates the transport mass balance — implicit backward Euler, unconditionally stable, tested to hit the analytic steady state exactly — with the reaction terms at zero, and recomputes SI / HOCl% / HTI exactly from the engine at each state. It answers when the water crosses into supersaturation if you push cycles, without claiming a deposit mass. COC is an OUTPUT, integrated and reported (it lands below makeup÷blowdown because windage carries concentrate out) — never assumed. Sim B (rate: kg/day) is gated: the scenario emits a reaction rate ONLY where replay has calibrated that coefficient by closing the mass balance on the plant's own history (rate = residual, not a curve fit). Until then the rate slot is UNCALIBRATED, never fabricated — the twin does not hide a guessed rate inside a differential equation. Corrosion is learned from the probe; Legionella is never predicted; a beneficial forecast does not authorise the setpoint that reaches it.
For cooling towers. Enter the water and tower flows to forecast the driving force; the kg/day rate stays gated until replay calibrates it.
Sim A driving-force is exact and always available. The Sim B rate is gated until replay calibrates the coefficient — the seam is visible, never faked.
Water comes from the shared analysis above. The Sim B rate slot stays UNCALIBRATED unless a calibrated coefficient is supplied by replay.
Driving-force forecast is exact; the reaction rate is gated behind replay calibration.
For a cooling tower, enter the water and tower flows to forecast the driving-force trajectory.
04
Independent audit · the vendor-neutral second opinioniA second opinion that doesn't sell you chemicals. Given your current operating point — the pH and cycles you actually run — this checks where you sit versus the water-specific setpoints and the binding constraint, names any material finding, and (if you supply economics) the lowest-cost route to it. Every finding shows its basis. It never recommends a point-value dose — dose-response is uncalibrated, so it bounds, it doesn't prescribe — and it states plainly what it cannot say without your field data. Carries no chemical supply interest.
Is your current program right? An independent read of your operating point.
Uses the makeup water above. Enter what you run today.
Makeup water comes from the case bar above.
Run it for an independent read of where your operating point sits — with every finding's basis.
01
Unified twin · one pass, advisory or simulator-autonomousiThe whole pass in one place. Identify → recommend → control → observe, with every output a single Recommendation carrying what, the proposal, why, its provenance, its confidence, and its safety class. Two rules you can see here: an output with no provenance does not render, and a human-only safety item (oxidant / biocide) is never automatable. Autonomous mode is for validating the control logic against a simulator or test rig — on a plant target it is refused and downgraded to advisory. Human-in-the-loop is the default and the only mode that reaches real hardware.
Run the control logic as one traced pass. Autonomous is simulator/test only.
Uses the makeup water above. Choose the target and the mode; add live sensors to include the observe step.
Makeup water comes from the case bar above.
Run it to see the Recommendation list — each with its safety class and confidence.
02
Control decision · what would actuate, and what may notiThe safety gate, made visible. Ask for a mode and a target, and this shows what the platform would actually do — loop by loop, with the safety class on each action. Two rules are structural, not preferences: autonomous is refused on a plant and silently downgraded to advisory, and an action classed human-only-safety (the oxidiser, the biocide) is never actuated no matter what mode you ask for. If you requested autonomous and got advisory, that is the gate working.
Ask for a mode; see what the gate grants and what it refuses.
Uses the makeup water above. Sensor values are optional — leave blank to run on water alone.
Makeup water comes from the case bar above.
Run it to see which loops would actuate, which are advisory, and which are refused outright.
03
Closed-loop sandbox · prove the loop before it touches anythingiLoop validation on a simulator, never a plant. Runs the control loop against simplified tower dynamics to show whether it converges toward the setpoints or oscillates. These dynamics are deliberately simplified and are NOT a calibrated plant model — the sandbox proves the loop's logic and stability, not what your tower will do. The oxidiser is structurally absent from the loop: it cannot be actuated here even in simulation.
Does the loop converge, or hunt? Run it on the simulator and watch.
Uses the makeup water above.
Makeup water comes from the case bar above.
Run it to see the trajectory converge toward the setpoints — or be refused on a plant.
01
Calibration · how close is this coefficient to trustworthyiThis is where the moat is built, and where it is honestly gated. Feed service-visit points and the learner classifies each interval (steady / drift / step), excludes dose-change steps from the fit and flags them for human confirmation, then fits the coefficient with a confidence interval. The status is the honest part: a coefficient reaches CALIBRATED only on FIELD or LAB provenance with a tight interval. Synthetic data can never calibrate anything — paste synthetic points and the status stays SYNTHETIC no matter how tight the interval gets.
Feed visit data; watch the confidence interval close — and see what still blocks CALIBRATED.
Paste service-visit points as JSON, or load a synthetic demo series to see the mechanism.
Feed points to see the classification, the fitted coefficient, its interval — and its honest status.
02
Field-data capture · distance to CALIBRATEDiThe moat motion. The step above fits a coefficient from whatever you paste; this one persists captured service visits and accumulates the posterior across every visit, then shows, per coefficient, how far it is from CALIBRATED. The honesty is in the distance: a coefficient with only synthetic points is not “almost there” — it is BLOCKED on field data, because no quantity of synthetic reaches CALIBRATED. One with field points but a wide interval shows ~N more field points at the current scatter. This capture is untrusted: any point claiming FIELD is clamped to SYNTHETIC — only a trusted field integration fills the moat, never a pasted payload. That is exactly why the demo below stays BLOCKED however many points you add.
Capture visits, then watch each coefficient's distance to CALIBRATED — honest about the kind of data still missing, not just the amount.
Capture service-visit points (persisted, accumulated across visits). Provenance is clamped to SYNTHETIC on this untrusted path — the tracker will show BLOCKED until a trusted integration supplies field data.
Capture service-visit points, then refresh to see each coefficient's honest distance to CALIBRATED.
18
ROI / eROI value ledgeriThe business case, without fabricating a number. Turns a physical operating improvement into water / energy / carbon / labour / dollar terms for a plant manager. The physical quantities it derives are textbook, deterministic water balances — the cooling water balance from a cycles change (blowdown = evaporation÷(cycles−1)), RO intake water from a recovery change (feed = permeate÷recovery) and boiler makeup water from a cycles change; every other quantity is entered and flagged. The honesty seam: every price and carbon/energy factor is ENTERED and source-stamped, never supplied from memory (treated like a regulated limit) — a missing price makes its line INCOMPLETE, never a fabricated default. Each line is quantity × price, shown. Physical and monetary confidence are reported apart: a deterministic water quantity does not make its dollar value validated — the money is HEURISTIC, riding on your entered prices. Prices may be entered as bands. Payback / ROI% appear only if a capital cost is entered. All segments.
Translate a physical improvement into the numbers a plant manager buys on. Enter a cooling cycles change (derived water saving) and/or your own physical deltas, plus your source-stamped prices.
The cooling water saving is deterministic; every price and factor is entered and source-stamped. Nothing is supplied from memory, and a missing price is flagged, never guessed.
Physical improvement — cooling water (derived) and/or entered deltas
Physical improvement — RO recovery and/or boiler cycles (also derived, deterministic)
Prices & factors — ENTERED, source-stamped (a blank price leaves its line incomplete)
The water saving is exact; every dollar figure is heuristic, riding on your entered prices.
Enter a cooling cycles change and/or your own physical deltas, plus your source-stamped prices, to see the transparent value ledger.
19
Compliance reportiThe audit artifact, honest by construction. Builds an audit-ready value-vs-limit record — ASHRAE 188 register, NPDES discharge, ASME/EPRI cycle-chemistry, or mine-discharge. The honesty seam: every limit is ENTERED and edition-stamped, never supplied from memory (the platform's standing position on discharge consents and ASME limits). A parameter with an entered limit is assessed transparently (value vs limit) → PASS/FAIL; a parameter without a limit is reported but NOT assessed — never a fabricated pass, and excluded from the overall verdict. Every value carries its provenance (engine / measured / entered). The report must name its standard and edition or it is incomplete. For ASHRAE 188 no Legionella CFU is predicted — the register documents the water-management program. It is a factual record, not a legal certification. All segments.
Assemble an audit-ready compliance record from your parameter values and your entered, edition-stamped limits. Nothing is assessed against a limit the tool invented.
Limits are entered and edition-stamped — never from memory. A parameter with no entered limit is reported but not assessed, never passed by default.
Report header
Parameters — value, provenance, and your ENTERED limit (blank limit = reported, not assessed)
Every limit is yours and edition-stamped; a blank limit is reported, not passed by default.
Name the standard and edition, then enter each parameter with its value and your entered limit, to assemble the audit-ready record.
20
AMD lifecycle cost / NPViThe one segment with only free government tools. An AMDTreat-style whole-of-life cost for an acid-drainage treatment system — capital + annual O&M + recapitalization (media replacement), discounted to NPV. The honesty seam: physical quantities are routed from the validated AMD reads (net-acidity → reagent demand, passive sizing → limestone mass, sludge → disposal tonnes/volume, depletion clock → replacement interval) or entered, each tagged with its provenance — never fabricated. Unit costs are ENTERED and UNCALIBRATED (the platform has never calibrated an AMD cost coefficient and never supplies one from memory); a line with no unit cost is INCOMPLETE — listed, excluded from the total, never a fabricated default. The NPV is deterministic arithmetic given your entered discount rate and horizon. Physical vs monetary confidence are kept apart: the dollar total is a HEURISTIC planning estimate, not a bid. Give two scenarios for a passive-vs-active comparison. AMD only.
Build a whole-of-life cost for an AMD system from routed physical quantities and your entered, uncalibrated unit costs. Nothing is costed against a coefficient the tool invented.
Unit costs are yours and uncalibrated — never from memory. A line with no unit cost is listed but excluded, never fabricated. The dollar total is a planning estimate, not a bid.
Analysis basis
years
Scenario A — capital, annual O&M lines (quantity × your entered unit cost), recapitalization
years
Quantities routed or entered; costs yours and uncalibrated; missing cost = excluded, not fabricated.
Enter a horizon and at least one scenario (capital, O&M lines with your unit costs, any recapitalization) to build the whole-of-life cost.
21
ESG / water-stewardship disclosureiPhysics-grounded disclosure, not a typed-in guess. Assembles a framework-structured water disclosure for CDP Water, GRI 303, or ESRS E3. The honesty seam: the record names its framework + edition or it is INCOMPLETE; a datapoint the framework asks for that has no value is NOT reported — listed as a gap, excluded, never a fabricated value or zero; the withdrawal / discharge / consumption volumes (GRI 303-3/4/5) are DERIVED deterministically from the platform's own water balance (blowdown = evaporation/(cycles-1); withdrawal = consumption + discharge) and tagged engine — RO consumption is left an honest gap (it depends on downstream use); the water-stress classification is ENTERED and sourced, never derived from memory (it needs external basin data like WRI Aqueduct); any monetary valuation uses an entered, uncalibrated internal water price and is planning-only. It is a disclosure-PREPARATION record, not an assured disclosure (CSRD requires third-party assurance). Neutral — all segments.
Prepare a CDP / GRI 303 / ESRS E3 water disclosure whose water balance comes from the engine, whose gaps are shown as gaps, and whose water-stress and water price are yours and sourced — never invented.
The 303 water balance is derived from the engine; a datapoint with no value is shown as a gap, never fabricated; water-stress and water price are entered and sourced. A preparation record, not an assured disclosure.
Framework & site
Water balance — derived from the engine (GRI 303-3/4/5)
Water-stress context — entered & sourced (never derived)
Additional datapoints (optional) — a datapoint with no value is shown as a gap, never fabricated
Framework + edition named or INCOMPLETE; 303 balance from the engine; gaps shown as gaps; stress + price entered and sourced.
Name the framework and edition, add a water balance (cooling or RO) and your water-stress context, to assemble the framework-structured disclosure record.
22
RO cost of foulingiThe running cost fouling actually adds. Free membrane-design tools (WAVE, IMSDesign) stop at design; this is the operational OPEX cost of RO fouling, across four categories: accelerated element replacement, the energy penalty from the fouling pressure rise, extra CIP (cleaning), and downtime. The honesty seam: every category is the INCREMENTAL cost vs clean operation (the difference from a baseline), not a gross cost. The physical drivers (flux/flow decline, pressure-drop rise, CIP interval, membrane life) are routed from the D4516 fouling twin or entered, tagged with provenance — never fabricated. Unit costs are ENTERED and UNCALIBRATED (never from memory); a category with no unit cost, or no clean baseline, is INCOMPLETE — listed, excluded, never a fabricated default. Physical drivers and dollars are kept apart: the total is a planning estimate, not a bid. RO only.
Cost the OPEX that fouling adds — from the twin's drivers and your entered, uncalibrated costs. Each line is the increment over clean operation; nothing is costed against an invented baseline.
Drivers routed from the fouling twin; costs yours and uncalibrated; every line is the increment over clean operation; a line with no cost or no baseline is excluded, never fabricated.
Accelerated membrane replacement
years
years
Energy penalty — extra pump energy for the fouling pressure rise
bar
m³/h
h/yr
Extra CIP & downtime — incremental cleans vs baseline
h
Every line is the increment over clean operation; costs yours and uncalibrated; missing cost or baseline = excluded, not fabricated.
Enter at least one fouling cost category (element replacement, energy penalty, extra CIP, or downtime) with its clean baseline and your unit costs, to cost the OPEX fouling adds.
23
Boiler fuel savingsiThe classic boiler energy case, done honestly. Boiler blowdown carries hot treated water out of the drum, so cycling up (reducing blowdown) saves fuel. The physics that is routed: blowdown = steam/(cycles-1), so the reduction from cycling up is deterministic — the same balance the boiler cycle twin uses — and is routed from the twin or entered, never fabricated. The one value that is entered, not fabricated: the blowdown heat content above makeup (kJ/kg) is ENTERED from steam tables for your drum pressure — there is no steam-table read here, and it is never supplied from memory. Boiler efficiency and fuel heating value are entered physical values; the fuel price is ENTERED and UNCALIBRATED, so the dollar figure is planning-only. The saving is INCREMENTAL (baseline → improved cycles); a line short a required value is INCOMPLETE — excluded, never fabricated (the physical fuel saving stands without a price). Physical and monetary confidence are kept apart: the total is a planning estimate, not a bid. Boiler only.
Turn the twin's blowdown reduction into fuel and dollars — deterministic where the physics allows, entered where it must be, and never a fabricated steam-table number.
Blowdown reduction routed from the twin (blowdown = steam/(cycles-1)); heat content entered from steam tables, never from memory; fuel price uncalibrated; a line short a value is excluded, never fabricated.
Blowdown reduction — from cycling up (routed from the twin)
kg/h
kg/h
kg/h
h/yr
Heat & fuel — heat content entered from steam tables (never from memory)
kJ/kg
kJ/kg
$/kg
Reduction deterministic from the twin; heat content and fuel values entered; price uncalibrated; a line short a value is excluded, never fabricated.
Enter the blowdown reduction (steam + baseline/improved cycles, or blowdown flows directly), the running hours, and the blowdown heat content from your steam tables, to value the fuel a boiler saves by cycling up.
24
Production at riskiA dollar figure on a deferral — without pretending to predict it. In sour (O&G) service a souring or corrosion condition can force a choke-back or shut-in to stay inside a facility H2S-handling, metallurgy or HSE limit; the consequence is the production value at risk. The honesty seam — and it matters most here: this tool does NOT forecast the risk. The souring/corrosion rates that would predict whether or when a constraint binds are UNCALIBRATED in this platform, so the affected rate, at-risk fraction (choke-back or shut-in) and duration are ENTERED, never a fabricated trajectory. Any constraint check is a deterministic comparison of your entered indicator against your ENTERED limit (source-stamped, never from memory) — it flags whether the premise holds, not a souring prediction. Price is ENTERED and UNCALIBRATED (planning only); a missing quantity or price is INCOMPLETE — excluded, never fabricated (the physical volume at risk stands without a price). Physical and monetary confidence are kept apart: the value is a planning estimate, not a bid or a forecast. Sour only.
Quantify the production a sour condition puts at risk — from your entered scenario, not a souring forecast. No unit conversion is done; enter a rate and a price in matching units.
Rate, fraction and duration are yours (the souring/corrosion rate is uncalibrated, never forecast); the price is yours and uncalibrated; a missing quantity or price is excluded, not fabricated.
At-risk scenario
days
Price & optional constraint check
Not a forecast — it costs the scenario you enter; the limit is never from memory; missing quantity or price = excluded, not fabricated.
Enter the affected production rate, the at-risk fraction and the duration (and optionally a price and a constraint check) to quantify the production value a sour condition puts at risk.
Speciation water:
Microbial tools
Pick a tool above to see it — or show all.
01
Halogen speciationiOnly the undissociated acid is a strong biocide — HOCl is roughly 80× more active than the hypochlorite ion. So the active fraction is an acid-base equilibrium, and at tower pH it decides the whole programme. HOCl pKa is temperature-corrected from Morris (1966); HOBr uses 8.70 at 25 °C with no temperature correction, because its T-dependence is not as well established and inventing one would be worse than saying so.
How much of your halogen is actually the active acid?
The water from your My Water card above — or a pH/temp override for speciation.
Run it to see how much of your chlorine and bromine is the active acid at your pH.
02
Holding time indexiHow long a slug survives, by dilution alone. Standard cooling-water practice and pure arithmetic from numbers Engine 1 already carries: blowdown = evaporation/(cycles−1) − windage. This is a CEILING on contact time, never the contact time — an oxidiser is also consumed by demand, sunlight and your own inhibitors, and dies faster. A non-oxidiser is not consumed by demand, so dilution is close to its whole loss path and HTI is close to real for it.
Your cycles decide how long a slug lasts — and nothing in the biocide programme changed.
Run it to see how long a slug survives at your cycles.
03
Halogen demand & decayiHolding time is dilution only, and on a fouled tower dilution is the slowest loss path by far. With measured constants the half-life can be under two hours against a holding time of a hundred — so a dilution-only curve overstates the residual by orders of magnitude, in the direction that says the biocide is still there when it is gone. Demand and bulk decay come from Standard Methods 2350 (Oxidant Demand/Requirement) — a jar series on this water, an afternoon’s bench work. We refuse to predict without them rather than substitute a plausible default.
What is actually left — once demand, your own inhibitors, and dilution have all taken their share.
Run step 02 first, then enter your 2350 constants.
04
Dose for residualiThe inverse of step 03: C₀ = D + C_target · exp(k·t). This is a dose recommendation, and it is defensible for a precise reason — the target is yours, from your water management programme or HSG274, never from us; and demand and decay are measured, not guessed. The forward and inverse models are pinned to round-trip against each other in the test suite. Dose-for-RESIDUAL only. Never dose-for-kill: that needs an efficacy constant, and none exists for biofilm organisms.
What dose holds your documented control limit — and how much of it is wasted on demand?
Needs step 02 and the 2350 constants from step 03.
05
Bio-dispersant slug windowiA bio-dispersant has no kill claim — it is a penetrant that exposes biofilm so the biocide can reach it, with no concentration-versus-kill relationship. But the dosing is exact arithmetic, and it is the operational instruction nobody computes: blowdown dilutes the slug, so holding a concentration for a contact time means suspending blowdown, and for how long is a number. Evaporation is ignored deliberately — it removes water and would concentrate the slug, so ignoring it errs conservative.
Stop blowdown, dose, wait how long, resume — using the volumes from step 02.
Uses the system volume and cycles from step 02.
06
Phosphorus ledgeriThe cycles balance, applied to phosphorus. Phosphorus enters as orthophosphate you dose and as phosphonate you dose; it leaves in blowdown, deposits as apatite, or converts — the oxidiser degrades phosphonate into orthophosphate. Against a chloride tracer: total P short of the tracer means it is depositing; ortho P above what you dosed means your phosphonate is being destroyed; both at once means your oxidiser is manufacturing your scale. Every input is a routine test. Assumes steady dosing and a conservative tracer — heavy bleach reduces to chloride and will inflate it.
Two independent failures, one balance, three routine tests.
Makeup rate is optional — supply it and the ledger reports a deposition rate in kg/day.
Enter your routine Cl, total P and ortho P results.
07
Programme couplingsiAn oxidiser does not stay in its lane. It consumes tolyltriazole, so yellow-metal protection falls while the halogen residual still looks fine. It degrades phosphonates into orthophosphate — losing the scale inhibitor AND raising calcium-phosphate supersaturation, which the dispersant then has to absorb. These are directional and disclosed. No rate is put on them: that would need kinetic constants we do not have.
What your biocide does to the rest of the programme.
Build it to evaluate the control measures against your chemistry.
08
Biocide classes
Not a taxonomy — the three classes behave differently in ways the model has to respect.
Ox, non-ox and bio-dispersant — and why only one of them couples back into the scale chemistry.
·
Live-stream diagnosisiClosures, not alarms. A lab analysis is a snapshot; sensors add time, closure and cross-instrument agreement. Each closure is the SAME physical quantity measured two independent ways — when they agree the balance is sound, when they diverge exactly one thing is wrong and which pair diverges names it. A fault fires only when instruments that share no inputs disagree, so it names a cause, not just an alarm. What the numbers mean for asset life is the one fleet-calibrated layer, shown separately and never faked.
Feed the sensor values. The closures, the fault tree and drift detection are all deterministic.
A closure needs both of its instruments — leave a pair blank to skip it.
Run it to see the closures, the fault tree and any drift.
·
RO performance normalisation · ASTM D4516iThe most-used RO operational calculation — and it separates the three failure modes a single number cannot. It normalises a current reading back to your start-up conditions for temperature and net driving pressure, then reads three trends: NPF (normalised permeate flow) down means fouling or scaling; NSP (normalised salt passage) up means membrane damage or a seal leak; NPD (normalised pressure drop) up means the feed channels are plugging. Read together they name the cause: flow-down with pressure-drop-up is fouling; flow-down with salt-up is degradation; salt-up alone is a leak. The temperature-correction constants and the pressure-drop exponent are polyamide defaults, labelled as defaults — override with your membrane’s value. Osmotic pressure uses the standard brackish TDS approximation, labelled; a rigorous value comes from Scale & Corrosion with a full analysis. This is a deterministic published method, not a fitted or fleet model.
Enter your commissioning (reference) reading and a current reading. Flows in your own consistent units; pressures in psi; TDS in mg/L; temperature in °C.
Two readings, the same fields — the reference is your clean start-up; the current is today.
Reference (start-up)
Current (today)
Enter a reference and current reading to separate fouling, scaling and damage.
·
Corrosion rate · coupon or LPR → mpyiTurns a raw corrosion measurement into a banded rate. A coupon (weight loss over a known exposure, ASTM G1) gives the average rate; an LPR probe (polarisation resistance, Stern-Geary + ASTM G102) gives the instantaneous rate. Both are deterministic published arithmetic. The verdict is metal-aware: the same mpy means different things for carbon steel and a yellow metal, so the band uses the metal's own acceptable range (NACE RP0775 for steel; the tighter cooling target for copper alloys), labelled. The Stern-Geary B is a labelled default (0.026 V, actively-corroding steel) and overridable. Neither method sees a pitting or localised rate — only the uniform average. Corrosion consequence (a rate → remaining asset life) is not computed here.
For cooling, boiler and sour systems. Convert a coupon weight-loss or an LPR reading to a banded rate.
Pick the method, the metal, and enter the reading. Fields switch with the method.
Consequence (rate → asset life) is not computed here.
Enter a coupon or LPR reading to see the banded corrosion rate.
A shareable, Waalgo-branded PDF, and your one working report — it's saved to your account and comes back when you sign in again. Build it by using Pin to report at the top-right of any tool's result, across Diagnose, Prescribe, Operate, Learn and Value. Each pinned result carries its water, segment and input parameters alongside the result, as a snapshot from when you pinned it. If you pin nothing, the report falls back to the default sections for your segment. Reorder or remove pins below, or Start fresh to begin a new report. Every number carries its units and the assumption it rests on.
Pinned resultsyour report, in order — reorder or remove
Add live analyses (optional)computed fresh from the water above — added after your pinned results
Pinned results are snapshots from when you pinned them; the water summary and any ticked sections above are computed fresh from the water shown, so those always match what the tools would show right now.
Focus segmentswhat appears on your console
Choose the water systems you work with. The platform shows only the segments you turn on here — the Home picker, the Scale & Corrosion mode buttons, the “My water” tabs, and every tool follow this list. This is your own view and changes nothing in the engine; a tool that is off is simply hidden, not disabled in the chemistry. At least one stays on.
Units & currencyapplied to every screen
Choose your preferred unit for each quantity used on the platform — SI or Imperial, per dimension. The default is SI everywhere and USD. Switching converts the values on screen, not just the labels; the engine always computes in SI, so a unit or currency choice never changes a calculated result. Ion concentrations stay mg/L in both systems — the industry convention, so there is no choice to make there.
Temperature & pressure
Temperature stays °C and pressures keep their per-tool unit for now. These are read across many tool engines (temperature is affine; pressures are labelled per tool), so they are wired next rather than half-wired — a mislabelled temperature is the exact failure this platform exists to prevent. Disclosed, not implied.
Currency
Applied to every price and cost. No exchange rate is applied — the symbol changes and your entered prices are used as typed. We do not hold live FX and will not invent one.
Concentration
mg/L in both SI and Imperial — the water-treatment industry uses mg/L (and ppm interchangeably for dilute waters) regardless of system. Fixed by convention, not a preference.
Live users & capacitywho's on now, and headroom
Two headline counts and the peak-load metric. Live users are distinct people active in the last few minutes — from the pseudonymous activity signal, no PII; registered users is the total number of accounts. The metric below answers the surge question: what binds first, and whether every resource holds 30% headroom above its observed peak. Deeper service liveness, RED metrics, database health and logs live on the System Health tab.
Peak load & capacity — the surge picture: what binds first, and whether every resource holds 30% headroom above its observed peak
Every figure here is observed — a real sample against a real host or configured ceiling — over the trailing 7 days of capacity samples. Load drivers (active users, API calls, DB lock contention) show a peak but never a made-up ceiling. The binding constraint is whichever resource sat highest against its ceiling at the busiest observed moment. Max concurrent is the one projected figure: a linear extrapolation from that busiest point to the binding ceiling, stamped ESTIMATE with its assumption shown — it is not a load-tested limit, and it reads INSUFFICIENT SIGNAL rather than guess when the peak is too thin. Peaks are only as sharp as the sampling cadence — schedule the sample to catch real surges.
Platform segmentswhat this deployment offers
Turn a whole segment on or off for the entire deployment. A segment turned off here is unavailable to every user — it disappears from onboarding, from each person's Settings focus, and from every picker, regardless of their per-user grant. At least one must stay on. Every change is written to the audit log and takes effect on each user's next sign-in.
Access requestsiRequests submitted from the public sign-in screen. Each is stored durably here; the notification email to the platform admin is a side channel and its delivery status is shown honestly per request — “not configured” means SMTP is not set up and this panel is the only channel. Approving means provisioning the user in the panel above; Close marks the request handled.from the sign-in screen — provision above, then close
Provision a useradmin only
Create an account and choose how the person receives it. Invite sends a one-time activation token — they set their own password, and no secret is ever transmitted. Temporary password issues a password they must change on first sign-in. Either way, the account is created here; nothing is self-signup.
Segments this user may access — all by default; the person still picks their own focus within this grant
Usersgrant, suspend, deactivate
Loading…
Audit logwho did what, newest first
An append-only record of account actions — logins, denials, provisioning, activation, password changes, and role/status changes. This is the accountability trail; it is never edited or deleted from here.
Loading…
Tool outcomesedge-case monitoring
How the intelligence tools are reporting, by outcome class. This rides the signals the engines already emit — a normal result (ok), a case the tool does not apply to, an unsolvable input, a safety refusal, or an uncalibrated (banded) answer. A rising edge-rate on one tool is a signal to investigate — a bug, or a shift in what users are feeding it. The counts are aggregate; no water chemistry or user input is stored here.
Loading…
Usagepseudonymous, first-party, internal
Product-usage metrics keyed on a pseudonymous user id — never name or email, and the event stream stores only the action, never water chemistry. First-party and internal only; never sold, shared, or used for advertising.
Loading…
Privacy controls
System healthfor support engineers
Live health of the seven services, the data stores, and growth trends. Green is healthy, amber needs a look, red needs action. Capacity forecasts are shown only where the data actually supports one — a flat or noisy series says “insufficient signal” rather than guessing. Latency and error spikes and lock errors are shown as current values and thresholds, not forecast. The peak-load & capacity metric and the live/registered user counts are on the Admin console.
Data stores
Backups & retention — verified online snapshots; the calibration moat is never pruned
Capacity forecast — when a growing resource reaches its soft limit
Recent warnings & errors — filter by correlation id to trace one request
Program · feature entitlement
Every tab, offer and tool is enabled by default. Disable one here and it is hidden from everyone who is not an admin — the tab button, the offer, or the tool tile simply does not render for them. Admins always see everything (a disabled node is marked off below). Only an admin can change this, and the change is enforced server-side. Scope: this controls UI visibility — a disabled node is hidden from non-admins; hard API-level access control on the underlying endpoints is a separate, disclosed follow-up.
Loading the program tree…
How this platform works
Waalgo answers five questions about one water — Diagnose (what will it do), Prescribe (what to hold and what it costs), Operate (act, safely gated), Learn (feed field data back) and Value (the business case) — across five kinds of system (cooling, reverse osmosis, sour, acid-drainage, boiler), plus a cross-cutting Microbial control suite. Every screen reads the same shared water. Tools that don't fit a given water are greyed out, and a segment never shows another segment's answer.
The one discipline behind every tool. Waalgo computes what physics, chemistry, geometry and balance determine — and where an answer needs a measurement (a halogen demand, a NORSOK Kt constant, a lab isotherm, a limestone armoring rate, a steam-table heat content, a price) or lies outside what the model can certify (Legionella, a ‘kill dose’), it asks for it or says so, rather than inventing a number. When you see “INCOMPLETE”, “not computed” or “enter the source-stamped price”, that is the product working as designed — it is what makes the numbers it does give you defensible.
How to read any tool below
What it is — the question it answers. Where — the screen it lives on. Open — jumps you straight to it on the right segment. Honest boundary — what it does not claim. The full training guide carries five worked examples and a complete use-case catalogue per tool.
REFERENCE · NO MODELLINGEvery number here is real
The examples in the training guide are not illustrative — every reading was captured live from the running engines. A tool that would have to guess a coefficient, a rate or a price returns a stated gap instead.
GRADED AGAINST THE CODETool directory
Browse the hierarchy or search to find a tool, then select it to see a plain-language explanation, a worked example, and everything it’s good for — with an Open button that jumps you straight to it.
Loading the tool directory…
Release
— · released —. This is 0.x on purpose. The version number is a claim, and 1.0 would claim the core is validated. It is not: the inhibitor ranking has never been checked against wet-lab dose-response. The thermodynamics being right — PHREEQC, published constants, and the checks below — is not the same thing, and the version must not blur it. 1.0.0 ships the day that calibration exists, not before, however many checks pass. Every release carries a changelog entry recording what changed and what was found to be wrong; a test asserts the entry exists.
What this console is
Waalgo computes scale, corrosion and microbiological-control conditions across five kinds of water system — cooling towers, reverse osmosis, oil & gas (sour), mining acid drainage and boilers — and pre-screens candidate treatment chemistry against a compliance envelope. It is built so that every number tells you how much it is worth — and so that where a number would be dishonest, you get a stated gap instead. Five screens, one water: Scale & Corrosion computes the saturation state, Microbial control and Intelligence both read from that analysis, Sensors diagnoses the live operating data, and Inhibitor Screening ranks chemistry against it. The segment-specific reads (sour, acid-drainage, boiler) surface only on the water that needs them.
The reason to run them together is that they share knobs and disagree about them. Raising pH from 7.0 to 8.6 improves mild-steel corrosion, drives calcite from +0.41 to +1.86, drives hydroxyapatite from +4.75 to +10.76, and collapses active chlorine from 77.6% to 8.0%. Four outcomes, three vendors, one knob. Each vendor optimises their own and the plant lives with the sum — this console exists to show the sum.
Engine 1 · Scale & Corrosion
Saturation indices from published thermodynamics. Two engines: Fast (Davies) for screening, Rigorous (PHREEQC, auto-Pitzer above I > 0.5) for brine and seawater. Carbonates, sulphates, barite/celestite, amorphous silica and sepiolite (Mg-silicate) — every phase on one activity model, including silica.
VALIDATEDEngine 1 · Scale & Corrosion · Incompatible-water mixing (Stage 2)
The seawater-injection scaling problem: two waters that are each safe alone can scale badly when mixed — sulfate-rich seawater meeting barium-rich formation water precipitates barite (BaSO₄) at the mixing front, worst at an intermediate ratio, though neither parent is supersaturated. This tool fabricates no chemistry: it conservatively blends the two analyses across the mixing range and runs each blend through the same saturation engine as the rest of the console, then reports the phases the mixture drives supersaturated that neither parent does (a true emergent incompatibility) versus a risk a parent already carries. Honest by construction: SI is a thermodynamic tendency, not a rate or a deposited mass; the mixing front's kinetics are not modelled; pH and temperature are blended linearly as a labelled first approximation. Surfaced on the sour segment, where injection incompatibility is the killer case.
VALIDATED · ENGINE-ROUTED · NO FABRICATIONEngine 2 · Inhibitor Screening
RDKit descriptors (exact) plus two separate heuristics — a corrosion axis and a scale axis — filtered against your compliance envelope.
HEURISTICEngine 1 · Microbial control
Halogen speciation (Morris 1966), holding time, demand-corrected residual from Standard Methods 2350, dose-for-residual, the bio-dispersant slug window, and the phosphorus ledger. Plus an ASHRAE 188 control-point register fed live from Engine 1’s deposit and corrosion numbers. It does not predict Legionella — no validated bulk-chemistry-to-CFU model exists, and the register does verification, never validation.
VALIDATED · NO PREDICTIONEngine 1 · Intelligence (Diagnose · Prescribe · Operate · Learn)
The inverse problems, run against the same analysis, split into four offerings over one shared makeup water: Diagnose (cycle limit, sensitivity, binding constraint), Prescribe (cycles balance, programme cost, operating setpoints, independent audit), Operate (the unified twin, control decision, sandbox), Learn (calibration). Its point is cross-validation: thermodynamics predicts a cycle ceiling, your logbook measures one, and the two are shown side by side. The console opens on Diagnose with a worked example already loaded and analysed, so the first screen shows results rather than an empty form; the deterministic reads run automatically and refresh whenever the water changes. Diagnose serves both cooling and reverse osmosis: a system toggle switches the cycle-limit read from evaporative cycles to RO recovery, evaluated at the membrane wall (CF × β) where scale nucleates — the same limiting-salt logic, the correct concentration physics for each. Tools are gated to the segment they fit: the cooling/RO cycles-of-concentration reads (cycle limit, sensitivity, cycles balance) are marked not-applicable on sour, acid-drainage and boiler water — where there is no concentration model — and the segment-native read (Segment chemistry) is surfaced instead, so a non-cooling water never shows a cooling answer. The segment-adaptive tools (programme cost, operating setpoints, binding constraint) carry the segment through to the engine and stay available everywhere. The Operate tools and the independent audit are now segment-aware too: for sour, acid-drainage and boiler the unified twin, control decision and audit run on the validated segment reads (never a cooling answer), and the closed-loop sandbox — an intrinsically cooling-tower model — is honestly declined for those segments rather than shown a fabricated trajectory. The water can be built by hand or imported from a lab analysis; an imported value is validated at the boundary and tagged caller-supplied.
VALIDATEDEngine 1 · Segment chemistry (sour · acid-drainage · boiler)
For waters that carry dissolved sulfide (O&G sour), low-pH metals (mining acid drainage), or dissolved oxygen (boilers), the engine runs the WATEQ4F thermodynamic database to evaluate the phases those segments care about: barite and iron-sulfide scaling, aluminium-hydroxide, alunite and jarosite, and oxygen redox. It appears only when the water carries those species — a normal cooling or RO water shows nothing here, by design. The water form asks for the defining species of the chosen segment (sulfide for sour, the Al/Mn metals for acid-drainage, dissolved O₂ for boilers), so the segment read resolves on the composition it actually needs rather than silently returning nothing. The saturation thermodynamics are validated against the database; a phase that is thermodynamically favoured but kinetically too slow to form now (Pyrite, Jarosite, Alunite) is flagged as a watch-indicator, never reported as present-day scale. What is not yet earned: per-site inhibitor dose calibration for these segments — the numbers say what the water wants to do, not what a specific treatment will cost.
DB-VALIDATED · DOSE UNCALIBRATEDEngine 1 · Diagnose · Net acidity (AMD entry point)
The entry point for acid mine drainage: net acidity — not pH — decides whether a water self-neutralises or needs added alkalinity, because a circumneutral water can carry high dissolved metal (latent acidity) that appears as the metals hydrolyse. Deterministic Kirby-Cravotta / Hedin calculated acidity (proton acidity from pH + the Fe/Mn/Al load by charge) minus your measured alkalinity, with the per-source breakdown. If total iron is given it is treated as ferrous — a labelled default; split it into Fe(II)/Fe(III) for the exact value. The lime figure is the stoichiometric CaO demand; real plant demand is higher by a plant-specific utilisation factor that is not fabricated here. Recovery % and product purity are not computed, and sludge volume needs an entered percent-solids — but the sludge dry mass is now computed (the Sludge generation tool); the remaining items are a stated AMD gap: this sizes the chemistry demand, not the plant. AMD-only by construction — shown on the acid-drainage segment.
VALIDATED · DETERMINISTIC · STOICHIOMETRIC LIME · AMD-ONLYEngine 1 · Prescribe · Phosphate-pH control (boiler)
The daily control decision for a phosphate-treated drum boiler. The Na:PO₄ molar ratio sets the pH the phosphate produces and the corrosion risk: above 3.0 free caustic (gouging); 2.2–2.8 the congruent in-control band; below 2.2 acid-phosphate (corrosion / maricite). This is the coordinated-phosphate diagram computed from the deterministic phosphate acid-base equilibria (pK₁/pK₂/pK₃ at 25 °C, labelled), not read off a chart — it backs out your effective ratio from measured phosphate and pH and gives the target pH at the congruent centre. The pressure-specific phosphate CONCENTRATION band is NOT supplied from memory — those limits come from your plant's chemistry program / current EPRI guidance; only the ratio, regime, target pH and the qualitative hideout principle are computed. A load-swing pair flags the hideout signature (phosphate down + pH up at load), never a predicted rate. Boiler-only by construction.
VALIDATED · DETERMINISTIC · BAND DEFERRED TO PLANT · BOILER-ONLYEngine 1 · Prescribe · Boiler cycle / blowdown twin (boiler)
The boiler analogue of the cooling dynamic twin. A drum boiler concentrates dissolved solids like a tower — feedwater in, steam out nearly pure, blowdown the only path out — so it reuses the cooling twin's validated implicit-Euler integrator (segment-neutral numerics; the boiler-water transient converges to feedwater×COC exactly), but watches boiler chemistry: silica, TDS/conductivity and alkalinity. Deterministic (ships): maximum cycles of concentration = min(limit÷feedwater) over those species (a ratio, the binding species named), and the boiler-water transient — cut blowdown and see when each species reaches its limit. COC is an OUTPUT (feedwater÷blowdown), never assumed. Gated (honest gap): the phosphate-hideout, scale-deposition and caustic-embrittlement RATES are not predicted — the hideout signature is routed to the validated boiler phosphate read, and silica carryover into steam is emitted only against an entered distribution ratio, never fabricated. Boiler-water limits are entered (your ASME/EPRI/OEM spec for the pressure); the defaults are illustrative and loudly labelled. Boiler terms (feedwater/steam/blowdown/cycles) are native, not cooling framing. Boiler-only.
DETERMINISTIC CYCLE LIMIT + TRANSIENT (REUSED KERNEL) · COC IS OUTPUT · HIDEOUT / DEPOSITION RATES GATED · BOILER-ONLYEngine 1 · Prescribe · Boiler control regime (boiler)
The boiler analogue of the cooling control-regime tool, and the fill for the Operate-page gap the coverage review confirmed: a boiler HAS real closed-loop control (not honest-by-physics that it doesn't). It recommends the control mode, deadband floor and failsafe for each chemical-feed loop — blowdown, oxygen scavenger, phosphate/pH — by reusing the cooling tool's segment-neutral kernel (dead-time÷lag rule + actuator binding + deadband floor), so the same invariants hold: no analog-only mode on a relay, no PID when dead-time dominates. The blowdown gain d(cycles)÷d(blowdown) is computed from the same mass balance as the cycle twin; the phosphate target is routed through the validated phosphate read. Failsafes are reasoned per loop (blowdown fails open to protect the turbine; scavenger/phosphate fail last-good). The scavenger dose target stays uncalibrated (mode only), limits are entered, and the SIL life-safety interlocks (level, pressure) are explicitly NOT modelled — chemistry control, not the safety system. Boiler-only.
DETERMINISTIC MODE / DEADBAND / FAILSAFE (REUSED KERNEL) · GAIN FROM MASS BALANCE · DOSE + SIL OUT OF SCOPE · BOILER-ONLYEngine 1 · Prescribe · Oxygen-scavenger dose (boiler)
The chemical dose that removes residual dissolved oxygen from boiler feedwater. The dose follows the scavenger's reaction stoichiometry with O₂ — exact published chemistry: sulfite 7.88 ppm/ppm O₂, hydrazine 1.00, carbohydrazide 1.41; DEHA is a labelled published ~1.24 (its oxidation is not a clean 1:1, and the tool says so). Any target residual and excess are operator-supplied and added to the demand — the specific residual band by pressure comes from the plant's chemistry program / EPRI, not from memory. It does not pick a scavenger — that is a program decision; it doses the chosen one and states the trade-offs (sulfite adds TDS and is non-volatile; the amines carry over and passivate the steam side). Hydrazine is flagged as a suspected carcinogen / controlled substance every time it is selected, never dosed silently. Boiler-only by construction.
VALIDATED · DETERMINISTIC · HYDRAZINE FLAGGED · BOILER-ONLYEngine 1 · Prescribe · Condensate amine / AVT (boiler)
The carbonic-acid corrosion of the condensate return and the neutralizing-amine demand to control it. CO₂ carried over with the steam dissolves in the condensate as carbonic acid, drops its pH and corrodes the carbon-steel return line. Deterministic (ships): the acidified condensate pH from the carbonic-acid equilibrium, and the neutralizing base demand to a target condensate pH = [HCO₃⁻]+2[CO₃=]+[OH⁻]−[H⁺] — closed-form carbonate arithmetic, ~1 eq of base per mol free CO₂ to the bicarbonate endpoint, then the condensate amine mass at the amine's equivalent weight. The honesty seam: the carbonate constants are the standard 25 °C reference values, LABELLED; the CO₂ carryover from feedwater alkalinity uses the published 0.79 factor as a LABELLED theoretical upper bound (actual carryover entered, never assumed); the amine equivalent weight is a labelled library value; and the amine distribution ratio is ENTERED, never from memory — without it the condensate amine still computes but the feedwater dose is INCOMPLETE, a first-order estimate assuming the entered DR when supplied. The tool does not choose the amine, model the condensation profile down the return, or claim a corrosion rate — those are gated. Boiler-only.
VALIDATED · DETERMINISTIC (CARBONATE) · CO₂ BOUND / EW / DR LABELLED-OR-ENTERED · DOSE GATED WITHOUT DR · BOILER-ONLYIntelligence · Control decision & closed-loop sandbox
The safety gate made visible. Control decision shows what would actuate loop-by-loop for a requested mode: autonomous is structurally refused on a plant and downgraded to advisory, and a human-only-safety action (oxidiser, biocide) is never actuated in any mode. The sandbox proves the loop converges rather than hunts — on a simulator only, with the oxidiser structurally absent from the loop. The sandbox dynamics are deliberately simplified and are not a calibrated plant model: it validates the loop’s logic, not your tower’s behaviour. Segment-aware: both are cooling-tower models, so on sour, acid-drainage and boiler water Control decision returns the segment setpoint as advisory (autonomous gated with an honest reason) and the sandbox declines rather than draw a cooling trajectory for a non-cooling water — a named gap, never a fabricated loop.
VALIDATED · SAFETY-GATED · SEGMENT-AWAREIntelligence · Learn (calibration)
Where the moat is built — and honestly gated. Service-visit points are classified (steady / drift / step); a dose-change step is excluded from the fit and flagged for human confirmation rather than silently absorbed; the coefficient is fitted with a confidence interval. A coefficient reaches CALIBRATED only on FIELD or LAB provenance and a tight interval. Synthetic data can never calibrate anything, however many points are added — the status stays SYNTHETIC by construction.
MACHINERY READY · UNCALIBRATEDIntelligence · Learn · Field-data capture + calibration tracker (Spec 2)
The moat MOTION on top of the learner — where captured field data becomes calibration. Service-visit points are persisted (the specced SQL schema is deployed here) and the coefficient posterior is accumulated across every visit, tightening the interval as data arrives. A per-coefficient distance-to-CALIBRATED view shows how far each is from trustworthy — and is honest about the kind of data missing: a coefficient with only synthetic points is BLOCKED on field data (no quantity of synthetic reaches CALIBRATED), while one with field points but a wide interval shows ~N more field points at the current scatter. The public capture path is untrusted: any point claiming FIELD is clamped to SYNTHETIC, so nothing captured through the API can calibrate scale_score — only a trusted field integration fills the moat. This is the item that unblocks both the dose-response surface and the fleet corpus, since all three wait on the same field data.
CAPTURE + TRACKER BUILT · PERSISTS + ACCUMULATES · UNTRUSTED CANNOT CLAIM FIELD · AWAITING TRUSTED FIELD INTEGRATIONIntelligence · Retrieval (not surfaced yet)
The physical water-similarity metric and the cite-never-compute precedent layer are built and gated, but deliberately not given a screen. Both need a fleet corpus of comparable waters and case notes, and that corpus does not exist yet — it is the field data the platform is still gathering. A retrieval screen today would either ask you to paste your own corpus or always answer “no precedent”. Rather than ship a dead end, it stays unwired until there is something real to retrieve.
BUILT · AWAITING FLEET CORPUSIntelligence · Independent audit
A vendor-neutral second opinion on your current operating point: where the pH and cycles you run today sit against this water’s own setpoints and binding constraint, with a severity and a basis on every finding. It never states a point-value dose — inhibitor dose-response is uncalibrated, so it bounds rather than prescribes — and it carries an explicit “what this cannot say without your field data” section. It composes only already-gated deterministic functions and carries no chemical supply interest. Segment-aware: for sour, acid-drainage and boiler the audit is assessed against the validated segment reads (segment chemistry, segment binding, segment setpoints), not a cooling cycle model — and it still names, in the “what this cannot say” section, the per-site dose and the closed-loop trajectory that are not modelled for that segment.
VALIDATED · DETERMINISTIC · NO POINT DOSE · SEGMENT-AWAREIntelligence · Binding constraint
The coupled cycle ceiling: scale saturation, biocide holding time and your discharge consent in one envelope, with the first to bind named. The chemistry and holding time are computed exactly; the differentiated part is the coupling — the ceiling is often the discharge consent or your own phosphate inhibitor (apatite), not carbonate. Discharge consents are entered from your permit, never supplied from memory. Holding time is a residence-time risk factor for your assessment — not a Legionella prediction.
VALIDATED · DETERMINISTICEngine 1 · Sensors
Live-stream diagnosis from closures — the same physical quantity measured two independent ways (cycles from conductivity vs an inert tracer; free chlorine from ORP+pH via Nernst; delivered dose from the tracer; heat transfer from approach temperature). A fault fires only when instruments that share no inputs disagree, so it names a cause, not just an alarm. Drift is caught by the Nernst follow-ratio — a pH move ORP does not follow is a probe, not demand. All deterministic closed-form physics, no fitted model. Consequence — what a rate means for asset life — is the one fleet-calibrated layer, shown separately and never faked. A free-chlorine residual below the control threshold is flagged as a human-only microbiological-control condition for human assessment — a physical residual threshold, never a Legionella prediction, and the oxidiser is never auto-dosed to correct it. Physically impossible or non-numeric inputs (negative concentrations, pH outside 0–14, injected strings) are rejected at the boundary, never computed into a plausible wrong number.
VALIDATED · DETERMINISTICEngine 1 · Diagnose · Thermal performance (cooling)
The two textbook cooling thermal reads a plant already logs, exposed as a tool — both closed-form heat-transfer arithmetic, no fitted model, no fabricated coefficient. Tower thermal effectiveness: range = hot-in − cold-out, approach = cold-out − wet-bulb, effectiveness = range÷(range+approach) — and a tower cannot cool below the wet bulb, so a cold-water reading beneath it is rejected, not computed. Heat-exchanger fouling resistance: Rf = 1÷Uservice − 1÷Uclean, the added thermal resistance from deposits, with Uservice entered or derived deterministically from duty÷(area×LMTD). The baselines are yours: the commissioning design approach and the clean-design U are ENTERED from the datasheet, never supplied from memory — without a baseline the current metric still computes but the degradation / fouling-resistance piece is INCOMPLETE, never a fabricated default. A service U above the clean U is flagged as a measurement anomaly, not a fouled state. This surfaces the same approach-temperature physics the Sensors closure already watches, as a standalone diagnostic. Cooling-only.
VALIDATED · DETERMINISTIC · BASELINES ENTERED · COOLING-ONLYEngine 1 · Diagnose · SDI / pretreatment screening (RO)
The standard reverse-osmosis feedwater fouling-potential screen, computed exactly from ASTM D4189: %P = (1 − ti/tf)×100, SDIT = %P/T — deterministic, no fitted model, no fabricated coefficient. The ASTM validity is enforced: at or above 75% plugging the result is unreliable and flagged (repeat with a shorter T), never reported as a plausible-wrong SDI. The acceptability band (LOW / MODERATE / HIGH) uses the near-universal spiral-wound guideline (SDI15 warranty ≈5, preferred ≈3) as a LABELLED default, overridable by the membrane manufacturer's own warranty limit — never presented as calibrated to a plant. The pretreatment recommendation is a class from published selection practice (cartridge / media ± coagulation / UF-MF by band), and the SDI a pretreatment will ACHIEVE is NOT predicted — that needs a pilot / bench trial, returned as an explicit gap and never fabricated. Impossible readings (a final sample time below the initial — the membrane did not plug) are rejected with a reason. RO-only by construction (the test is defined for pressure-driven membrane feedwater).
VALIDATED · DETERMINISTIC (ASTM D4189) · THRESHOLDS LABELLED · PRETREATMENT-RESULT GATED · RO-ONLYEngine 1 · Sensors · RO performance normalisation (ASTM D4516)
The single most-used RO operational calculation, and the one that separates the three failure modes a raw number cannot. It normalises a current reading back to your commissioning conditions and reads three trends together: NPF (normalised permeate flow) down → fouling or scaling; NSP (normalised salt passage) up → membrane degradation or a seal leak; NPD (normalised pressure drop) up → feed-channel plugging. Read as a set they name the cause — flow-down with pressure-drop-up is fouling, flow-down with salt-up is degradation, salt-up alone is a leak. It is a deterministic published method, not a fitted or fleet-calibrated model. The temperature-correction constants and the pressure-drop exponent are polyamide defaults, LABELLED as defaults and overridable — not dressed up as calibrated to your plant; osmotic pressure uses the standard brackish TDS approximation, labelled, with a rigorous composition-based value available from Scale & Corrosion. The damage verdict uses a recovery-invariant salt-passage signal, so a pure flow decline is not misread as membrane damage. Impossible readings (recovery ≥ 1, net driving pressure ≤ 0) are rejected with a stated reason, never computed into a plausible-wrong number. RO-only by construction — the method is defined for pressure-driven membrane arrays and is shown only on the RO segment.
VALIDATED · DETERMINISTIC · DEFAULTS LABELLED · RO-ONLYEngine 1 · Prescribe · RO array balance + CIP (RO)
The system-level design read for a reverse-osmosis array. From the feed, target recovery and membrane area, the system mass balance is exact: concentration factor CF = (1−R(1−r))/(1−R), concentrate and permeate TDS, permeate/concentrate flow, average flux — at 75% recovery CF ≈ 4, the rule of thumb, computed. The per-stage split is a labelled uniform-flux approximation. The element-by-element profile (lead-element over-flux, per-element dP) is NOT computed — that needs the full element-hydraulic model (the Wave-3 build) and is returned as an honest gap, never a fabricated per-element number. Salt rejection, element area and β are labelled defaults. It reports the concentrate concentration, not the saturation — run the concentrate through Scale & Corrosion for that. A CIP regime follows deterministically from the foulant (acid for scale, alkaline for organic/bio); the specific dose/temperature is membrane-specific and deferred to the element's guidelines. RO-only by construction.
VALIDATED · DETERMINISTIC · ELEMENT-BY-ELEMENT NOW A DEDICATED TOOL · RO-ONLYEngine 1 · Prescribe · RO element-by-element profile (RO)
Resolves a pressure vessel spatially — per-element flux, recovery, TDS and pressure — so the lead-element over-flux and tail-element under-flux are visible instead of averaged away (the lead is where fouling/scaling start; the tail is where brine peaks). A first-principles solution-diffusion marcher in the FilmTec form: Jw = A·NDP, Js = B·ΔC, pf = exp(0.7·Y), ΔP = 0.01·q1.7, with the FilmTec TCF and a van't Hoff osmotic term. A and B are back-calculated from the element's public datasheet (permeate flow, rejection, test conditions) — a clean, new-membrane value, labelled; they are NOT fitted to a plant and NOT the aged/fouled state, and the fouling factor is your assumption. The profile shape and recovery are the reliable read; the absolute pressure carries the stated band. Accuracy: ~5–10% vs a manufacturer projection, ~10–20% vs a real aged plant. Validated against the Johnson & Busch (2010) published seven-element worked case — a real external oracle, reproduced by validate_ro_element_profile.py (recovery converges, flux declines monotonically lead→tail, ratio in the published band). RO-only by construction.
VALIDATED (vs PUBLISHED CASE) · A/B DATASHEET-NOMINAL · NOT PLANT-CALIBRATED · RO-ONLYEngine 1 · Prescribe · RO fouling twin / CIP-cycle (RO)
The RO analogue of the cooling dynamic twin, split into two claims. Deterministic (ships): each operating point is normalised against the reference by ASTM D4516 (routed through the platform's own normaliser, no re-implementation), giving normalised permeate flow / salt passage / pressure drop; a least-squares trend on each — with an R² noise guard so noise is never called a decline — is projected to its entered cleaning threshold to give the CIP-due day, the soonest indicator setting the schedule and the moving indicator naming the foulant class (the D4516 verdict). Gated (honest gap): the mechanistic fouling rate, remaining membrane life and whether a clean will recover performance are NOT computed — they need a membrane autopsy or fleet data, and are never fabricated (the same gap as scale_score and the cooling twin's Sim B rate). A MEMBRANE_DEGRADATION signature is flagged as cleaning will not restore it. Cleaning thresholds are entered/edition-stamped, never supplied from memory. RO-only.
DETERMINISTIC TREND PROJECTION (D4516-ROUTED) · FOULING RATE / LIFE / RECOVERY GATED (HONEST GAP) · RO-ONLYEngine 1 · Prescribe · RO control regime (RO)
The RO analogue of the cooling / boiler control-regime tool — completes the Operate-page gap fill across both evaporative/pressure segments. Recommends the control mode, deadband floor and failsafe for the four RO chemical-feed loops (antiscalant, acid/pH, dechlorination, CIP) by reusing the cooling tool's kernel and its chlorine-speciation gain profile, so the same invariants hold (no analog-only mode on a relay, no PID when dead-time dominates). Dechlorination is the inverted oxidiser: free chlorine destroys the membrane fast and irreversibly, so — unlike the cooling oxidiser (no safe default) — this loop HAS a safe default (protect the membrane). Antiscalant is flow-paced with the dose target uncalibrated; the CIP trigger routes through the RO fouling twin (entered cleaning threshold), never a fabricated rate. Limits are entered. Hard boundary: the high-pressure safety interlocks are NOT modelled — chemistry control, not the safety system. RO-only.
DETERMINISTIC MODE / DEADBAND / FAILSAFE (REUSED KERNEL) · DECHLOR HAS A SAFE DEFAULT · DOSE + HP INTERLOCKS OUT OF SCOPE · RO-ONLYEngine 1 · Prescribe · Passive AMD treatment sizing (AMD)
Recommends a passive treatment train and sizes each unit from published design criteria. Selection follows the Hedin/Nairn/Kleinmann (1994) decision tree: net-alkaline → aeration + settling + aerobic wetland; net-acidic with DO/Fe(III)/Al all < 1 mg/L → anoxic limestone drain (ALD); otherwise → RAPS / vertical-flow pond; net acidity > 300 mg/L precludes stacked ALDs. Sizing from published loading rates — aerobic wetland Fe 10/20, Mn 1/2 g/m²/d (Hedin & Watzlaf 1994); RAPS acidity 25–35 g/m²/d (AMDTreat / Rose 2004); ALD limestone = the larger of a 15 h retention hold and life-neutralisation; settling 24–48 h (PIRAMID). Rates are empirical medians with wide site-to-site variance — the compliance basis is ~2× conservative; it sizes but does not guarantee effluent quality. COST is not computed: unit prices are region- and time-specific and uncalibrated by design — the card names the cost-driver structure but supplies no prices, the same disclosed gap as elsewhere. AMD-only by construction.
VALIDATED · DETERMINISTIC SIZING · COST UNCALIBRATED (BY DESIGN) · AMD-ONLYEngine 1 · Prescribe · Limestone depletion clock (AMD)
The dynamic companion to passive sizing. A passive AMD bed has no control loop — its dynamic behaviour is slow depletion — so this forecasts when the limestone needs replacement. Deterministic (ships): remaining life = installed limestone ÷ consumption, where consumption = acidity load ÷ (purity × efficiency) via the same neutralisation stoichiometry as the sizing tool (routed through it, one source of truth). The result is a stoichiometric upper bound — the real life is at or below it. Gated (honest gap): the armoring rate (Fe/Al hydroxide coating shortens the real life) and end-of-life effluent quality are not predicted — any armoring de-rating is an entered field factor, never fabricated (the same gap the sizing tool already declares). Net-alkaline water reports no depletion. AMD-only.
DETERMINISTIC STOICHIOMETRIC CLOCK · UPPER BOUND · ARMORING RATE GATED · AMD-ONLYEngine 1 · Prescribe · Sludge generation (AMD)
The disposal-cost driver — sludge handling is a major, often-overlooked annual cost, and disposal is billed by volume. Deterministic (ships): the dry-solids mass, where each dissolved metal converts to its hydroxide by a fixed molar-mass ratio (Fe(OH)₃ 1.914, Mn(OH)₂ 1.619, Al(OH)₃ 2.891), 100% at the design pH endpoint — the AMDTreat convention, not a fitted or fleet model. Iron is taken as ferric hydroxide Fe(OH)₃ (the aerated active-treatment basis) — a labelled choice that differs, on purpose, from the net-acidity engine's ferrous default (that scores the raw water's latent acidity; this scores the treated precipitate); a passive/anoxic flag warns the ferric basis over-states iron. Not fabricated: the wet volume needs the site-specific percent-solids (and, optionally, density), both entered — supply them and the volume is computed, leave them blank and only the dry mass is returned, the volume an honest gap. Gypsum / calcite / excess-lime solids are not estimated (they need the reagent dose and are saturation-dependent) — caller-owned only. AMD-only.
DETERMINISTIC DRY MASS · VOLUME NEEDS ENTERED %SOLIDS · NOT FABRICATED · AMD-ONLYEngine 1 · Prescribe · Scale-inhibitor squeeze design (sour / O&G)
Designs an oilfield scale-inhibitor squeeze in three layers, each honestly labelled. (1) Scaling driver — which scale the squeeze protects against, routed through the platform's own saturation + incompatible-mixing engine (no chemistry re-implemented). (2) Reservoir geometry — deterministic first principles: radial penetration r = √(rw²+V/(πhφS)), treated pore volume, inhibitor mass placed. (3) Squeeze lifetime — the frontal-advance model Vlife = 1+ρ(1−φ)/φ·(k/n)·MIC(1/n−1) [Hong & Shuler 1988; Sorbie 1992], deterministic ONLY given a lab-measured isotherm (Freundlich k, n) and MIC. Those are rock-and-brine-specific lab measurements (static-adsorption bottle test + coreflood) and cannot be predicted from water chemistry — without them the tool returns an explicit lab-data-required gap, never a fabricated isotherm or lifetime. Units and the Freundlich exponent convention (Γ=k·C1/n, Γ in mg/g) are stated. Sour-only by construction.
DETERMINISTIC CORE · LIFETIME NEEDS LAB ISOTHERM+MIC (HONEST GAP) · SOUR-ONLYEngine 1 · Prescribe · Sour progression twin (sour / O&G)
The sour analogue of the dynamic twin, built honestly around the one sour progression that is deterministic: scaling onset as injection water breaks through. As sulfate-rich injection water (seawater) mixes into Ba/Sr-bearing formation water, the blend supersaturates in barite/celestite that neither water forms alone — the classic produced-water problem. Deterministic (ships): the onset is routed through the validated mixing scan (the platform's own saturation engine) — the smallest seawater fraction each emergent scale crosses SI > 0, the binding scale named, and (against an entered breakthrough curve) the field-life time. Gated (honest gap): the reservoir souring rate (biogenic H₂S), scale deposition rate and CO₂/H₂S corrosion rate are not predicted (reservoir-/lab-specific) — an entered souring trajectory is walked as-is, never generated. This is a thinner tool than the other twins by design: the novel sour dynamics are genuinely lab-gated, so it reframes the validated mixing scan as a field-life progression rather than modelling a rate. Sour-only.
DETERMINISTIC SCALING ONSET (MIXING-SCAN-ROUTED) · SOURING / DEPOSITION / CORROSION RATES GATED · SOUR-ONLYEngine 1 · Diagnose · NORSOK M-506 CO₂ corrosion (sour / O&G)
A second published CO₂-corrosion band, beside the de Waard–Milliams estimate already in the sour path — NORSOK M-506's semi-empirical rate for carbon steel, CR = Kt·fCO₂0.62·(S/19)(…)·f(pH). The honesty seam is the whole design: the method is assembled deterministically here (CO₂ partial pressure by Dalton, fugacity, the shear term, the product), but the two most error-prone, strongly-tabulated NORSOK constants are NEVER supplied from model memory — Kt (the temperature table) and f(pH) (the pH polynomials) are ENTERED from your copy of the standard, standardized values in the same class as ASME limits; reproducing a safety-relevant published polynomial from memory, subtly wrong, would be worse than requiring it. Without Kt the rate is INCOMPLETE. The stable method exponents (0.62; 0.146/0.0324) are LABELLED NORSOK defaults, overridable — verify against the standard; the fugacity coefficient and f(pH) default to a conservative 1.0, LABELLED. It is a published-model estimate, not calibrated to your field, and can diverge from de Waard–Milliams (that divergence is informative); localized/pitting attack, H₂S/sour cracking and inhibitor availability are NOT covered. Sour (O&G) only.
NORSOK METHOD ASSEMBLED · Kt / f(pH) ENTERED (NEVER FROM MEMORY) · NOT CALIBRATED · SOUR-ONLYEngine 1 · Value · ROI / eROI value ledger (all segments)
The first Stage-3 business-layer tool — it translates a physical operating improvement into water / energy / carbon / labour / dollar terms for a plant manager, without crossing the no-fabrication line. The physical quantities it derives are all textbook, deterministic water balances: the cooling water balance from a cycles change (blowdown = evaporation÷(cycles−1)), RO intake water from a recovery change (feed = permeate÷recovery), and boiler makeup water from a cycles change (blowdown = steam÷(cycles−1)); every other quantity is entered and flagged, never invented. Every price and carbon/energy factor is ENTERED and source-stamped, never supplied from memory — treated exactly like a regulated limit; a missing price makes its line INCOMPLETE (it contributes nothing), never a fabricated default. Each line is a transparent quantity × price product. Physical and monetary confidence are reported apart: the water saving is DETERMINISTIC, but every dollar and carbon figure is HEURISTIC (it rides on an entered price) — a deterministic quantity is never laundered into a validated saving. Prices may be entered as bands; payback / simple ROI% appear only with an entered capital cost. All segments (physical deltas can be entered for any segment; the cooling, RO and boiler water balances are all wired deterministic derived cases).
DETERMINISTIC WATER BALANCE · PRICES ENTERED (NEVER FROM MEMORY) · MISSING PRICE = INCOMPLETE, NOT FABRICATED · PHYSICAL vs MONETARY CONFIDENCE SPLIT · ALL SEGMENTSEngine 1 · Value · Compliance report (all segments)
The second Stage-3 business-layer tool — an audit-ready value-vs-limit record for ASHRAE 188, NPDES discharge, ASME/EPRI cycle-chemistry or mine-discharge. It holds the platform's standing line on regulated limits: every limit is ENTERED and edition-stamped, never supplied from memory. A parameter with an entered limit is assessed transparently (value vs limit and its operator) → PASS/FAIL; a parameter without a limit is reported but NOT assessed — never a fabricated limit, never a default pass — and is excluded from the overall verdict. Every value carries its provenance (engine / measured / entered). The record must name its standard and edition or it is INCOMPLETE. For ASHRAE 188, no Legionella CFU is predicted (the platform refuses that) — the register documents the water-management program, and a culture result is a laboratory input assessed against an entered action level. It is a factual record, not a legal certification: confirm the standard/edition and have a qualified person sign off before any regulatory submission. All segments.
VALUE vs ENTERED LIMIT · LIMITS NEVER FROM MEMORY · NO LIMIT = NOT ASSESSED, NOT PASSED · NO LEGIONELLA CFU · RECORD, NOT A CERTIFICATION · ALL SEGMENTSEngine 1 · Value · AMD lifecycle cost / NPV (AMD only)
The third Stage-3 business-layer tool and the first built off the competitive benchmark, which ranked AMD lifecycle costing the highest-relevance next tool — AMD is the one segment whose cost tooling is government/academic and free (OSMRE AMDTreat, USGS PHREEQ-N-AMDTreat) with no commercial vendor-neutral platform. It builds an AMDTreat-style whole-of-life cost: capital + annual O&M + recapitalization (media replacement), discounted to NPV. The honesty seam: physical quantities are routed from the validated AMD reads (net-acidity → reagent demand, passive sizing → limestone mass, sludge → disposal tonnes/volume, depletion clock → replacement interval) or entered, each tagged with provenance — never fabricated. Unit costs are ENTERED and UNCALIBRATED: the platform has never calibrated an AMD cost coefficient and never supplies one from memory, so a line with no unit cost is INCOMPLETE — listed, excluded, never a fabricated default. The NPV is deterministic arithmetic given your entered discount rate and horizon (a horizon is required; a rate is never assumed). Physical vs monetary confidence are kept apart: the dollar total is a HEURISTIC planning estimate, not a bid. Optional passive-vs-active comparison, with the ranking honestly flagged as riding on entered costs. AMD only.
DETERMINISTIC QUANTITIES ROUTED · COSTS ENTERED + UNCALIBRATED, NEVER FROM MEMORY · NO COST = INCOMPLETE, NOT FABRICATED · NPV DETERMINISTIC ON ENTERED RATE · PLANNING ESTIMATE, NOT A BID · AMD ONLYEngine 1 · Value · ESG / water-stewardship disclosure (all segments)
The fourth Stage-3 business-layer tool and the benchmark's #2-ranked next build: CSRD/ESRS E3 makes water withdrawal and discharge mandatory, and CDP Water and GRI 303 drive voluntary disclosure, but the disclosure-software field is filling with generalists that simply collect whatever number a user types. The differentiator here is physics-grounded honesty. The record names its framework and edition or it is INCOMPLETE (the same seam the compliance report uses). A datapoint the framework asks for that has no value is NOT_REPORTED — a listed gap, excluded, never a fabricated value or zero. The withdrawal / discharge / consumption volumes (GRI 303-3/4/5) are DERIVED deterministically from the platform's own water balance (blowdown = evaporation/(cycles-1); withdrawal = consumption + discharge) and tagged engine — hand-checkable, and RO consumption is left an honest gap because it depends on downstream use. The water-stress classification is ENTERED and sourced, never derived from memory (it needs external basin data such as WRI Aqueduct). Any monetary valuation uses an ENTERED, uncalibrated internal water price and is planning-only, with physical volume and monetary value kept apart. It is a disclosure-PREPARATION record, not an assured disclosure (CSRD requires third-party assurance). Neutral — all segments.
FRAMEWORK + EDITION OR INCOMPLETE · NO VALUE = NOT REPORTED, NEVER FABRICATED · 303 BALANCE DERIVED FROM THE ENGINE · WATER STRESS ENTERED + SOURCED, NEVER DERIVED · VALUATION ENTERED + UNCALIBRATED, PLANNING ONLY · PREPARATION RECORD, NOT ASSURED · ALL SEGMENTSEngine 1 · Value · RO cost of fouling (RO only)
The fifth Stage-3 business-layer tool and the benchmark's #3-ranked next build. Free membrane-design tools (DuPont WAVE, Hydranautics IMSDesign) stop at DESIGN, leaving the operational cost of fouling — widely cited near a quarter of RO OPEX — unserved by a vendor-neutral tool. This turns the D4516 fouling twin's deterministic drivers into a costed OPEX breakdown across four categories: accelerated membrane replacement, the energy penalty from the fouling pressure rise, extra CIP, and downtime. Every category is the INCREMENTAL cost of fouling vs clean operation — the difference from a baseline, not a gross cost. The physical drivers (flux/flow decline, pressure-drop rise, CIP interval, membrane life) are routed from the fouling twin or entered, each tagged with provenance, never fabricated. Unit costs are ENTERED and UNCALIBRATED (never from memory); a category with no unit cost, or no clean baseline, is INCOMPLETE — listed, excluded, never a fabricated default (the energy penalty is deterministic arithmetic: power = ΔP×flow/(36×eff), extra kWh at your entered price). Physical drivers and dollars are kept apart: the total is a heuristic planning estimate, not a bid. RO only.
DRIVERS ROUTED FROM THE FOULING TWIN, NEVER FABRICATED · COSTS ENTERED + UNCALIBRATED, NEVER FROM MEMORY · EVERY LINE INCREMENTAL VS A CLEAN BASELINE · NO COST OR NO BASELINE = INCOMPLETE, NOT FABRICATED · PLANNING ESTIMATE, NOT A BID · RO ONLYEngine 1 · Value · Boiler fuel savings (boiler only)
The sixth Stage-3 business-layer tool and the benchmark's #5-ranked next build. Boiler blowdown carries hot treated water out of the drum, so cycling up (reducing blowdown) saves fuel — the classic boiler energy case. The physics that is routed: blowdown = steam/(cycles-1), so the reduction from cycling up is deterministic (the same balance the boiler cycle twin uses) and is routed from the twin or entered, never fabricated. The one value that is entered, not fabricated: the blowdown heat content above makeup is ENTERED from steam tables for the drum pressure — there is no steam-table read in the platform, and a fabricated enthalpy would be exactly the kind of invented physical constant the platform forbids, so it is never supplied from memory. Boiler efficiency and fuel heating value are entered physical values; the fuel price is ENTERED and UNCALIBRATED, so the dollar figure is planning-only and the physical fuel saving stands without a price. The saving is INCREMENTAL (baseline → improved cycles); a line short a required value is INCOMPLETE — excluded, never fabricated. Physical and monetary confidence are kept apart: the total is a heuristic planning estimate, not a bid. Boiler only.
BLOWDOWN REDUCTION DETERMINISTIC, ROUTED FROM THE TWIN · HEAT CONTENT ENTERED FROM STEAM TABLES, NEVER FROM MEMORY · FUEL PRICE ENTERED + UNCALIBRATED, PLANNING ONLY · INCREMENTAL VS BASELINE CYCLES · MISSING VALUE = INCOMPLETE, NOT FABRICATED · BOILER ONLYEngine 1 · Value · Production at risk (sour only)
The seventh Stage-3 business-layer tool and the last of the benchmark-ranked value tools. In sour (O&G) service a souring or corrosion condition can force a choke-back or shut-in to stay inside a facility H2S-handling, metallurgy or HSE limit; the consequence is the production value at risk. The honesty seam — and it is deliberately conservative, because this is where the platform is most tightly gated: this tool does NOT forecast the risk. The souring and corrosion rates that would predict whether or when a constraint binds are UNCALIBRATED here (the sour progression twin is rate-gated), so the affected rate, the at-risk fraction (choke-back or shut-in) and the duration are ENTERED, never a fabricated trajectory — the tool quantifies the value of a scenario the operator specifies. Any constraint check is a deterministic comparison of an entered indicator (e.g. H2S) against an ENTERED limit — source-stamped, never supplied from memory — and only flags whether the premise holds, not a souring prediction. The price is ENTERED and UNCALIBRATED (planning only); a missing quantity or price is INCOMPLETE — excluded, never fabricated, and the physical volume at risk stands without a price. Physical and monetary confidence are kept apart: the value is a planning estimate, not a bid or a forecast. Sour only.
DOES NOT FORECAST THE RISK · RATE / FRACTION / DURATION ENTERED, RATES UNCALIBRATED, NEVER A FABRICATED TRAJECTORY · CONSTRAINT = ENTERED-VS-ENTERED-LIMIT, LIMIT NEVER FROM MEMORY · PRICE ENTERED + UNCALIBRATED · MISSING QUANTITY OR PRICE = INCOMPLETE, VOLUME STANDS · PLANNING ESTIMATE, NOT A BID OR FORECAST · SOUR ONLYEngine 1 · Prescribe · Control regime recommendation (cooling)
Per cooling-tower loop (acid, oxidiser, non-oxidiser, inhibitor), recommends a control mode + deadband + alarm/failsafe. The process gain is engine-computed — the oxidiser gain dHOCl%/dpH from the engine's own HOCl speciation (pKa), so the mode follows from physics, not assertion. Actuator class (relay vs analog) gates which modes are physically possible (no true PID / analog feed-forward offered to a relay); the dead-time/lag ratio selects within it (tight PID is refused when dead-time-dominated — it oscillates into its own alarms). Dead time, min-on-time and noise are entered; alarm/failsafe limits are the entered, edition-stamped surface (SI ceilings, HSG274, consents) — it computes WHERE a variable crosses them, never the limit. Failsafe is reasoned per loop: acid & non-ox FAIL-CLOSED, inhibitor FAIL-LAST-GOOD, and the oxidiser has NO safe default (failing off risks Legionella, failing on risks over-oxidation + consent) so it is NEVER auto-set — it crosses the human seam. The inhibitor dose target stays uncalibrated (dose-response gap). Design-time companion to the setpoint window and the runtime control decision. Cooling-only.
ENGINE-COMPUTED GAIN · SAFETY-GATED FAILSAFE (OXIDISER NEVER AUTO-SET) · COOLING-ONLYEngine 1 · Prescribe · Sensor drift & service scheduling (cooling)
Tells sensor DRIFT (recalibrate, do not act) from real SERVICE NEED (act on the water) — and never confuses them, because confusing them is the dangerous failure (dosing acid to “correct” a lying pH probe drives the water acidic). The confound breaker is the crux: a real process change moves MULTIPLE physically-correlated streams together (pH and ORP and calcite SI); instrument drift moves ONE. A stream that departs from what its partners predict is a sensor fault; a stream that moves with them is a real change — the tower's own coupled physics is the drift detector, no extra hardware. Drift per sensor is a least-squares slope of (reading − reference) with an R² noise guard (a noisy-but-stable probe is NOT called drifting); out-of-spec streams are suppressed from the correlations. Scheduling by time-to-limit, not calendar, against entered limits (never from memory); the water clock and instrument clock merge into one visit. It refuses to act on a drifting sensor, does not present LPR as pitting-aware (the coupon is truth), and keeps Legionella/consent across the human seam; low-confidence readings shorten, never lengthen, the interval. Time-series companion to the snapshot sensor cross-check. Cooling-only.
CONFOUND BREAKER (DRIFT vs PROCESS) · R² NOISE GUARD · LIMITS ENTERED · COOLING-ONLYEngine 1 · Prescribe · Cooling-tower dynamic twin (cooling)
The honest digital twin, split into two claims. Sim A (ships now) forward-integrates the transport mass balance — implicit backward Euler, unconditionally stable, tested to hit the analytic steady state exactly — with the reaction terms at zero, recomputing SI / HOCl% / HTI exactly from the engine at each state. It forecasts when the water crosses into supersaturation as cycles climb, without claiming a deposit mass. COC is an OUTPUT, integrated and reported (it sits below makeup÷blowdown because windage carries concentrate out) — never assumed. Sim B (rate, kg/day) is gated by the seam: the scenario emits a reaction rate ONLY where replay has calibrated that coefficient by closing the mass balance on the plant's own history (rate = residual, not a curve fit; CALIBRATED once ci ≤ 0.10). Until then the rate slot is UNCALIBRATED and empty — the twin never hides a guessed rate inside a differential equation. It refuses: no unlearned rate, no assumed COC, no corrosion or CFU curve from chemistry alone (corrosion is learned from the probe; Legionella is never predicted), and no forecast that authorises a consent/Legionella setpoint without the human seam. Cooling-only.
SIM A DRIVING-FORCE (EXACT) · SIM B RATE GATED ON REPLAY (SEAM) · COC IS OUTPUT · COOLING-ONLYEngine 1 · Sensors · Corrosion rate (coupon / LPR → mpy)
Turns a raw corrosion measurement into a banded rate. A coupon (weight loss over a known exposure, ASTM G1) gives the average rate; an LPR probe (polarisation resistance, Stern-Geary + ASTM G102) gives the instantaneous rate — both deterministic published arithmetic, not a fitted model. The verdict is metal-aware: the same mpy means different things for carbon steel and a yellow metal, so the band uses the metal's own acceptable range (NACE RP0775 for steel; the tighter cooling target for copper alloys), labelled. The Stern-Geary B is a labelled default (0.026 V) and overridable; metal density and equivalent weight are labelled library values. It reads a uniform average rate, never a pitting or localised rate, and corrosion consequence (a rate → remaining asset life) is not computed here — that stays the one fleet-calibrated layer, never faked. For cooling, boiler and sour systems, where coupon/LPR monitoring is standard practice.
VALIDATED · DETERMINISTIC · METAL-AWARE BAND · NO CONSEQUENCEIntelligence · Operating setpoints
The pH ceiling, conductivity ceiling and ORP target computed from this water, not a universal table. The pH ceiling is bisected against the engine at the operating cycles (a generic “up to 8.8” would scale a hard water); the conductivity ceiling is the cycle limit naming the limiting salt; the ORP target is residual-driven and moves with pH. The corrosion-side pH floor is a metallurgy default and is labelled a default, not dressed up as computed. Every setpoint states how it was derived.
VALIDATED · DETERMINISTICSegment moat · AMD neutralisation staircase
For acid-drainage water, the engine titrates pH across the neutralisation range and reports which metal precipitates at which pH — iron, then aluminium, then manganese — from the same WATEQ4F solubility products the segment read uses, so the windows inherit that validation. It surfaces the amphoteric-aluminium trap: aluminium re-dissolves if you over-lime past its peak, which is why chasing manganese at high pH can undo your aluminium removal. What it does not compute: recovery percentage, sludge volume and product purity — those need field calibration and are returned as explicit gaps, never numbers.
VALIDATED (WINDOWS) · RECOVERY UNCALIBRATEDSegment moat · CO₂ corrosion rate (sour)
The de Waard & Milliams (1975) correlation for the internal CO₂ corrosion rate of carbon steel, with pCO₂ taken from the water’s own carbonate system (the CO₂(g) partial pressure), not guessed. It reproduces the published worked point (0.5 bar, 60 °C → ~2.9 mm/yr) exactly and offers the inhibited rate as a lever. It does not cover H₂S / sulfide-stress corrosion — a separate mechanism, flagged never predicted — and above ~60 °C a protective FeCO₃ film can moderate the real rate, which is disclosed rather than silently scaled.
VALIDATED (PUBLISHED MODEL) · H₂S NOT COVEREDSegment moat · Silica carryover (boiler)
Estimates the silica that volatilises into the steam against the 0.02 ppm turbine limit, from boiler-water silica, pressure and pH — carryover rises with pressure and falls with boiler-water pH, matching the handbook pH-suppression (~0.74 at pH 11). This is a directional correlation: it is labelled an estimate to confirm against a steam sample, never a calibrated ppm to two decimals.
DIRECTIONAL ESTIMATE · NOT CALIBRATED PPMIntelligence · Segment-aware tools (binding · cost · setpoints)
The Diagnose/Prescribe tools now compute the right model per segment, not a cooling model on every water. Binding constraint names what actually binds — scale/CO₂ for sour, the neutralisation pH (with the amphoteric ceiling) for AMD, carryover for boiler. Programme cost for AMD is a lime-neutralisation model (kg CaO/m³ from free acidity + metal equivalents), not a cooling-inhibitor cost. Setpoints for AMD state a two-stage requirement when manganese needs a pH that re-dissolves aluminium, rather than a contradictory single setpoint. The stoichiometry is validated chemistry; the cost coefficients (reagent efficiency, unit costs) are uncalibrated and flagged as such — a water that cannot be solved returns an honest gap, never a 500.
STOICHIOMETRY VALIDATED · COST COEFFICIENTS UNCALIBRATEDIntelligence · Cost-coefficient calibration pipeline
The path by which the segment cost coefficients become trustworthy — honest by construction, and the same discipline that protects scale_score. Provenance is authoritative: a coefficient reaches CALIBRATED only on FIELD or LAB data with a tight interval. Synthetic data can exercise the pipeline but can never calibrate a coefficient — even a large, tight synthetic batch stays SYNTHETIC by construction, and the untrusted API clamps any field claim in a payload to synthetic. So the machinery is real and demonstrable today, while every cost coefficient remains uncalibrated until real data earns it.
PIPELINE READY · COEFFICIENTS UNCALIBRATEDPlatform · Observability & System Health
Every service is instrumented for support: a correlation id is minted at the gateway and propagated across all seven services, so one user request is traceable end-to-end; logs are structured JSON carrying that id — never a request body or PII; and each service exposes RED metrics (rate/errors/duration). A support-engineer System Health page — its own admin-only tab — shows per-service liveness, the RED summary, SQLite health (file & WAL size, a database-locked counter, WAL mode), and recent warnings/errors filterable by correlation id. It includes capacity forecasting that is honest about its own limits: growing resources (database, WAL, event table) get a forecast with a confidence band and a plain-language runway, but a flat or noisy series is refused with “insufficient signal” rather than a guessed line — and spiky metrics (latency, error rate) and discrete events (lock errors) are shown as current values and thresholds, never forecast. Instrumentation is observe-only: it never changes an endpoint's behaviour, and a failure in a log or metric call can never break a request. A ready-to-run self-hosted observability stack (Prometheus, Loki, Grafana, plus GlitchTip for error tracking) is provided as a deployment bundle for mesh-wide metric history, log search, and error grouping — it is correct-by-construction and runs on a Docker host (it is not part of the app itself). Error tracking is opt-in and gated (off unless a DSN is set) and never ships PII. What is not yet included: distributed tracing (Tempo) and shipped alerting rules — designed, named as gaps, not implied.
SHIPPED · TRACING / ALERT-RULES NET-NEWPlatform · Database durability (corruption, backup, restore, retention)
Three SQLite stores hold state — auth (users, audit, tokens), engagement (analytics, capacity samples), and the calibration moat (field points + coefficient posteriors); the chem/simulation services are stateless. Corruption avoidance: every store runs in WAL with synchronous=NORMAL and a busy_timeout (a power-loss can still drop only the last transaction — stated, not hidden). Detection: a quick_check / integrity_check probe surfaces a corrupt file on the System Health read and the ops CLI. Backup: the SQLite online-backup API takes a transactionally consistent snapshot of the live database (a plain file copy of a WAL db can be torn; this is not); every backup is verified (integrity + openable) and written with a manifest (sizes, sha256, per-table row counts), a bad backup is discarded not kept, and backup-retention keeps the newest N and never deletes the last good one. Restore verifies the backup first, refuses a corrupt one, snapshots the current file as *.pre-restore-* before overwriting, and clears stale -wal/-shm; it is a maintenance operation (stop the service, restore, start) — deliberately not a live endpoint, because a file cannot be safely hot-swapped under an open connection. Retention: high-churn operational tables are pruned by age (audit trail, analytics events, capacity samples, expired one-shot tokens), every window env-configurable; the calibration moat is NEVER pruned — it carries no retention policy by construction. Operability: a support-engineer Backups & retention panel on the System Health tab shows per-store integrity and last-backup status and runs a backup or a previewed prune on demand; an opt-in in-process scheduler (WAALGO_AUTO_BACKUP) runs both on a fixed interval. Restore stays CLI-only by design. Offsite replication now ships (WAALGO_OFFSITE_URL): after each backup the backup directory replicates to a second filesystem path (dir:// — only as offsite as the mount actually is; a second folder on the same disk is theatre) or to S3-compatible object storage (s3://), with every remote copy read back and sha-verified against its manifest. Replication is additive, never a mirror: an attacker who wipes the local backups cannot wipe the offsite copies through the next cycle, and the remote prunes only by its own, deeper retention count. Honest test scope: the dir:// path is proven end-to-end in the battery; the s3:// client is proven against a mock — the live-bucket round-trip is a deployment verification step, not implied as already done.
SHIPPED · LIBRARY + CLI + PANEL + SCHEDULER + OFFSITE · LIVE S3 BUCKET VERIFY AT DEPLOYConsole · Accessibility (automated WCAG floor)
The console passes an automated WCAG 2.1 AA audit (axe-core) with zero critical and zero serious violations — every view, at desktop and mobile widths, plus the sign-in screen. What that audit actually covered, in plain terms: every input and select now carries an accessible name (a screen reader hears “pH”, “Calcium”, “Currency” — tooltip prose is deliberately excluded from the name); text contrast was raised to the 4.5:1 floor where it fell short (muted labels, unit suffixes, status pills, N/A tags, slider values); and the main scroll region is keyboard-focusable. The floor is pinned: the audit runs in the test battery with a detector control (a deliberately injected defect must be flagged), so a regression — or a dead detector — fails the gate. Honest scope: this is an automated pass; it catches machine-detectable issues only. Manual screen-reader and keyboard-only walkthroughs have not been performed and remain the named gap — automated tools typically catch only a subset of WCAG criteria.
SHIPPED · AUTOMATED FLOOR · MANUAL AUDIT NET-NEWPlatform · Peak-load & capacity
The Admin console carries a peak-load & capacity metric for the surge question the growth forecast can't answer — alongside two headline counts: live users (distinct pseudonymous ids active in the last few minutes — no PII) and registered users (total accounts). The capacity metric answers: what binds first, and is every resource 30% clear of its observed peak. Over a trailing window it reports, per signal, the observed peak and when it happened; at the single busiest observed tick it correlates the load drivers with resource use to name the binding constraint (the resource highest against its ceiling); and it checks each ceilinged resource against a configurable headroom target (default 30% free above peak). Honest by construction: every utilisation is an observed sample over a real ceiling — host RAM/CPU/disk % from the host, database size against a configured soft limit — and the load drivers (active users, API calls/s, DB lock contention) get a peak but never a fabricated ceiling. Active users is counted from distinct pseudonymous ids with recent activity (there is no session table to inflate). Max concurrent is the one projected figure: a linear extrapolation from the busiest observed point to the binding ceiling, stamped ESTIMATE with its assumption stated (per-user footprint ~linear, current mix representative) — it is not a load-tested limit, and it returns “insufficient signal” rather than invent a number when the peak is too thin. A load-test harness now ships (loadtest/run_load.py): staged concurrency ramps against a live deployment measuring throughput, p50/p95 latency, error rate, and the scaling knee (rule stated in every report) — results are stamped this-host-only and are never auto-promoted into this capacity estimate; a production ceiling requires running the harness in situ. A reference run on the build host showed the expected single-worker behaviour: flat throughput with latency rising linearly in concurrency and zero errors under 16-way load — requests queue, they do not fail. The sampler is observe-only and the ingest is whitelisted (a caller cannot inject an arbitrary metric). Known limits: peaks are only as sharp as the sampling cadence — a surge between samples is missed, so the sample must be scheduled to catch real peaks; the host signals are the request-tier host's, correct for a single box — a multi-node deploy needs each node to sample itself with aggregation; and a true maximum comes from a load test, which this estimates toward but does not replace. Whether the fix is a load balancer (for a stateless CPU/RAM bottleneck) or a DB-writer change (the SQLite single-writer path a balancer cannot relieve) is read off the binding constraint, not assumed.
SHIPPED · SCHEDULED-SAMPLER / MULTI-NODE / LOAD-TEST NET-NEWPlatform · Per-user analytics & privacy
Usage is measured per user for product insight and, later, personalization — keyed on a pseudonymous id (the internal user id), never name or email in the event stream. The schema stores only the action (which tool, outcome, segment) — never the water chemistry or any request body, so minimization is enforced structurally, not by promise. It powers DAU/WAU/MAU, activation and feature-adoption metrics on an admin-only dashboard, and is fire-and-forget (a down analytics store never affects your call). Privacy controls are built in: a per-user data export (access right), hard erasure (deletion right), and a retention window after which raw events are pruned. This is first-party and internal only: usage is never sold, shared, or used for third-party advertising. What is deliberately not built yet: user-facing marketing/lifecycle emails and identified-user personalization — those need a consent/opt-out layer and legal review first, and are left as a clean seam.
SHIPPED · MARKETING / PERSONALIZATION GATED ON CONSENT + REVIEWPlatform · Tool-outcome analytics
Every intelligence call is classified into one outcome class — a normal result (ok), a case the tool does not apply to, an unsolvable input, a safety refusal, or an uncalibrated (banded) answer — and counted per tool. This rides the signals the engines already emit; it observes, it never changes a result. It is aggregate and observational: only the outcome class is stored, never water chemistry or user input, and it is fire-and-forget — if the analytics store is down, your call is unaffected. A rising edge-rate on a tool is a signal to investigate. What is not yet built: error tracking, database/mesh performance monitoring, and product usage analytics — named as gaps, not implied.
SHIPPED · ERRORS / DB-METRICS / USAGE NET-NEWPlatform · User management & access
Accounts are admin-provisioned, never self-signup. An admin creates a user with a role and either an invitation link (they set their own password — no secret is ever transmitted) or a temporary password (they are forced to change it on first sign-in). Passwords are Argon2id-hashed, never stored or logged in the clear; activation tokens are single-use, stored hashed, and expire in 48 hours. Roles form a ladder (viewer → technician → operator → engineer → admin), and every account action — logins, denials, provisioning, activation, password and role/status changes — is written to an append-only audit log. Password rules follow NIST SP 800-63B r4: length over complexity, no forced rotation. Safety-critical actions (autonomous actuation, marking a coefficient CALIBRATED) are gated by a maker-checker workflow: a proposer (operator+) and a distinct approver (engineer+), with a one-time approval token the action must carry — the deterministic safety floor in the engine still applies on top. Two-factor auth (TOTP) is supported at the API level and opt-in per user: once enrolled, a password alone yields only a short-lived challenge, and a valid authenticator code (or a single-use recovery code) is required to complete sign-in. The console enrollment/status screen is not yet built — enrolment today is via the API (/mfa/setup, /mfa/confirm, /mfa/disable), so a user cannot yet turn 2FA on from the console. Named as a gap, not implied as reachable. New passwords are screened: an always-on local check rejects short, trivial, context-matching, and commonly-compromised passwords (NIST SP 800-63B), with an optional Have I Been Pwned check (k-anonymity — only a 5-character hash prefix ever leaves the process) that can be enabled without weakening the local floor. Login attempts are rate-limited: after a few failed attempts, each further try on that account — and from that source IP — is slowed by an exponential backoff (the client gets a 429 with a Retry-After), which throttles password-guessing and spraying to a crawl. It is backoff, not lockout: there is deliberately no permanent lock (per NIST SP 800-63B, lockout is a denial-of-service vector — an attacker could lock a victim out), so a legitimate user's worst case is a short wait, never being shut out; a success clears the account counter. The default admin identity is admin@waalgo.com (override with WAALGO_ADMIN_EMAIL), which signs in with the master password (WAALGO_ADMIN_PASSWORD) until a real admin@waalgo.com account is provisioned, after which that account takes over. The master password follows the same secret ladder as the signing key: a default/placeholder is refused in production (WAALGO_REQUIRE_STRONG_SECRET=1 fails the boot closed, and the bootstrap login is refused as defence-in-depth), so there is no usable default admin in production — it works out of the box only in dev/test. The bootstrap admin (which has no account to lock) is covered per-IP, and the throttle is bounded — hammering while throttled cannot extend the wait. Every trip is audited. Requesting access: the sign-in screen carries a request-access form that stores each request durably and notifies the team by email (SMTP, env-configured; default recipient help@waalgo.com), and the form also offers a direct mailto to help@waalgo.com when SMTP is not set up. The honesty of that channel is explicit: when SMTP is not configured, no send is pretended — the request still lands in the admin console's Access-requests panel with its mail status stated per request. The form is rate-limited per source IP (its own limiter, independent of the login backoff) and enumeration-safe: the response is identical whether the address is new, already pending, or already an account, so the public form reveals nothing about who has access. Signing-secret strength: at start-up each edge service assesses the JWT secret — empty, a well-known placeholder, or under the 32-byte RFC 7518 minimum is flagged. In production (WAALGO_REQUIRE_STRONG_SECRET=1) a weak secret fails the boot closed rather than run with forgeable tokens; in dev it warns and continues. Sessions have a fixed lifetime (the sign-in token expires after a configured absolute TTL, default one hour) and an idle auto-logout: after a configurable window of no interaction (default 15 min) the console shows a countdown warning, then drops the local session and returns to login — protecting an unattended browser. This is a client-side hygiene layer, not server-side revocation: the token is a stateless JWT, so it stays valid until its absolute TTL — a copied token is only truly revoked by that expiry (a shorter TTL or a token denylist would be the next step, named here honestly). What is not yet built: the in-console MFA enrollment/status screen (TOTP works via the API today), SSO/SCIM, hardware/WebAuthn factors, and server-side token revocation — named as gaps, not implied. Terms & Conditions acceptance is required on first sign-in: until the current terms version is accepted the app is not granted, and every acceptance is written to an append-only record (email, version, UTC timestamp, source IP) for audit and legal, exportable by an admin. Enforcement is the sign-in gate plus that authoritative record — the JWT is still issued at login, so this is a UI gate backed by a durable server-side record, not a per-request server block (that would be the next step, named here honestly).
SHIPPED · IDLE-LOGOUT · T&C-GATE · MFA (TOTP) API-ONLY · ENROLL-UI / SSO / WEBAUTHN / TOKEN-REVOCATION NET-NEWPlatform · Program entitlement (feature visibility)
An admin can enable or disable any tab, offer or tool from the Program tab. Everything is enabled by default; a disabled node is hidden from every non-admin — the sidebar tab button, the offer, the Home tile and the tool tile simply do not render for them, and showView refuses a disabled tab or the Program tab itself for a non-admin (defense in depth against a stale URL hash). Admins always see everything, with a disabled node marked off. The state is persisted server-side (a disable-list, empty by default) and only an admin can change it — the toggle route is admin-gated, an unknown node id is rejected so a stale client can never persist a phantom flag, and a test pins the backend node set to the client's tool tree so the two never drift. Scope, stated honestly: this is a UI-visibility entitlement — a disabled node is hidden from non-admin UIs; hard API-level access control on the underlying tool endpoints (refusing a disabled tool's endpoint to a non-admin who calls it directly) is a separate, disclosed follow-up, not implied here.
SHIPPED · ADMIN-ONLY · DEFAULT-ON · UI VISIBILITY (API GATING = DISCLOSED FOLLOW-UP)Platform · Training tab
A guided, plain-language tool directory written for a newcomer. Every tool expands to a friendly explanation of what it does, one worked example (the inputs, the readings, the verdict and what you'd do next), the full list of cases it's good for, and its honest boundary — plus an Open button that sets the right segment and jumps you to the tool. It is reference only — it makes no engine calls, runs no model and shows no computed numbers of its own; the example figures are quoted from the standalone training guide (which carries five worked examples per tool). It is a normal program node (an admin can disable it) and, like every tab, its client entry is pinned to the backend node set by a test, with a further test pinning that every tool keeps its example, case-list and boundary so it can't quietly decay into a thin list. Because it neither models nor asserts a result, there is nothing here to calibrate or to be wrong about.
SHIPPED · REFERENCE · NO MODELLINGPlatform · Segment focus & scope
On first sign-in a user chooses the water-treatment segments they work with (cooling, RO, oil & gas / sour, mining / acid drainage, boiler); thereafter the console shows only those segments — the Home picker, the Scale & Corrosion mode buttons, and the “My water” segment tabs render just the chosen set, and the active segment is kept in scope. The choice is editable any time in Settings and persists per user (in the same server-side prefs blob as units and currency); at least one segment always stays on. Scope, stated honestly: this is a per-user view filter, not an engine change — hiding a segment does not disable it in the chemistry, and the per-tool × per-segment applicability that governs whether a tool actually works for a segment is unchanged and remains the source of truth. An anonymous session (the shared-password bootstrap admin, which has no stable id) is not onboarded and simply sees everything, since it cannot persist a choice. Admin governance (shipped): an admin sets platform-wide availability (a segment turned off is unavailable to everyone) and a per-user grant (which segments a person may access); the effective set a user sees is their focus, within the grant the admin gave them, within what the platform offers. Platform and grant changes are written to the audit log; a grant rides the user's token (applied on next sign-in) and platform availability is fetched at sign-in, with a min-one floor on each layer. Honest boundary, unchanged: this whole three-layer scope is a UI/access view filter — it governs what a user is shown and can select, not what the engine computes; the per-tool × per-segment applicability remains the source of truth.
SHIPPED · PER-USER FOCUS + ADMIN PLATFORM / GRANT · UI/ACCESS FILTER (ENGINE UNCHANGED)Platform · Units & currency preferences
Every quantity on the platform can be shown in your preferred unit, SI or Imperial, per dimension, with the choice living in Settings. Volume (m³ / gal) and mass (kg / lb) drive the cost, water-balance and ROI inputs; the detailed per-segment engineering tools (boiler, RO array, AMD, twin, sour) keep their flows in m³ / m³·h⁻¹ — disclosed here, not implied as converted. Currency is selectable ($, ₹, €, £). The default is SI everywhere and USD. The critical property: switching a unit or currency never changes a calculated result, and this is now enforced exactly — every unit-dependent input carries its canonical SI value, preserved byte-for-byte across any number of toggles (the engine reads that, never the rounded on-screen figure), so a volume→price round-trip cannot introduce even a fractional-percent drift. A volume divides by the factor, a price-per-unit multiplies by it, so the engine only ever sees m³/kg; and currency is symbol-only with no exchange rate (prices are used exactly as typed — we hold no FX and will not invent one). Switching converts the on-screen values, not just the labels, so a number is never silently mislabelled. Ion concentrations stay mg/L in both systems by industry convention — a fixed choice, disclosed, not an omission. The preference is persisted per user (the uid is taken from the authenticated token, so you only ever see your own), and a demo/shared-password session keeps it in-browser only. What is not yet wired: temperature (°C only for now — it is affine and read across many tool engines) and pressure (kept per-tool, as some tools already read bar and others psig) — both are named here as the next step, not implied as available, precisely because a mislabelled temperature is the exact failure this platform exists to prevent.
SHIPPED · VOLUME / MASS / CURRENCY WIRED · DEFAULT SI + USD · ENGINE ALWAYS SI (NO CALC IMPACT) · TEMP / PRESSURE NEXTPlatform · Pin to report (curated report builder)
Every tool result carries a Pin to report control at its top-right. Pin results as you work — across Diagnose, Prescribe, Operate, Learn and Value — and they collect in an ordered queue in the Report tab, where you can reorder, remove, or start fresh, then preview and download a branded PDF. Each pinned result is a snapshot of what the tool showed at pin time, and it carries its water, segment and input parameters alongside the result, so every section is self-contained; the renderer prints that snapshot, it does not re-compute or invent a number. If nothing is pinned, the report falls back to the default sections for the selected segment, so it is always useful. Each user keeps one working report: it is saved to their account (the uid is taken from the authenticated token, so a user only ever sees their own) and comes back on next sign-in; Start fresh requires a two-click confirm because it deletes that saved report. A demo/shared-password session has no account id, so its report stays in-browser only — disclosed, not a silent failure. Pinned and stored content is sanitised and size-capped server-side so a report can never crash or bloat on odd input.
SHIPPED · ONE SAVED REPORT / USER (PERSISTED) · WATER + INPUTS PER PIN · DEFAULT-WHEN-EMPTY · SNAPSHOTIntelligence · Unified twin
One traced pass — identify, recommend, control, observe — where every output is a single Recommendation carrying what, the proposal, why, its provenance, its confidence and its safety class. Three rules are enforced in code, not documented: an output with no provenance does not render; a human-only safety item (oxidant/biocide) is never automatable; an uncalibrated value is shown as a range, never a point. Confidence comes from instrument agreement, never asserted. Autonomous actuation is permitted only against a simulator or test target — on a plant it is refused and downgraded to advisory. Human-in-the-loop is the default and the only mode that reaches real hardware. Segment-aware: for cooling/RO the twin runs the cycles spine; for sour, acid-drainage and boiler it runs a segment spine composed only from the validated segment reads (segment chemistry, segment binding, segment setpoints), and the closed-loop control/observe stages — a cooling-tower dynamic model — are honestly gated as advisory for those segments rather than emitting a cooling action on a non-cooling water. No cooling framing (cycles, cu-steel yellow-metal) appears in a segment answer, and no segment trajectory is fabricated.
VALIDATED · DETERMINISTIC · SEGMENT-AWAREWhat each number is worthread this before you trust a result
| Output | Basis | Status |
|---|---|---|
| Saturation index | PHREEQC / Davies on published constants. Reproduces published solubilities it was never fitted to — gypsum, barite, celestite and amorphous silica all land inside 0.07 SI (worst case celestite, 0.069). This is the number to trust. | VALIDATED |
| LSI · RSI · PSI | Standard empirical formulae, calibrated for low-TDS water. We have not benchmarked these values against published worked examples — what we test is the guard that suppresses them above ~4000 mg/L TDS, outside which they mislead. Read them as the industry conventions they are, not as our result. The saturation index is the number to trust. | UNBENCHMARKED |
| Stiff & Davis · S&DSI | The high-salinity analogue of LSI (ASTM D4582), reported where LSI is suppressed above 4000 mg/L TDS — brine, seawater, RO concentrate. K is computed from PHREEQC’s activity coefficients, not read off the published chart: the chart was an approximation of exactly that, and digitising a 1952 nomograph would be guessing at a regulated number with no way to test it. The identity pH − pHs ≡ SI(calcite) closes to 0.000, because they are the same quantity — Stiff & Davis is LSI with a better K. So this adds no accuracy over the calcite SI already shown; it adds the form the industry reports in, valid where LSI is not. | VALIDATED |
| Fast engine | Davies reads high versus ion association — conservative, increasingly so as ionic strength rises. The Rigorous engine hands off to Pitzer the moment its Davies-computed I crosses 0.5 (Pitzer then reports a higher I on the same water, typically ~0.75); Davies is never carried above its own 0.5 convention ceiling, so it does not degrade silently into brine. Use Rigorous for brine and seawater. | BENCHMARKED |
| RO wall SI | Concentration polarisation applied (β, default 1.15). Scale forms at the membrane wall, not in the bulk. | MODELLED |
| Corrosion axis | Adsorption-centre proxy (N/S/aromatic). Real, but not fitted to any inhibition data. | UNCALIBRATED |
| Scale axis | Ca-binding density proxy. Also unfitted. It ranks threshold inhibitors only — molecules that poison crystal growth sub-stoichiometrically at 2–10 ppm. Neither axis sets dose. No wet-lab dose-response data exists behind it. | UNCALIBRATED |
| Calcium phosphate · hydroxyapatite | Reported whenever you enter a PO₄ residual. On a real phosphate programme (Ca 300, PO₄ 6 mg/L, pH 7.8) apatite reaches SI +8.2 against calcite’s +1.1 — the mild-steel inhibitor creates the most supersaturated phase in the tower, and the AA/AMPS dispersant is what holds it in suspension. Flagged kinetically slow: it forms through amorphous precursors over days, so a high SI means your dispersant is doing its job, not that scale is forming now. The thermodynamics is PHREEQC; the rate, and therefore the dispersant dose, is not modelled. | THERMO ONLY |
| Passivating inhibitors | Ortho- and pyrophosphate work by forming an iron-phosphate film, not by adsorbing a lone pair — which is all the corrosion axis measures. They therefore carry no score at all. A 0.0 would call the primary mild-steel inhibitor useless: the chelant error inverted. Pyrophosphate additionally hydrolyses back to orthophosphate in service, faster hot, so a pyro programme becomes an ortho programme and the phosphate risk rises with it — that reversion is disclosed, not modelled. | DISCLOSED |
| Halogen speciation | Acid-base equilibrium, exact. HOCl pKa temperature-corrected from Morris (1966) — reproduces 7.54 at 25 °C. HOBr uses 8.70 at 25 °C with no temperature correction: its T-dependence is not as well established, and inventing one would be worse than disclosing the basis. Only the undissociated acid is a strong biocide, which is why at pH 8.3 bromine is ~5.6× more active than chlorine. | VALIDATED |
| Halogen residual · demand | Predicted from measured demand and bulk decay (Standard Methods 2350) plus exact dilution. Without those constants we refuse and name the test — a default would reproduce the very failure this fixes and look authoritative doing it. The finding: on a fouled tower dilution is ~1% of the halogen loss, so holding time alone overstated the residual by roughly 80×, in the direction that says the biocide is still there when it is gone. This is what separates halogen control from scale dose-response: the constants are an afternoon’s bench work, not a year of field trials. | VALIDATED (CALIBRATED) |
| Dose for residual | Prescriptive, and defensible for a precise reason: the target comes from your own water management programme or HSG274 — never from us — and demand and decay come from a bench test, not a guess. The forward and inverse models are pinned to round-trip against each other. Dose-for-RESIDUAL only. Never dose-for-kill: that needs an efficacy constant which does not exist for biofilm organisms. | VALIDATED |
| Bio-dispersant slug window | How long blowdown must be suspended to hold a slug above its threshold for the contact time — exact dilution arithmetic, and the operational instruction nobody computes. Evaporation is ignored deliberately: it removes water and would concentrate the slug, so ignoring it errs conservative. This is the dosing, not the effect — a bio-dispersant is a penetrant with no concentration-versus-kill relationship, and whether the biofilm lifts is not modelled. | EXACT |
| Phosphorus ledger | The same conservative-tracer balance as the cycles balance, applied to phosphorus. Total P short of the tracer means it is depositing; ortho P above what you dosed means the oxidiser is destroying your phosphonate. Both at once means your oxidiser is manufacturing your scale. Every input is a routine test (Cl, total P, ortho P). Assumes steady dosing and a conservative tracer — heavy bleach dosing reduces to chloride and inflates the tracer, which is disclosed. A 5% band is treated as noise because no noise floor has been established against field data. | UNBENCHMARKED |
| Holding time index | Standard cooling-water arithmetic from the same mass balance the rest of Engine 1 uses: blowdown = evaporation/(cycles−1) − windage. It is a CEILING on contact time, never the contact time — an oxidiser is also lost to demand, sunlight and your own inhibitors, all faster than dilution. A non-oxidiser is not consumed by demand, so dilution is close to its whole loss path and HTI is close to real for it. | EXACT (a ceiling) |
| ASHRAE 188 register | Verification only. ASHRAE 188 separates verification (are we doing what we said?) from validation (is it working?). This register does the first. The bridge that makes it defensible: HSG274 names scale and deposit control AS a Legionella control measure, and that is precisely what Engine 1 computes — so we evaluate a measure the standard names against chemistry we compute exactly. The CFU action levels are deliberately NOT keyed in: guessing at a regulated figure is fabricating it, the same rule that stopped us digitising the Stiff & Davis nomograph. | VERIFICATION ONLY |
| Legionella prediction | Not attempted, and it will not be. Legionella lives in biofilm and inside amoebae, not in the bulk water this product models. Bulk free halogen → CFU has no validated mechanistic model; the literature is epidemiological association. ASHRAE 188, HSG274 and WHO are risk-management frameworks by deliberate choice. The failure is also asymmetric: a wrong saturation index costs money, while a false negative here gives someone a defensible-looking reason not to sample. | REFUSED |
| Mechanism separation | A chelant (citric acid, gluconate) sequesters calcium stoichiometrically — mol‑for‑mol, hundreds of ppm — and is not an antiscalant at antiscalant doses. It binds calcium well and so scores well on binding density, which is why it is ranked on its own axis and never against a threshold inhibitor. Ranked together, citric acid (59.5) outranked polyacrylic acid (47.6), which would be a two-order-of-magnitude dosing error. | ENFORCED |
| Cycle limit · limiting salt | Bisection on the same PHREEQC saturation the rest of Engine 1 uses. The thermodynamics is validated; the practical SI ceilings it bisects against (calcite +2.5 on antiscalant, gypsum 0.0) are industry convention, not measurements — vendor-dependent and unfitted. Kinetically inhibited phases are excluded, or dolomite would limit every water. | MIXED |
| Sensitivity | Each input perturbed, the limiting phase re-solved. Deterministic arithmetic on a validated engine — it inherits the SI's accuracy exactly and adds no assumption of its own. | VALIDATED |
| Cycles balance · deposition rate | Mass balance against a conservative tracer (Cl, EC). The arithmetic is exact and the method is standard practice, but it assumes stable makeup, that nothing else removes the ion, and honest sampling — real towers break all three. No noise floor has been established against field data, so a small shortfall is not yet distinguishable from analytical scatter. The one output here that is a rate, not a tendency. | UNBENCHMARKED |
| Program cost | Water and blowdown are arithmetic; acid is stoichiometric and ignores corrosion risk. The antiscalant line assumes a 5 ppm dose that nothing in this product justifies — thermodynamics does not set a dose. Its ranking is indicative only, and it is labelled LOW in the panel. | PART ILLUSTRATIVE |
SI is a tendency, not a rate. Every saturation index here says whether scale can form, never how fast. Nucleation, induction time and crystal growth kinetics are not modelled — a water at SI +1 may scale in an hour or not at all in a year. Nothing on this page tells you a rate.
Why we tell you this. Saturation thermodynamics is published science — anyone can reproduce it, and we do not pretend otherwise. What is hard, and what we are building, is empirically calibrated dose-response from real plants. Until that data exists the screening scores rank candidates; they do not predict performance. A tool that hid that distinction would be easier to sell and worth less to you.
What we won't fakethe limits we state on purpose, so a number never overreaches
- Polymers are scored per repeat unit, using attachment points rather than an arbitrary chain length, so the score no longer moves with how many units you happen to draw. They are now rankable against each other — but the axis is still uncalibrated, and a real antiscalant's performance also depends on molecular weight and distribution, which a repeat unit cannot express. Draw your own polymer with end caps and the old dilution effect returns; use
[*]attachment points. - The practical SI limits are borrowed, not measured. The Intelligence tab’s cycle limit bisects against ceilings that are industry rules of thumb (calcite +2.5 on antiscalant). They are uncalibrated and vendor-dependent. Today this shows: sepiolite currently limits ordinary municipal water at about 3 cycles, while real plants run 5–6 — so either that ceiling is wrong or sepiolite is kinetically slow like dolomite. We do not have the data to say which. Field dose-response data is exactly what replaces these numbers.
- Kinetics are not modelled anywhere. Every index is a tendency. Talc and chrysotile are deliberately not reported even though they are supersaturated in ordinary cooling water — they cannot form at these temperatures, and a permanent alarm on a phase that never appears teaches you to ignore the panel. Dolomite is reported but is famously slow to nucleate; treat it as a long-term indicator, not a today problem.
- A treatment programme is not modelled — only its molecules are. A real cooling programme couples a mild-steel passivator, a yellow-metal azole, a scale inhibitor, a dispersant polymer and two biocides, and the interactions dominate: chlorine degrades tolyltriazole; an oxidiser degrades phosphonates to orthophosphate, which raises the calcium-phosphate risk the dispersant then has to absorb. The couplings are now named on the Microbial control tab, but none of them are given a rate — that would need kinetic constants that do not exist. Biocides are absent entirely and deliberately — nothing in a saturation model speaks to microbiology, and scoring them would invent a third meaningless axis.
- Copolymer composition is inexpressible. An AA/AMPS dispersant is defined by its molecular weight and its sulfonation level, which set its calcium tolerance. We score the AMPS comonomer alone, so neither is expressible — the same limit as the repeat-unit scoring above.
- No dose recommendation. Nothing here tells you how much inhibitor to feed.
- A visible gap is a feature, not a failure. Where PHREEQC will not converge — at absurd concentration, or a charge balance too broken to speciate — the point appears as a gap in the chart, never as a plausible wrong number. The engine refusing to answer is the most important thing it does; a model that always returns a number is the one to distrust.
Send a query
Questions about Waalgo, the models, or a pilot? Leave a note and it goes straight to the team's inbox.
Query inbox
Loading…