Evidence Twin
An industrial cooling investigator that knows when its evidence is insufficient
The problem worth solving
Service engineers must reconcile sensor streams, component relationships, maintenance notes, and the age of each observation before deciding what to investigate. A fluent summary can sound convincing while mixing a pump reading from yesterday with a temperature excursion from today. Build an investigation assistant for a fictional industrial cooling loop. It proposes supported engineering hypotheses and the next useful observation. The project uses synthetic telemetry and read-only tools; it does not control equipment, prescribe physical repairs, or claim to reproduce a commercial system.
What could make it stand out
The portfolio contribution is an auditable bridge between a small physical simulator, a typed component graph, and selective agent answers. Every proposed explanation must point to sensor observations, timestamps, units, and graph paths. The assistant can request a disambiguating measurement or abstain when competing explanations remain plausible. The distinctive experiment measures whether semantic and physical consistency checks improve the risk-versus-coverage tradeoff under sensor faults. This is a proposed combination to evaluate, not a claim of worldwide novelty; sensor ontologies and cooling simulation already have substantial related work.
On held-out synthetic cooling scenarios, a planner using typed evidence constraints plus a heat-balance residual will reduce unsupported explanation rate by at least 30% relative to a text-RAG agent at matched answer coverage of 70%, while identifying the generator's fault family within the first three investigation steps on at least 75% of identifiable cases. Reject this hypothesis if the improvement disappears after matching observation budgets or holding out simulator parameter regimes.
System architecture
| Component | Responsibility |
|---|---|
| Cooling scenario generator | Simulate heat input, water flow, inlet and outlet temperatures, gradual restrictions, load changes, and biased or missing sensors. Keep latent fault labels in an evaluator-only file that the agent cannot retrieve. |
| Typed evidence graph | Represent CoolingLoop, Pump, HeatExchanger, Sensor, Observation, and ServiceNote nodes. Enforce observable-property and unit constraints, and store both observation time and ingestion time for every measurement. |
| Investigation planner | Choose a bounded read-only action: inspect a time window, retrieve a note, compare related sensors, or request a simulated fresh sample. Maintain explicit candidate explanations and unresolved evidence requirements. |
| Evidence and physics gate | Check units, component identity, freshness, independent corroboration, and the residual of a deliberately simplified heat balance. Return supported, contested, or insufficient evidence with machine-readable reasons. |
| Trace reviewer | Show the user a component graph, aligned telemetry, cited observations, rejected evidence, and the effect of the next measurement. Export a replay manifest with scenario seed and configuration hashes. |
Data and reproducibility
Author 300 synthetic episodes across four fault families plus normal operation, with approximately 30 minutes of one-second observations per episode. Include service-note templates written for this fictional system. The linked ontology and cooling documentation inform representation and simulation technique; they provide no equipment-specific dataset or calibration.
Start with a synthetic benchmark
Generate normal, reduced-flow, excess-heat, and sensor-bias trajectories using documented toy equations and seeded perturbations. Cross these with missing intervals, incorrect units, ingestion delay, and contradictory duplicate sensors. Split by physical parameter ranges and fault combinations, not just random rows, so nearly identical trajectories cannot enter both development and test sets. Mark episodes where available observations cannot distinguish two latent causes; correct behavior there is abstention or a measurement request.
Baselines you must beat
- Threshold rules over temperature and flow, with the same observation budget and an explicit unknown state.
- Text RAG over flattened telemetry summaries and notes, using the same language model and token budget as the proposed planner.
- Typed evidence retrieval without the physical residual, isolating whether the simulator adds value beyond cleaner metadata.
Measure the claim
Targets below are proposed success criteria. No results have been achieved on your behalf.
| Metric | Definition and target |
|---|---|
| Unsupported explanation rate | The fraction of answered episodes whose explanation lacks required evidence or contradicts the evaluator's available observations; report a risk-coverage curve rather than rewarding blanket abstention. Target, not achieved result: at least 30% relative reduction versus text RAG at matched 70% coverage, with a paired episode bootstrap interval. |
| Investigation success at three reads | Among episodes labeled identifiable under the allowed tools, the fraction where the correct synthetic fault family is retained and supported within three observation actions. Target, not achieved result: at least 75%; report each fault family separately and list ambiguous cases outside this denominator. |
| Evidence validity | Fraction of cited observations with correct component, property, unit, time interval, and retrievable source identifier; calculate this independently of prose quality. Target, not achieved result: at least 98% valid citations on a frozen test set, with no unsupported real-device claims. |
Experiments and ablations
- Run paired evaluations on identical episodes while removing the ontology gate, physical residual, and abstention policy one at a time. Keep retrieval size and model configuration fixed so gains cannot be attributed to larger contexts.
- Sweep missingness from 0% to 40% and observation delays across the freshness threshold. Plot coverage and unsupported explanations together; inspect whether the planner becomes appropriately uncertain as evidence degrades.
- Hold out simultaneous load increase and sensor bias until final testing. Compare the next-measurement policy with a fixed checklist and a random read policy, measuring evidence gained per tool call.
Your execution plan
0 of 12 deliverables checked. Tick a deliverable after recording evidence in your project repository.
Define the fictional plant and evaluation contract
Build the simulator and evidence store
Establish comparable baselines
Add selective investigation
Test the research claim
Package a defensible portfolio release
Working seed
Run this small, deterministic core first. It demonstrates the central mechanism. The complete system, experiments, and deployment are your capstone work.
"""Evidence Twin: a synthetic cooling-loop evidence gate, not a device model."""
from dataclasses import dataclass, replace
import json
@dataclass(frozen=True)
class Observation:
id: str
component: str
property: str
value: float
unit: str
minute: int
ONTOLOGY = {
"flow": ("cooling_loop", "kg/s"),
"inlet": ("cooling_loop", "degC"),
"outlet": ("cooling_loop", "degC"),
"heat": ("cooling_loop", "kW"),
}
def simulate(flow, heat=10.0, minute=100):
# Water heat capacity is an illustrative constant; no equipment-specific calibration.
values = {"flow": flow, "inlet": 18.0,
"outlet": 18.0 + heat / (4.18 * flow), "heat": heat}
return [Observation(k, "cooling_loop", k, v, ONTOLOGY[k][1], minute)
for k, v in values.items()]
def investigate(observations, now=100):
grouped = {}
for o in observations:
if (o.component, o.unit) != ONTOLOGY.get(o.property):
return {"status": "abstain", "reason": "ontology_or_unit_error"}
if not 0 <= now - o.minute <= 5:
return {"status": "abstain", "reason": "stale_or_future_evidence"}
grouped.setdefault(o.property, []).append(o)
if set(grouped) != set(ONTOLOGY):
return {"status": "abstain", "reason": "missing_property"}
if any(max(o.value for o in group) - min(o.value for o in group) > 0.1
for group in grouped.values()):
return {"status": "abstain", "reason": "contradictory_evidence"}
v = {k: group[0].value for k, group in grouped.items()}
if v["flow"] <= 0:
return {"status": "abstain", "reason": "invalid_flow"}
residual = abs(v["heat"] - 4.18 * v["flow"] * (v["outlet"] - v["inlet"]))
if residual > 0.5:
return {"status": "abstain", "reason": "energy_balance_mismatch"}
candidate = "low_flow_investigation" if v["flow"] < 0.5 else "no_simulated_alert"
return {"status": candidate, "residual_kW": round(residual, 6),
"evidence": sorted(o.id for o in observations)}
def main():
normal = simulate(1.0)
restricted = simulate(0.25)
stale = [replace(o, minute=90) for o in restricted]
conflicting = restricted + [replace(restricted[0], id="flow_backup", value=0.8)]
outputs = [investigate(x) for x in (normal, restricted, stale, conflicting)]
assert [x["status"] for x in outputs] == [
"no_simulated_alert", "low_flow_investigation", "abstain", "abstain"]
assert investigate([replace(normal[0], unit="litres/min")] + normal[1:])["status"] == "abstain"
print(json.dumps(outputs, sort_keys=True, indent=2))
if __name__ == "__main__":
main()
Failure modes to investigate
- Toy physics may make the task artificially easy. Hold out parameter regimes, include unmodeled disturbances, and describe the residual as a consistency signal rather than proof of a physical cause.
- Latent fault labels can leak through note templates or file names. Randomize surface wording and audit every tool-visible field before evaluating explanation quality.
- A convincing simulator can imply more validity than its evidence supports. Label all assets fictional and keep the assistant limited to simulated engineering investigation with no equipment control or servicing instructions.
Your demo, moment by moment
- Open a fictional cooling-loop episode with a rising outlet temperature. Ask what the evidence supports and show the component and observation identifiers behind the first candidate.
- Introduce a stale flow sensor and a contradictory fresh backup reading. The assistant retracts its confident answer and names the missing evidence instead of inventing a cause.
- Request one permitted fresh observation. Reveal how the candidate set changes and show the energy-balance residual alongside its simplifying assumptions.
- Finish with the frozen risk-coverage comparison and one failure case, explaining what the measured improvement can and cannot establish.
Write the resume bullet after the experiment
Replace every placeholder with your actual measurements. Keep the dataset size, baseline, and evaluation conditions available for interview questions.
A research extension
After the six-week study, ask a domain expert to review the fictional ontology and ambiguity labels. If legitimately available equipment data later becomes authorized, begin with retrospective read-only validation and distribution-shift analysis. A valuable research extension is active sensing: compare expected information gain with fixed investigation checklists while charging each simulated measurement an explicit latency cost.
Related work to challenge your idea
Provides established vocabulary for sensors and observations. The proposed work specializes a small subset for a fictional cooling loop and tests its effect on agent abstention.
Shows established cooling-system simulation examples. The capstone uses simpler documented equations and must not present building chiller models as validated equipment physics.