MINUTEMEN TECHNOLOGIES / PROPOSED VENTURE
Product catalog
One free local software pilot; fourteen proposed software, hardware or research products.
Free local software pilot. Proposed capabilities are not commercially available or certified systems.
MINUTE OS
Intelligent Operations Environment · Free local pilot
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Owner-run service businesses |
| Functions | Jobs, manually reported equipment, text procedures, approved local review-task workflows and audit history. |
| Architecture / dependencies | React client over a typed domain core; IndexedDB stores one encrypted, revisioned workspace. Web Crypto derives a non-extractable key from the user passphrase. No service business records are transmitted to a server. |
| User journey / prototype | Use Command Center → create job → add equipment → preview flow → approve → inspect history → export encrypted backup. |
| Limitations / safety | 300 jobs; 150 equipment records; 50 text documents; 20 flows; 1,000 runs; latest 500 audit actions. No cloud team ACL, server account, remote scheduling or SLA. |
| Acceptance criteria | Persistence, wrong-passphrase refusal, encrypted backup restoration, quota failure, multi-tab conflict and approval/idempotency tests. |
HELIX
Local intelligence adapter · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | MINUTE OS users needing document assistance |
| Functions | Optional retrieval and small-model suggestions grounded in authorized local material. |
| Architecture / dependencies | Separate inference worker with cancellable messages, versioned model manifest and a disabled-by-default tool broker. Existing All•Tier is a separate optional local-AI tool; this release does not rename it HELIX or silently share workspace data. |
| User journey / prototype | User opts in to a model download → selects documents → views retrieved excerpts → requests a draft → reviews it. |
| Limitations / safety | Device memory and language/model quality constrain capability. No autonomous email, financial, legal or machinery actions. |
| Acceptance criteria | Measure retrieval against manually labeled documents; verify citation coverage, cancellation and no-prompt-egress before enabling model assistance. |
CORE 01
Compact local workstation · Hardware concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Owner-operated local workflows |
| Functions | Local inference, document processing and application hosting. |
| Architecture / dependencies | Commodity x86-64 or ARM64 system; initially no custom board. Select processor by actual model/runtime support, available memory bandwidth and measured thermal behavior. |
| User journey / prototype | A reference-build sheet and local workload runner precede any enclosure design. |
| Limitations / safety | Planning target: 32 GB RAM, 1 TB replaceable NVMe, wired Ethernet, USB, TPM/secure boot where supported, active cooling; 15–65 W system target is unmeasured. |
| Acceptance criteria | Test start-up, sustained workload, power, thermal throttling, backup restore and repair access; never publish invented tokens/second. |
CORE PRO
Engineering workstation · Hardware concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Developers and engineering teams |
| Functions | Larger local-model experiments, simulation and build workloads. |
| Architecture / dependencies | Workstation-class commodity CPU; optional supported discrete accelerator selected by model size, VRAM, driver support and maintainability. |
| User journey / prototype | Use owned or borrowed equipment for reproducible workload characterization. |
| Limitations / safety | Planning target: 64–128 GB RAM, 1–2 TB NVMe, optional 12–24 GB accelerator memory, active airflow, accessible expansion; 200–700 W target requires actual PSU/thermal verification. |
| Acceptance criteria | Run versioned workloads, driver-recovery and endurance tests; publish raw measurements with configuration and uncertainty. |
CORE EDGE
Rugged edge computer · Hardware concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Facility monitoring teams |
| Functions | Buffered telemetry, local analytics and controlled gateway services. |
| Architecture / dependencies | Industrial ARM64 or x86 module, watchdog, qualified storage and isolated interface adapters. Avoid mains wiring or unsafe direct machinery interfaces in early prototypes. |
| User journey / prototype | Begin with read-only captured data and certified external power supplies. |
| Limitations / safety | Planning target: 8–32 GB RAM, 256 GB–1 TB SSD, Ethernet and approved field interfaces, 10–50 W; environmental, ingress and EMC claims require testing. |
| Acceptance criteria | Brownout recovery, clock drift, storage wear, network interruption and measured environmental tests on a safe bench. |
CORE RACK
Rack infrastructure · Hardware concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Organizations with a demonstrated centralized workload |
| Functions | Multi-user compute and storage after operational demand exists. |
| Architecture / dependencies | Serviceable server platform with ECC memory where supported, remote management on an isolated administration network and redundant power only where justified. |
| User journey / prototype | Capacity-plan a real workload before specifying a rack. |
| Limitations / safety | Planning target: 128–512 GB RAM, replaceable storage, optional accelerator, 500–2,500 W configuration envelope; facility power/cooling must be independently assessed. |
| Acceptance criteria | Burn-in, redundant path failure, restore drills, administrative isolation and documented service procedures. |
SENTRY R1
Supervised inspection robot · Research concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Facilities with repeatable low-risk inspection routes |
| Functions | Capture authorized inspection observations under remote supervision. |
| Architecture / dependencies | Validated mobile base, guarded drive system, encoders, IMU, obstacle sensing and visible status; navigation software is separated from an independent emergency-stop and power-isolation path. |
| User journey / prototype | Simulation → bench sensors → supervised exclusion zone → independently assessed inspection pilot. |
| Limitations / safety | Not for people transport, public-space autonomous operation, hazardous locations or safety-critical inspection decisions. Battery and charging risks require qualified review. |
| Acceptance criteria | Fault injection, safe-stop behavior, loss-of-link response, obstacle/person tests, battery monitoring and controlled route acceptance. |
VECTOR
Robot fleet coordination · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Operators of validated supervised robots |
| Functions | Queue approved missions, show stale telemetry and coordinate operator handoffs. |
| Architecture / dependencies | Mission service with expiring authority leases, sequence numbers, read-only dashboards and clear local autonomy limits. The robot safety controller cannot depend on cloud availability. |
| User journey / prototype | Operator approves mission → robot accepts within its permitted area → progress expires when stale → operator intervenes. |
| Limitations / safety | No remote override of emergency stops or locally enforced safety boundaries. |
| Acceptance criteria | Duplicate mission delivery, lease expiry, split-brain scheduling and network-loss drills before any physical pilot. |
AEGIS
Defensive device posture · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | IT administrators |
| Functions | Surface known device configuration, supplied vulnerability information and security events. |
| Architecture / dependencies | Opt-in supported endpoint agent or authorized exports; normalized evidence, least-privilege collection and a human-reviewed incident queue. |
| User journey / prototype | Collect authorized evidence → correlate rules → show confidence and timestamps → require approval for containment. |
| Limitations / safety | The MINUTE OS Sentinel view is not AEGIS. No scanner, malware protection or vulnerability certification is implemented. |
| Acceptance criteria | Known-good/known-bad fixtures, false-positive review, source freshness, tenant isolation and minimally privileged incident response. |
WATCHTOWER
Operational monitoring · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Equipment and infrastructure maintainers |
| Functions | Report missed heartbeats, stale observations and operational anomalies. |
| Architecture / dependencies | Timestamped telemetry with device identity, freshness windows, deduplication and explicit unknown states. Distinguish process outages from cybersecurity findings. |
| User journey / prototype | Device observation → unit/schema validation → time-window evaluation → correlated operator alert. |
| Limitations / safety | An absent heartbeat is not evidence of a cyberattack; sensors can fail independently. |
| Acceptance criteria | Simulate stale clocks, reconnect storms, maintenance windows and missing samples without hiding data gaps. |
GRIDKEEPER
Energy monitoring · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Building/facility managers |
| Functions | Normalize energy data, identify unusual consumption and compare recommendations with measured baselines. |
| Architecture / dependencies | Read-only meter/CSV adapters, interval units, timezone handling and occupied/unoccupied schedules. Any control integration needs a separate qualified safety review. |
| User journey / prototype | Import consented readings → validate units → show coverage gaps → compare baseline → human reviews suggestion. |
| Limitations / safety | No promised savings, billing-grade meter certification, tariff advice or live switching. |
| Acceptance criteria | Validate sample intervals and totals against source records; compare predictions on withheld data and disclose errors. |
RELAY ONE
Industrial networking gateway · Hardware/software concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Facilities with justified connectivity needs |
| Functions | Provide documented network segmentation and supervised failover. |
| Architecture / dependencies | Supported appliance, explicit allowlists, certificate identity, read-only diagnostics and disabled remote administration by default. No invented zero-trust certification. |
| User journey / prototype | Bench network → policy review → recorded failure scenarios → limited non-production pilot. |
| Limitations / safety | Never bypass an industrial safety boundary or expose an administration port publicly. |
| Acceptance criteria | Failover timing, loop prevention, DNS/certificate failure, backup configuration and recovery tests. |
FIELDLINK
Offline field operations · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Technicians with intermittent connectivity |
| Functions | Record work locally and reconcile approved updates after reconnection. |
| Architecture / dependencies | Encrypted local event log, device-scoped identity, per-record versions, attachment manifests and explicit conflict screens. No last-writer-wins for safety/status approvals. |
| User journey / prototype | Technician records draft → queue remains visible offline → server acknowledges sequence → conflicting change requests human resolution. |
| Limitations / safety | True background sync and multi-user authorization are not implemented in the current local pilot. |
| Acceptance criteria | Duplicate/reordered delivery, clock skew, partial acknowledgement, conflict resolution and recoverable offline exports. |
FORGE
Manufacturing operations · Proposal
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Small shops with a documented process owner |
| Functions | Track versioned work instructions, lots, quality checks and maintenance records. |
| Architecture / dependencies | Process-revision registry, operator authorization, recorded approvals and append-only server evidence in a future shared deployment. |
| User journey / prototype | Define one process → capture work order → record quality checks → approve release → retain evidence. |
| Limitations / safety | Not a certified manufacturing execution system or validated regulated quality system. |
| Acceptance criteria | Reconstruct a lot from source records; reject obsolete instructions and unauthorized release; verify correction history. |
ATLAS
Engineering digital twin · Research concept
| Engineering dimension | Proposed specification |
|---|---|
| Target customer | Engineers comparing bounded scenarios |
| Functions | Explore a specific model with units, calibration data and uncertainty. |
| Architecture / dependencies | Versioned model packages, bounded solver inputs, reproducible seeds, unit checks and measurement-to-model comparisons. This MMT concept is separate from XRP Legacy’s existing financial Infrastructure Atlas. |
| User journey / prototype | Choose model → inspect assumptions → run scenario → compare to a held-out physical observation. |
| Limitations / safety | A visualization is not a validated twin. No simulated output authorizes a real safety-critical action. |
| Acceptance criteria | Conservation/unit checks, sensitivity analysis, calibration split and documented limits of applicability. |