Specification as shared context
The specification connects a product question to objects, interfaces and acceptance conditions. It gives people and development agents a common boundary to work within.
RESEARCH / R&D PRACTICE
Concept artwork · Failure, revision and evaluation under a shared constraint.Build with hypotheses. Advance with evidence.
Our development approach connects product intent, explicit contracts and observable outcomes. AI can accelerate the work; evaluation determines what is ready.
Evidence travels with the change
Select a layer to explore its role.
EvidenceInforms the next iteration
01 / QUESTION
Write the specific question that current methods or system behaviour do not settle. Separate the research uncertainty from implementation work.
question + hypothesis expected observation
Harness exposes initiation, design and contract gates followed by Alpha, Beta and release. The diagram connects that progression with the research and validation practices described in our engineering record.
Experiments as decision tools
A comparison is useful when it changes the next decision. We retain configuration and evaluation scope, including approaches that fail or remain inconclusive.
Release as an evidence boundary
A roadmap describes intent. A release needs a reviewed implementation, relevant checks and a known version. Evidence should travel with the capability it supports.
INSIDE HARNESSA visible path
A visible path
through the work.
Harness is our internal R&D control platform. Its product map spans App/Panel, Energy, Manager, Studio and Enterprise. Specifications connect repository context and supporting documents; prototypes and QA boundaries provide review surfaces.
The observed progression is initiation, design, contract, Alpha, Beta and release. Its value is the connection between those stages and the work that substantiates them.
Explore our engineering platforms01 / Initiation · articulate the need
02 / Design · define the system
03 / Contract · establish the boundary
04 / Alpha · exercise the implementation
05 / Beta · validate the experience
06 / Release · preserve the evidence
The feedback loop
belongs outside production.
Our Home Agent infrastructure proposal separates feedback capture, privacy filtering, sandbox adaptation and evaluation from household deployment. Candidate models and adapters pass validation and regression checks before release. It is a direction for governed personalisation, not an assertion of autonomous training inside a home.
Cloud and edge, with different jobs
Select a layer to explore its role.
01 / HOME & EDGE
Persistent context. Responsive local control.
Structured contextEvaluated decisions
02 / REASONING & RESEARCH
Reasoning and adaptation, with a release gate.
01 / HOME CONTEXT
Household, individual, spatial, device, environmental, event and security context form the input domains. Retention and access boundaries belong in the design.
household / individual / space capabilities / environment / memory / identity
A proposed routing and governed-learning architecture. Model choices, capacity and performance remain subject to validation.
SYSTEMS / IN DETAIL
A contract turns intent into reviewable work.
The development direction makes product intent, interface expectations and acceptance conditions available to both engineers and agents. The review object is the change together with evidence of its behaviour.
CONCEPTUAL MECHANISM 01 / 04
| Boundary | Responsibility | Engineering consideration |
|---|---|---|
| Product intent | A user or system outcome | Avoid using implementation activity as a substitute for an acceptance condition. |
| Interface contract | A shared expectation across consumers | Review identity, data meaning and failure behaviour before integration. |
| Release evidence | Observed results for a specific revision | Record remaining limitations rather than inheriting confidence from a stage label. |
What does agent-friendly engineering require?
Agents benefit from navigable specifications, small explicit contracts and repeatable verification. They also need a clear boundary between suggested implementation and accepted outcome. Harness supplies product and development context; validation supplies the evidence that a change works across its intended consumers.