Add design and product documentation
This commit is contained in:
16
DESIGN.md
Normal file
16
DESIGN.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Design — Volthouse Energy
|
||||
|
||||
## Direction
|
||||
|
||||
Technical blueprint interface: dark grid environment, hard data panels, luminous system accents, and diagram-led proof.
|
||||
|
||||
## System
|
||||
|
||||
- Use semantic tokens, tabular numerals, precise units, and consistent diagram grammar.
|
||||
- Avoid sci-fi decoration that does not represent system state or flow.
|
||||
- Motion may trace energy flow or transitions, with static and reduced-motion alternatives.
|
||||
- Mobile reorganizes calculations and diagrams into readable steps rather than scaling them down.
|
||||
|
||||
## Intentional patterns
|
||||
|
||||
Grid lines, one-pixel dividers, and accent borders are functional blueprint vocabulary and may be explicitly detector-waived.
|
||||
21
PRODUCT.md
Normal file
21
PRODUCT.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Product — Volthouse Energy
|
||||
|
||||
Status: approved baseline.
|
||||
|
||||
## Audience and job
|
||||
|
||||
Technical and commercial decision-makers need to understand energy systems, quantify capacity and resilience, inspect delivered projects, and request an engineering assessment.
|
||||
|
||||
## Primary journeys
|
||||
|
||||
1. Match a facility problem to an engineering solution.
|
||||
2. Inspect calculations, diagrams, case evidence, maintenance, and SLA.
|
||||
3. Submit site, load, timing, and constraint data for a qualified assessment.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- No invented savings, unsupported efficiency claims, or ornamental engineering diagrams.
|
||||
|
||||
## Success criteria
|
||||
|
||||
Technical evidence is understandable, calculators expose assumptions, and assessment requests carry enough data for a useful response.
|
||||
Reference in New Issue
Block a user