02_PRODUCT — the product that Dense-Armor can sell¶
The market question¶
How does a small manufacturer with a robot cell tell the difference between a real failure and a false alarm, in a system whose "normal" behaviour keeps changing, without hiring the engineer who knows how to tune thresholds?
Why this question, and not "build a detector"¶
1709.04749 (Giardino, Wang, Abrahamsson 2014), page 1: the failure of
early-stage software startups is traced to the gap between the strategy, which
reveals the need to understand the problem/solution fit first, and the
execution, which "prioritize[s] the development of the product to launch on
the market as quickly as possible to verify product/market fit, neglecting the
necessary learning process." The paper's own second step (page 4) is: "build
the right product features that solve real customers' needs, also known as the
product/market fit. If the product/market fit is not achieved, then a
problem/solution fit must be reiterated, operation known as pivoting."
The lesson is not "build faster". It is: state the demand first, build the
thing that answers it second. This document is the first half. The second
half is 03_NEXT_ISTRUZIONI.md, the task that builds the first vertical.
2210.05192 (Ros, Bjarnason, Runeson 2022), page 1, gives the three factors
that decide whether continuous experimentation works at all: "1) processes and
infrastructure for CE, 2) the user problem complexity of the product offering,
and 3) incentive structures for CE." The same paper (page 17, proposition P4)
adds a warning: "high problem complexity limits experimentation impact."
This is why the first vertical is chosen for low integration complexity, not
for market size.
The product¶
A streaming condition-monitoring and diagnostics engine, sold as a
per-asset licence to integrators who resell it to small manufacturers
with robot cells. The engine turns a raw stream into a
structured fault: a severity (debounced through EventMetrics.threshold_window,
which exists today), a per-fault event metric (precision, recall, delay, false
alarms per hour, through EventMetrics), and, once task Y01 is built, a state
machine (PREFAILED, CONFIRMED, CLEARED) and a freeze-frame of the sensors
at the moment of the fault. The state machine and the freeze-frame are not in
Dense-Armor today: they are the code that task Y01 writes. It is not another
dashboard. The dashboard is the integrator's job; the engine is ours.
2610.14823 (Britto, Ericsson 2026), page 1, frames the same shift from the
buyer's side: "The vision covers sensing, exploration, decision-making,
realization, and learning." An engine that only produces a score covers
"sensing". A buyer pays for the rest.
The vertical: industrial robots¶
The product is specified for one vertical only: industrial robots with a
system integrator between us and the small manufacturer. The other verticals
that Dense-Armor could serve (drones, finance, LLM agents) are left out of
this delivery because their evidence rows do not support the claim. They are
not declared as options: a claim that is not in evidence.csv is not in the
document.
| Vertical | Buyer | Evidence |
|---|---|---|
| Industrial robots | system integrators (Intech, Energy Robotics through Smart NDT) | E10, E11, E12, E13 |
The vertical is industrial robots for three reasons documented in
evidence.csv:
- The reseller channel exists (E10, E11). Energy Robotics sells its inspection platform through Smart NDT in Italy (E10); this proves the reseller channel exists, not that demand for this engine exists. Intech Automazione already installs vibration and temperature sensors and IO-Link modules to sell predictive maintenance (E11), the closest match to the engine's use.
- The integrator's economics reward a recurring line (E12, E13). White-label robotics platforms list "recurring SaaS revenue from platform licenses" as a distinct line (E12) and pay distributors a share of every software subscription (E13).
- The alternative vendors are already priced for SMEs (E03, E05): RoboVigil at 150 GBP per machine per month (E03, vendor page), and Viking Analytics at 30-100 USD per monitored asset per month (E05, aggregator estimate, not the vendor's own page). The range is corroborated, not the exact price of one vendor; the question is whether our engine is worth the same range.
Which Dense-Armor classes do the work¶
Every class named here was checked with grep -rn "class <Name>" dense_armor/
before this line was written.
| Class | Path | Role in the product |
|---|---|---|
CUSUMDriftDetector |
dense_armor/utility/drift/detector.py |
drift on the scalar channels; the trigger that task Y01 wraps in its state machine |
ADWIN |
dense_armor/utility/drift/adwin.py |
second opinion on the same channel; false-alarm control |
HalfSpaceTrees |
dense_armor/utility/anomaly/hst.py |
unsupervised score on the joint vector, no labels needed |
OnlineRobustMahalanobis |
dense_armor/utility/anomaly/mahalanobis.py |
multivariate check that survives outliers |
EventMetrics |
dense_armor/utility/metrics/events.py |
per-fault precision, recall, delay, false alarms per hour |
RealtimePipeline |
dense_armor/roles/realtime.py |
the budget: a per-sample p99, not an average |
profile |
dense_armor/roles/realtime.py |
measures the p99 on the buyer's machine |
check_p99_within_budget |
dense_armor/checks/robot.py |
the check that the integrator can run before selling |
Protected |
dense_armor/roles/protection.py |
skip learning on a flagged sample, so one fault does not poison the model |
The first five are the core. The last four are the budget and the protection around them.
The arithmetic to 500 EUR gross per month¶
Inputs, each a row of evidence.csv or a declared assumption.
| Input | Value | Source |
|---|---|---|
| Price per asset per month | 50 USD | assumption, inside the 30-100 USD range of E05 |
| Assets per integrator | 20 | assumption, 5 clients x 4 robots |
| Share kept by the integrator | 50% | assumption, from the white-label model in E12 and E13 |
| USD to EUR | 0.92 | assumption, no source in evidence.csv |
| Hosting, support, tax | 30-40% of gross | assumption, no source in evidence.csv |
Calculation with one integrator:
50 USD x 20 assets x 0.50 x 0.92 = 460 EUR per month
460 EUR gross is below 500. The sentence "one integrator is enough for 500 EUR gross" is false with these inputs. Two routes reach 500 EUR gross, before the 30-40% of hosting, support and tax:
2 integrators: 2 x 460 = 920 EUR per month
1 integrator at 55 USD per asset: 55 x 20 x 0.50 x 0.92 = 506 EUR per month
The first route is the one the delivery assumes: two integrators, 40 assets across 10 SME clients. The second route is a price change of 10% and needs a buyer who accepts 55 USD per asset per month, inside the E05 range.
The arithmetic is small on purpose, but it is an arithmetic, not a promise.
The 500 EUR target is net; the arithmetic above is gross, and the
hosting, support and tax line is an assumption, not a measured cost. At 30% of
gross, two integrators at 920 EUR gross give about 640 EUR net, above the 500
target; at 40% of gross, the same 920 EUR give about 550 EUR net, still above.
No cost has a row in evidence.csv, and the delivery states this.
1912.12371 (Ye et al. 2019), page 5, describes the subscription shape:
"The user subscription model (also discussed in Chang et al. 11) relies on a
subscription for a set period of time." The subscription is the base; the
consulting, page 13, is the first invoice. Neither is revenue until one
integrator signs.
Why a buyer pays, when a free alternative exists¶
River (E08) is free and does online machine learning. PyOD (E09) is free
and does anomaly detection. The question is which part of the product the free
libraries do not cover, and that part must be code that exists today, not code
that task Y01 will write.
What exists today in Dense-Armor, and the free libraries do not have.
RealtimePipeline(dense_armor/roles/realtime.py),profile(same file),check_p99_within_budget(dense_armor/checks/robot.py): a per-sample p99 budget, measured and checked before the engine is sold. River and PyOD do not ship a latency budget.EventMetrics(dense_armor/utility/metrics/events.py), with thethreshold_windowargument: two alarms insidethreshold_windowseconds are the same detection. This is a debounce on the alarm stream, and it exists.Protected(dense_armor/roles/protection.py): skip the learning step on a flagged sample, so one fault does not poison the model.
What does not exist yet, and task Y01 writes.
- The state machine
PREFAILED,CONFIRMED,CLEARED: zero occurrences indense_armor/today. Item A of03_NEXT_ISTRUZIONI.mdwrites it. - The freeze-frame of the sensors at the moment of a fault: zero occurrences
today. Item B of
03_NEXT_ISTRUZIONI.mdwrites it.
The reason a buyer pays, today, is the budget and the event metric: the two pieces the integrator cannot get from River or PyOD, and the two pieces that decide whether the engine fits a control loop. The state machine and the freeze-frame are the reason the buyer renews after Y01 is built, not the reason the buyer signs before it.
2601.15494 (Koren, Bekes, Hinz, Lohmann 2026), page 1: "When OSS is monetized
only through direct user engagement, greater adoption of vibe coding lowers
entry and sharing, reduces the availability and quality of OSS, and reduces
welfare despite higher productivity." The free library is free because it is
not asked to be a product. The product is the part that a maintainer is paid to
keep working, plus the part that Y01 has not written yet, and that the delivery
states it has not written yet.
What the next task builds¶
03_NEXT_ISTRUZIONI.md is the task file for the first vertical: the robot one.
It lists the files, the checks, the sources and the delivery in the shape of
02_TASK_TEMPLATE.md. The engine is the same as the other three verticals, but
the first build is the one whose channel is already mapped in E10 and E11.
The paper that gives the build its shape is 2506.16334 (Wu, Wang 2025),
page 1: "LSM complements discovery-oriented AI by utilizing AI to expand the
search for market opportunities and employing prototyping to validate these
opportunities, thereby reducing uncertainties." Discovery (this document) and
prototyping (the next task) are two halves of the same loop, not two phases.
References¶
- Giardino, C., Wang, X., Abrahamsson, P. (2014). Why Early-Stage Software Startups Fail: A Behavioral Framework. ICSOB 2014, pp. 27-41. Page 1 (problem/solution fit before product/market fit); page 4 (pivoting).
- Kula, R. G., Reid, B., Treude, C. (2025). Open Source at a Crossroads: The Future of Licensing Driven by Monetization. arXiv:2503.02817. Page 3 (MySQL dual licence); page 5 (Elasticsearch, SSPL).
- Ye, Y., Boyce, R. D., Davis, M. K., et al. (2019). Open Source Software Sustainability Models. NCI ITCR SIP-WG white paper. Page 5 (user subscription and freemium models); page 13 (Axiomedix Expert Network, contract and consulting).
- Ros, R., Bjarnason, E., Runeson, P. (2022). A Theory of Factors Affecting Continuous Experimentation (FACE). arXiv:2210.05192. Page 1 (the three factors); page 17 (proposition P4, high problem complexity).
- Azarang, R., Azarang Esfandiari, M. R. (2026). Strategic Technical Debt: A Real Options Approach to Early-Stage Software Experimentation. arXiv:2608.16112. Page 1 (high hypothesis uncertainty, cheap experiments, freedom to abandon).
- Wu, L., Wang, X. (2025). Artificial Intelligence, Lean Startup Method, and Product Innovations. arXiv:2506.16334. Page 1 (discovery-oriented AI and prototyping).
- Koren, M., Bekes, G., Hinz, J., Lohmann, A. (2026). Vibe Coding Kills Open Source. arXiv:2601.15494. Page 1 (direct user engagement and the erosion of the OSS revenue base).
- Britto, R. (2026). AI-Native Product Management: A Vision. arXiv:2610.14823. Page 1 (sensing, exploration, decision-making, realization, learning).