The Dashboard That Almost Lied: Building Trustworthy Repair Intelligence
Punarnava turns everyday appliance repairs into privacy-aware insights for more durable products. Using synthetic repair data, we discovered why raw repair counts can mislead—and built a local-first AWS Build It workflow around explainable analytics, brand-scoped access, and circular repair.
The Dashboard That Almost Lied: Building Trustworthy Repair Intelligence
Part 4 of 4 · Punarnava · Environmental Hacks / AWS Build It
A manufacturer dashboard can be technically correct and still tell the wrong story.
Imagine grouping every repair by brand and sorting the totals. In our synthetic dataset, Kestrel appears to have the most repairs: 1,599, compared with 904 and 752 for two other fictional brands. It looks like Kestrel has the biggest reliability problem.
But we deliberately designed Kestrel to be the most reliable brand per unit. It simply has the largest installed base in our synthetic market.
Nothing was wrong with the query. The interpretation was wrong.
That discovery shaped the final part of Punarnava: a repair workflow that creates useful records for technicians and product owners, while turning consented, anonymised repair activity into evidence manufacturers can use to improve product durability.
The principle: repair counts tell us what reaches a repair shop—not, by themselves, how reliable a product is.
Punarnava in 90 seconds
Across India, local technicians keep appliances working long after warranties expire. Yet the repair journey is often fragmented: owners may receive one quote without a clear comparison, usable parts can be discarded with a broken appliance, and manufacturers lose visibility into failures that happen outside their service networks.
Punarnava connects the people and decisions around a repair.
- Technicians can record the appliance, failed component, suspected cause, evidence and quote in a structured job record.
- Product owners can compare practical outcomes—repair with a new part, repair with a reused part, sell, harvest usable components, or recycle—without needing to install a dedicated app.
- Parts and recycling partners can help keep usable components in circulation and route end-of-life material responsibly.
- Brand and product teams can study anonymised failure patterns by model, component, age band and operating condition.
The data is not the product's only purpose. It is a useful by-product of making repair decisions clearer and easier to record.
Diagram 1: How Punarnava Works
Why we used synthetic data
We did not have a real manufacturer partner or a production dataset of independent repairs. Rather than fill a dashboard with random-looking numbers, we created a reproducible synthetic dataset and planted patterns whose answers we already knew. That let us test whether the analysis could find a signal, miss a signal, or create a misleading conclusion.
The dataset generator included 3,255 synthetic repair jobs across four product categories, three fictional brands and eight fictional towns. It planted five patterns:
Pattern | What we planted | What it tests |
|---|---|---|
P1 | A fan capacitor fails more often at 9–15 months | Age-related reliability |
P2 | A water-purifier inlet valve fails more often in hard-water towns | Environmental conditions |
P3 | A mixer motor coupler has a sharp six-week failure spike | A possible bad production batch |
P4 | A washing-machine control board fails more often in unstable-voltage towns | Electrical conditions |
P5 | A low-volume drain-pump model has a smaller, shorter rise | Whether subtle signals are detectable |
These are simulated patterns, not claims about real brands or real products. Their value is that the experiment is repeatable: we know what was planted, and can compare the system's output with that ground truth.
Diagram 2: Why Raw Counts Lie
The chart we chose not to ship
The first view a team might build is simple: count repairs by brand. But repair shops see products that break; they do not see the full population of products that keep working.
In our generated market, Kestrel represents 60% of units and is the most reliable per unit. Orbit represents 15% and is the least reliable per unit. As a result, Kestrel has the largest raw repair count even though the simulated per-unit rates tell a different story.
In a real deployment, the denominator—the number of units of a model in use—is rarely available to an independent repair network. Warranty length, regional market share, product age and customer behaviour can all affect what arrives at a shop. A raw count cannot separate those effects from product quality.
We therefore made three product decisions:
- No cross-brand leaderboard. An analyst should not be encouraged to interpret raw counts as a reliability ranking.
- Compare a component with its own history. A sudden change in failures for one model and component can be useful even when the installed base is unknown.
- Show sample sizes and uncertainty. Every percentage needs its supporting count. Small slices should be suppressed or clearly marked as too small to interpret.
The point is not that comparisons are impossible. It is that comparisons need the right denominator, context and access controls.
What the dashboard asks instead
Rather than ranking brands, the dashboard is designed around questions an engineering team can act on:
- Which components appear most often in repairs for this model?
- At what product age do those repairs occur?
- Are failures concentrated in a particular region or operating condition?
- Has this component changed meaningfully compared with its own recent history?
- How much evidence supports the displayed percentage?
In the synthetic experiment, the planted age pattern made 78% of the relevant Orbit FAN-2 capacitor repairs fall between 9 and 15 months, compared with 11% for the corresponding Kestrel fan component. That contrast is a useful test case for an engineering investigation—not proof that any real-world product has the same behaviour.
The unstable-voltage pattern was less decisive: its simulated share was 39% against 30% in the comparison group. That is exactly why the dashboard should show the sample size beside the percentage rather than presenting a neat-looking chart as certainty.
Diagram 3: Compare a Part With Its Own History
Detecting a spike without pretending every alert is a discovery
For the synthetic dataset, we evaluated a straightforward baseline before reaching for a more complex model. For each model/component series, it looks at the previous eight weeks, calculates an average, and flags a week when its count exceeds that average by a chosen number of standard deviations. A Poisson approximation uses the square root of the average as the standard deviation.
At a threshold of three standard deviations, the baseline caught the deliberately planted large spike in its first week, missed the smaller low-volume rise, and generated 24 false alerts across 2,112 weekly checks. Lowering the threshold to two standard deviations caught the smaller rise, but produced 111 false alerts.
That trade-off matters. An alerting system that constantly interrupts an analyst will eventually be ignored. A missed subtle signal matters too, especially when it may indicate a low-volume model with a real reliability issue.
The lesson from this test is not that a simple baseline is universally best. It is that anomaly detection should be evaluated against known cases, false positives and operational cost—not just a model name. More advanced detection can be added when it demonstrates a measurable improvement on representative data.
Privacy is part of the architecture
Repair records can contain personal information: names, phone numbers, addresses, photos, exact quotes and details about a technician's business. A manufacturer generally does not need those fields to investigate a recurring component failure.
Punarnava's analytics design separates operational records from aggregate insights. The intended flow removes direct identifiers and detailed evidence before contributing a repair to grouped statistics such as model, component, town, month and age band. Small groups are suppressed so a narrow slice does not reveal a single person's repair.
We also treat access control as a server-side rule, not merely a hidden menu. Cedar policies express who can read which resource. A brand analyst should be restricted to their own brand's eligible aggregates and should never be allowed to read individual repair jobs.
Illustrative policy intent:
cedar
permit (principal in Punarnava::Role::"BrandAnalyst",action == Punarnava::Action::"ReadFailureAggregate",resource is Punarnava::FailureAggregate)when {resource.brand == principal.brand &&resource.repairCount >= 5};forbid (principal in Punarnava::Role::"BrandAnalyst",action == Punarnava::Action::"ReadRepairJob",resource);
This policy snippet communicates the access boundary; it should be aligned with the exact entity and action definitions in the deployed policy schema. Minimum group size should also be checked when data is queried, because filters can turn a large aggregate into a small slice. Even then, differencing attacks can sometimes infer suppressed values from multiple allowed totals. Stronger privacy techniques, such as carefully calibrated noise, remain an area for future work.
Diagram 4: Who Sees What
Building with the AWS Build It stack
We approached the build with a local-first workflow so core behaviour could be developed and demonstrated without requiring every contributor to have a fully provisioned cloud environment.
- AWS SAM CLI provides the infrastructure-as-code and local Lambda development workflow.
- LocalStack gives the team local AWS-service emulation for repeatable development and integration tests.
- Strands Agents SDK with a local LLM supports the AI-assisted workflow while keeping experimentation accessible during development.
- OpenSearch supports search and matching experiences, such as finding relevant parts or related repair knowledge.
- Cedar makes authorization rules explicit, reviewable and testable.
The key design separation is between the operational repair flow and the analytics path. A repair should still be recordable and actionable if a dashboard calculation is slow or unavailable. Search, AI assistance and aggregate analysis should support the workflow rather than become a single point of failure.
The included architecture diagram captures the intended system boundaries. Before publishing, confirm that the diagram matches the exact services and integrations present in the final repository; local emulation is not the same thing as a production deployment on AWS.
Diagram 5: Punarnava Architecture on AWS
What we learned
A correct query can still create a false story. Counts need context, and a dashboard should not encourage conclusions its data cannot support.
Synthetic data is most useful when it has ground truth. Planting specific failure patterns gave us a way to test detection and document both misses and false alarms.
Privacy must survive filtering. Removing names from a dataset is not enough if a user can narrow an aggregate until only one repair remains.
The baseline is part of the product. Explainable detection gives a useful benchmark for evaluating more sophisticated approaches, and false alerts are a product cost—not just a model metric.
Circular repair needs a record of the outcome. Reuse, parts harvesting and responsible recycling become more actionable when decisions are documented as part of the repair lifecycle.
What we will validate next
The next meaningful test is not a larger synthetic chart. It is a carefully scoped pilot with real technicians and explicit consent, so we can learn whether the job-card workflow fits a busy repair shop and whether the resulting data is complete enough to support useful analysis.
Before making reliability claims, we also need manufacturer-provided installed-base data or another defensible denominator. Until then, Punarnava can surface patterns worth investigating; it cannot prove that one brand is more reliable than another.
Our goal is to help repair become easier to choose, easier to document and easier to learn from—so that more products stay useful for longer, and fewer usable parts become waste.
A question for builders
If your dashboard showed a strong pattern but you knew the data could not support the conclusion people would draw from it, would you remove the chart—or keep it with a warning?
For Punarnava, we removed the ranking. Trust was worth more than one more chart.
Punarnava was developed for the AWS Build It / Environmental Hacks journey. The failure patterns and numerical results described above come from a synthetic dataset, not real customer repairs or verified manufacturer failure rates. Update the project links, team credits and implementation details before publishing.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article