SENSORIUM is a local-first field instrument for designing defensible sensing systems from the physical phenomenon through installed validation, deployment, review, and evidence.
Its central question is:
Can the complete sensing system reliably distinguish the physical states the project needs to tell apart?
SENSORIUM preserves facts, measurements, calculations, assumptions, recommendations, unknowns, confounders, stale evidence, and accepted limitations. It does not compress engineering judgment into a single observability score.
- Download
sensorium-v3.0.html. - Open it in a current desktop browser.
- No server, account, installation, or internet connection is required.
- Projects and the reusable engineering library save locally in the browser.
- Export project JSON and library JSON for portable backup.
The application does not transmit project information.
v3.0 adds five connected design workspaces to the complete v2.9 workflow:
What-if Analysis → Architecture Comparison → Observability Map → Measurement Argument → Engineering Libraries
These additions make it possible to explore alternatives without overwriting the working design, compare complete sensing architectures, see shared system weaknesses, state the technical measurement argument, and reuse evidence-backed local engineering records.
The core engineering thread remains:
Phenomenon → Sensor → Placement → Interface → Calibrate → Validate
SENSORIUM extends that thread through:
Analytics → What-if → Multi-sensor → Architectures → Logging → Deployment → Review → Observability → Observability Map → Measurement Argument → Evidence Package
A persistent Requirement Thread keeps one measurement objective in context across the technical workspaces. Upstream changes mark affected downstream evidence stale instead of silently treating old conclusions as current.
Shows Requirement Thread coverage, current observability, stale downstream stages, next actions, templates, operational readiness, what-if records, architecture decisions, map findings, measurement arguments, and reusable library records.
Defines stable requirement IDs, physical quantities, units, ranges, normal and target states, thresholds, sensitivity, timing, environment, interfering conditions, evidence basis, and the supported decision.
Compares candidates requirement by requirement. Every suitability result includes its reasons. Roles include primary, reference, redundant, comparison, candidate, and rejected.
Provides image-backed sensor markers, orientation and sensitive-axis arrows, cable paths, scale metadata, placement templates, and installed-location checks.
Combines physical placement, signal chain, power, grounding, calibration setup, and validation setup in one editable, layer-based diagram workspace.
Builds the signal chain and checks compatibility, power headroom, ADC span and quantization, sampling, filtering, latency, throughput, storage, shielding, grounding, bus conflicts, and termination.
Manages calibration plans, named runs, repeated observations, increasing and decreasing sequences, CSV mapping, regression, residuals, R², RMSE, repeatability, hysteresis, and correction preview.
Maintains requirement-specific and shared contributors, distributions, divisors, sensitivity coefficients, expanded uncertainty, threshold comparison, and guard bands. Unknown values remain visible and outside the numeric combination.
Stores installed-system procedures and individual trials for range, thresholds, response time, repeatability, false positives, false negatives, interference, power interruption, communications loss, disconnection, and reference comparison.
Imports time-series CSV evidence and calculates baseline statistics, noise, drift, gaps, threshold crossings, condition separation, and reference RMSE.
Creates non-destructive alternatives for:
- Sensor and placement
- Sampling rate and filtering
- ADC resolution
- Cable length
- Uncertainty multiplier
- Decision threshold
- Interface latency
- Reference channel
Each scenario exposes blocking findings, cautions, strengths, signal-to-uncertainty separation, ADC counts, timing margin, and preserved tradeoffs. Up to four scenarios can be compared side by side. A reviewed scenario can be applied explicitly to the working design, which records downstream change impact.
Defines redundant, differential, reference-compensated, voting, complementary-modality, and derived architectures with explicit channels, roles, weights, decision rules, fallback behavior, common-cause risks, and validation plans.
Compares complete sensing-system options rather than isolated sensor specifications. Each option can link:
- A requirement
- A what-if scenario
- A multi-sensor architecture
- A sampling and logging plan
- Cost, power, complexity, maintainability, and replaceability assumptions
- Strengths, limitations, and retained rationale
The architecture decision record preserves the preferred option, constraints, reviewer, status, and rejected alternatives.
Defines acquisition rate, channel count, packet overhead, throughput, buffering, storage, retention, timestamps, synchronization, missing-data handling, offline recovery, file schema, and quality flags.
Carries the design into installed-asset, commissioning, calibration-due, inspection, service, repair, replacement, and decommissioning records.
Supports structured engineering review with questions, concerns, requested evidence, requested changes, approval conditions, responses, resolution status, snapshots, and revision comparison.
Evaluates every focused requirement across sensor fit, state separation, placement, confounders, interface, sampling, uncertainty, calibration, validation, reference channels, and change impact.
Classifications are:
- Clearly observable
- Observable with validation
- Marginally observable
- Confounded
- Not observable
- Insufficient information
Every result includes plain-language reasoning, evidence gaps, assumptions, and corrective actions.
Shows observability as a requirement-by-factor matrix. The map supports classification and hotspot filters, CSV and SVG exports, factor summaries, shared dependencies, and common-cause findings. It is a navigation and review instrument, not a combined score.
Builds an editable nine-part technical argument:
- Required distinction
- Physical phenomenon
- Sensor response
- Placement effects
- Signal acquisition
- Calibration establishes meaning
- Remaining uncertainty
- Validation demonstrates performance
- Limitations and unresolved evidence
Arguments retain explicit assumptions, conclusion, author, reviewer, date, and status. They can be refreshed from current evidence, duplicated, exported as text or standalone HTML, and included in the evidence package.
Maintains reusable local records for:
- Sensors
- Interface components
- Reference standards
- Uncertainty templates
- Validation procedures
- Placement patterns
- Known confounders
Records preserve source, evidence, usage notes, and structured reusable data. Library records can be captured from a project, applied to the focused requirement, exported, and imported. Reuse never bypasses project checks.
Builds a selectable 22-section package including scenarios, architecture comparison, observability map, and measurement arguments alongside the full design, calibration, uncertainty, validation, deployment, review, traceability, history, and evidence index.
Exports include standalone HTML, evidence JSON, project JSON, CSV appendices, browser Print / Save PDF, and diagram SVGs.
Easy Mode asks for the intended measurement or detection, expected span, supported decision, environment, controller or logger, timing, power, and reference access. It creates a linked starter architecture with visible recommendations and assumptions. Moving into Advanced Mode retains all data.
SENSORIUM includes:
- Automatic local saving with visible status
- Recovery snapshots
- Versioned project schema migration
- Import validation and repair reporting
- Project integrity checks
- Active-project and all-project JSON backup
- Duplicate, archive, rename, and delete controls
- Clear Sample Data
- Start Fresh
- Clean New Project behavior
- Separate portable engineering-library backup
New Project and Start Fresh create a genuinely clean active workflow.
sensorium-v3.0.html— complete standalone applicationREADME.md— operating guideCHANGELOG.md— v3.0 release recordDATA-SCHEMA.md— schema 7 documentationKEYBOARD-SHORTCUTS.md— controls and navigationTEST-NOTES.md— release validation recordSAMPLE-MEASUREMENT.csv— import-ready sample dataENGINEERING-LIBRARY-SAMPLE.json— portable starter libraryQA-v3-overview.png— overview screenshotQA-v3-scenarios.png— what-if screenshotQA-v3-observability-map.png— observability-map screenshot
The embedded Motor Bearing Temperature and Vibration Monitoring project demonstrates:
- Temperature and vibration requirements
- Primary and reference sensors
- Placement tradeoffs and confounding airflow
- Signal-chain and sampling checks
- Calibration observations
- Unknown and numeric uncertainty contributors
- Installed-system validation and false-positive evidence
- Time-series measurement analytics
- Multi-sensor architecture
- Logging, deployment, and review records
- Three what-if scenarios
- Three competing complete architectures
- A proposed architecture decision
- Requirement-level observability mapping
- A generated measurement argument
The sample intentionally includes unresolved and confounded conditions so the application demonstrates engineering judgment rather than a falsely complete design.
SENSORIUM calculations and generated findings support engineering work; they do not certify a real installation. Review exact component datasheets, applicable standards, calibration traceability, safety requirements, environmental conditions, and measured evidence before relying on a design.