MINUTEMEN TECHNOLOGIES / PROPOSED VENTURE
Research & development
Ten technically plausible research proposals. Originality and patent eligibility are not asserted.
Free local software pilot. Proposed capabilities are not commercially available or certified systems.
13. Advanced research opportunities
Research begins with falsifiable questions rather than an invention claim. Prioritize recovery, reliable workflows and explainable local assistance before material science, advanced robotics or unbounded AI autonomy.
Each proposed experiment needs a baseline, measurable success/failure threshold, permitted dataset, risk owner, reproducible method and stop condition. Cancel projects that require unapproved spend, unavailable data rights or safety authority the team does not possess.
Receipt-Locked Flows
| Dimension | Research proposal |
|---|---|
| Problem | duplicate or unapproved operational actions |
| Technical concept | bind an approval receipt to the source event, command revision and action scope |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | ordinary approval systems and idempotency keys. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | show the exact approved object revision in a local replay inspector |
| Difficulty | moderate; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | two conflicting job versions and duplicate delivery fixtures |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | a second identical event produces no second task |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Private Procedure Lens
| Dimension | Research proposal |
|---|---|
| Problem | procedures scattered across personal files |
| Technical concept | retrieve selected local excerpts before drafting any suggestion |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | desktop search and document assistants. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | make source selection and data residency visible beside each result |
| Difficulty | moderate; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | a labeled 30-document synthetic procedure set |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | a query returns the correct excerpt and abstains when no source supports an answer |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Power-Loss Journal
| Dimension | Research proposal |
|---|---|
| Problem | work lost during network or device interruptions |
| Technical concept | use bounded durable local event batches with recoverable commit markers |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | offline forms and write-ahead journals. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | explain recoverable versus acknowledged work to technicians |
| Difficulty | high; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | fault injection around every persistence boundary |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | a simulated interrupted commit recovers a coherent prior or new revision |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Capability Passport
| Dimension | Research proposal |
|---|---|
| Problem | generic adapters granted excessive device control |
| Technical concept | publish signed, expiring adapter capabilities with read/write scopes |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | device certificates and scoped API tokens. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | separate telemetry permission from command permission in the operator UI |
| Difficulty | high; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | mock adapters with expired and revoked scopes |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | an expired capability cannot issue a simulated command |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Freshness-First Watch
| Dimension | Research proposal |
|---|---|
| Problem | stale measurements mistaken for healthy equipment |
| Technical concept | make source age, clock quality and missing intervals part of every displayed state |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | monitoring dashboards and heartbeat alerts. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | promote unknown state instead of silently carrying forward a green status |
| Difficulty | moderate; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | timestamped fixtures with clock drift and gaps |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | a stale source becomes unknown with its last observed time retained |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Recovery Rehearsal
| Dimension | Research proposal |
|---|---|
| Problem | backups exist but have never been restored |
| Technical concept | test an encrypted exported snapshot in an isolated restoration workspace |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | backup validation and disaster-recovery exercises. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | produce an operator-readable list of recovered record counts without sending data away |
| Difficulty | moderate; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | known dataset, damaged backup and wrong-passphrase cases |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | restore produces identical supported records and refuses tampered ciphertext |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Energy Intent Sandbox
| Dimension | Research proposal |
|---|---|
| Problem | optimization advice ignores operational constraints |
| Technical concept | simulate a proposed schedule against measured baseline and owner-defined exclusions |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | energy dashboards and schedule optimizers. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | show uncertainty and excluded safety-critical loads before approval |
| Difficulty | high; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | synthetic interval data and locked-load rules |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | the proposed schedule never changes an excluded load in simulation |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Serviceable Edge Manifest
| Dimension | Research proposal |
|---|---|
| Problem | repair technicians cannot identify compatible parts or firmware |
| Technical concept | version the component/firmware/recovery mapping for a reference device |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | asset manifests and software bills of materials. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | join replacement steps with signed software compatibility checks |
| Difficulty | moderate; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | one commodity reference build and failure scenario |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | a technician identifies a compatible replacement and recovery procedure |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Human Handoff Ledger
| Dimension | Research proposal |
|---|---|
| Problem | automated decisions lose their responsible reviewer |
| Technical concept | record a scoped human handoff with decision rationale and revocation |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | task approval logs and case-management workflows. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | require an explicit new handoff when scope or source data changes |
| Difficulty | moderate; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | multiple reviewer labels in a non-production fixture |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | changed scope invalidates the prior simulated approval |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |
Measured Twin Contract
| Dimension | Research proposal |
|---|---|
| Problem | digital-twin visuals imply unjustified accuracy |
| Technical concept | bind every simulation run to model version, units, calibration set and error envelope |
| How it works | Validate input → bind version/authority → execute a bounded local calculation → present source evidence → require human review. No external action by default. |
| Components | Typed event envelope, local persistence, deterministic test fixtures, review UI and exportable evidence. |
| Potential customers | Service-business operators first; engineering/industrial teams only after validated domain demand. |
| Competing approaches | simulation provenance and model validation tools. Category comparison only; no completed competitive landscape or novelty claim. |
| Proposed differentiation | display applicability limits as part of the result, not hidden documentation |
| Difficulty | high; prototype effort depends on data quality and acceptance criteria. |
| Prototype requirements | one bounded physical process with permissioned measurements |
| Safety / regulation | Non-production data; no safety-critical action; domain/privacy review before real deployment. |
| Commercial potential | A customer-validation hypothesis. Interview users about the problem and measure repeated use; no revenue or demand is asserted. |
| Patentability question | Does a specific technical implementation differ materially from known methods? Perform dated prior-art and freedom-to-operate review before any claim or filing. |
| Minimum demonstration | a withheld measurement is compared against a predeclared error criterion |
| Evidence gate | Publish the fixture, expected result, failure cases and repeatable procedure; compare to the simpler baseline. |