
V0.1 Prototype
The smallest real Kore we can build.
One room, five components, one working loop. This is the V0.1 spec: what would be built, how it would be tested, what it cannot claim, and what it would cost. Concept stage; nothing here is assembled.
Pre-prototype · every visual is concept imagery
Selected components · Concept stage
The V0.1 hardware list.
The smallest feasible one-room prototype: an ESP32 hub, four sensing components, and a phone dashboard as the display. Every component below is selected, not purchased. There is no assembled hardware.
| Component | Role in V0.1 | Status |
|---|---|---|
| ESP32 dev boardHub and local compute | Runs the sensor polling loop, compares readings against thresholds and a room baseline, and dispatches alerts. All processing is planned to happen on the device first. | Selected · concept |
| BME280Environmental sensor | Temperature, humidity, and pressure. The baseline environmental channel for the room. | Selected · concept |
| SGP30Air quality sensor | Volatile organic compounds (VOC) and equivalent CO2 for indoor air quality tracking. | Selected · concept |
| PIR motion sensorMotion events | Passive infrared motion events: someone entered, someone is moving, the room went still. | Selected · concept |
| ESP32 camera moduleVisual documentation | Captures stills or short clips on event triggers for the documented safety record. This is the ultra-surveillance configuration; the module can be omitted in the camera-free configuration for schools, churches, and senior living. | Selected · concept |
Processing architecture · Planned
Local first, human last.
The V0.1 loop is designed to run on the ESP32 in the room, show up on a phone dashboard, and wait for a person to decide. Nothing in this architecture is built.
Sense Planned
The selected sensors read the room on a fixed polling cadence: temperature, humidity, pressure, VOC/air quality, motion, and camera frames on event.
Compare Planned
The ESP32 compares each reading against fixed thresholds and a learned room baseline. An event is raised when a hard threshold trips or when the reading departs from the baseline in a sustained way.
Act Planned
The hub dispatches an alert to the phone dashboard (concept UI) and writes the event to the local record with a timestamp.
Verify Planned
After an alert, the system keeps sensing and checks whether the signal changed, so the record shows what was sensed, what was done, and whether it worked.
Record Planned
Every event, reading series, and alert is written to local storage first. The documented record is the point: unmatched safety and documentation.
Phone dashboard Concept UI
The planned interface for the V0.1 prototype: current readings, event history, and alert controls on a phone. It is a concept interface. No app is written.
Connectivity: WiFi Planned
The hub connects over WiFi to reach the phone dashboard and to sync records. Core monitoring is planned to keep working locally even if the network drops; no cloud dependency is planned for basic sensing and alerting.
Data handling: local-first Planned
Readings, events, and footage are planned to be processed and stored on the local device first. Cloud sync, if any, is a later roadmap question, not a V0.1 feature.
Kore Intelligence layer Concept
The software layer (Sense, Learn, Detect, Connect, Protect, Insight) is a concept. V0.1 plans only the polling loop, threshold and baseline comparison, and alert dispatch described below.
Planned software · Not written
Three small programs, clearly scoped.
The V0.1 software plan is deliberately narrow. Each piece below is planned and described; none of it is written, and no code has been tested on hardware.
Sensor polling loop Planned
Reads each sensor on a fixed cadence, timestamps the readings, and keeps the latest values in memory. Handles sensor warm-up, missed reads, and out-of-range values by flagging rather than guessing.
Threshold and baseline event detection Planned
Compares readings against fixed safety thresholds and a rolling room baseline. An event fires on a hard threshold breach, or on a sustained departure from baseline. Detection rules are designed to be inspectable, so a person can see why an event fired.
Alert dispatch Planned
Sends triggered events to the phone dashboard, writes them to the local record, and keeps sensing afterward to verify whether the signal changed. No automatic calls to emergency services are planned; a person decides what happens next.
Testing methodology · All tests planned, none performed
Bench tests with written acceptance criteria.
Before any real-room trial, the V0.1 prototype must pass bench tests with explicit pass/fail criteria. Every test below is planned. No tests have been run, because no prototype exists.
| Bench test | Acceptance criterion (planned) | Status |
|---|---|---|
| BME280 accuracy | Readings stay within the sensor's published datasheet tolerance across a room-temperature sweep. | Planned |
| SGP30 air response | Stable baseline over a 24-hour soak, with a measurable response to a controlled VOC source. | Planned |
| PIR motion range | Reliable trigger at the 3 m test distance, and no trigger during an empty-room soak test. | Planned |
| Camera module capture | Stores a retrievable still on each event trigger, and the footage is viewable on the local device. | Planned |
| Alert latency | Planned target: the alert fires within 10 seconds of a threshold breach. | Planned |
| End-to-end loop | Sense, compare, act, verify, record completes on the bench without manual intervention, and the local record is complete. | Planned |
Known limitations, stated plainly
- No fall-detection claims. V0.1 does not include fall detection. Any future fall work would need its own dedicated validation before a single claim is made.
- No medical claims. Environmental sensing is not medical monitoring. It supplements, never replaces, professional care.
- WiFi presence sensing is experimental research. Through-space presence via WiFi Channel State Information follows published research (Carnegie Mellon's 2023 "DensePose From WiFi"). It is not selected for V0.1 and is not a validated feature.
- Camera analytics are not validated. Planned footage is documentation, not verified detection. No claim is made about what the camera can recognize.
- Not a replacement for certified alarms. Until a prototype is built, tested, and validated, Kore does not replace certified smoke alarms, carbon-monoxide alarms, or emergency services. See the privacy and safety page.
Phased roadmap · No dates promised
Five phases, in order.
Each phase gates the next. No phase is given a date, because dates are commitments and the work has not started.
Design and feasibility
Component selection, this spec, and the bench test plan.
Current
Prototype assembly
Build the one-room unit from the selected components.
Planned
Bench testing
Run every acceptance criterion above and record the results.
Planned
Controlled validation
Real-room trials with documented conditions and honest failure logs.
Planned
Limited pilot
A small pilot program, only after the prototype proves itself.
Planned
V0.1 budget · One verified figure, the rest estimates
What the $30,000 campaign funds.
The crowdfunding goal is $30,000, and it funds V0.1: parts, assembly, and the first working loop. The only verified figure in this table is the written build quote; every other line is an estimate with its basis stated. Figures are in USD.
| Budget line | Amount | Basis |
|---|---|---|
| Engineering and buildAssemble and integrate the V0.1 prototype | ~$18,000 Verified quote | Written quote from Sheldon Hurst, October 2026 (build labor; components excluded). Awaiting reply; not a contract. |
| Prototype componentsESP32 dev board, BME280, SGP30, PIR, camera module, power, cabling | $400 – $800 Estimate | Basis: typical retail pricing for ESP32 dev boards and sensor modules at single-unit quantities for a one-room bench build. Not quoted. |
| Electronics and fabricationCustom boards, wiring, small-run assembly | $300 – $600 Estimate | Basis: one-off PCB fabrication and hand assembly at small quantities. Not quoted. |
| Testing and validationBench equipment, calibration references, test time | $500 – $1,000 Estimate | Basis: bench equipment access and calibration reference instruments via maker space or rental. Not quoted. |
| Enclosures and assemblyHousings, mounts, finishing | $200 – $500 Estimate | Basis: 3D-printed or off-the-shelf enclosures plus mounting hardware at prototype quantities. Not quoted. |
| Contingency (15%)Standard prototype reserve | $200 – $450 Estimate | Basis: 15% of the estimated non-quote lines, standard practice for hardware prototype planning. Not quoted. |
| Planning range (excludes fees and shipping) | ~$19,600 – ~$21,350 | Estimate. The $30,000 campaign goal leaves headroom for iteration, fees, and shipping. |
The $30,000 goal in context: the verified ~$18,000 build quote plus the estimates above fit inside the campaign goal, with room for iteration, platform fees, and shipping. No expenditure on hardware has been tracked to date, and the raised total is not verified, so no raised figure is shown here.
Where V0.1 sits
The prototype is a gate, not a finish line.
On the road Kore is on, a working V0.1 plus one measured pilot is the proof that unlocks the next rung: capstone teams, manufacturing programs, and paid pilots all wait on exactly this evidence. That is why the campaign funds this build and nothing flashier.
Follow the build
Watch the prototype come together.
Get bench test results, build milestones, and pilot news as the V0.1 moves from spec to bench.
Interactive 3D · Concept
The printer, in your hands.
Drag to spin, pinch or scroll to zoom. Every product, explorable.