Harness Beta · session API
When a single answer is not enough
Guided HVAC diagnostic sessions, not a chat that improvises
Harness moves an intervention forward one check at a time: it uses model/SKU context, journals replies, and abstains when no specific action is safe. Built for product teams, CMMS vendors, integrators, and manufacturers.
It is neither a CMMS nor a universal OEM tree. It is a deliberately bounded Beta surface that makes diagnostic reasoning integrable, traceable, and honest about scope.
The field-session problem
A fault code does not tell your product which check to propose next
Between a code, a rating plate, and a repair, the field records observations, measurements, and things that cannot be done. A chat preserves that state poorly, and a CMMS should not have to reimplement OEM logic. Harness exposes a guided session whose next action remains reviewable.
Intervention state gets lost
The next technician sees a code and free-form notes, not which check was performed, declined, or impossible.
The model changes the answer
A procedure may suit a neighbouring range and be unsafe for the SKU on site. Harness treats ambiguity as a reason to stop.
Abstention must be an outcome
When no safe pack action applies, the product must explain escalation — not pressure an LLM to fill the blank.
Integration example
One session shared by your mobile app and back office
A technician starts a session from a work order with brand, model, and fault code. The app displays only the proposed next check; it then returns a measurement, inability to perform it, or an explicit repair result.
A supervisor resumes the same session by identifier and sees the journal. If the model is ambiguous, Harness requests the rating plate and a new diagnostic with the exact model. It never silently changes scope.
- REST: create, reply to, read, close, and summarise a session
- Mirrored MCP tools for products orchestrating tools through an agent
- Manufacturer code information remains visible even when no specific action can be proposed
Redacted excerpt for illustration only. The live API returns full manufacturer, manual, page and section — see the HVAC-Bench protocol.
Illustrative citation
Manufacturer source · Applicable manual · shown when available
Bench scenario: hvac-bench/harness-anchor-session
{
"session_id": "ds_…",
"fault_code": {
"status": "recognized",
"relation": "oriente"
},
"next_action": {
"action_id": "MES-TENSION-HPS",
"decision_role": "confirmation_measurement"
},
"outcome_state": "none"
}{
"status": "equipment_ambiguous",
"message": "Read the rating plate, then start a new diagnostic with the exact model",
"billable": false
}Honest limits
Harness Beta has a precise perimeter
Five anchor brands
Daikin, Mitsubishi Electric, Panasonic, Atlantic, and Gree across Air/Air and Air/Water heat pumps. Global lookup is a separate surface.
Mutable Beta packs
0.0.1 packs evolve during Beta. A resumed session uses current pack content; the manufacturer lookup obtained at start remains journaled.
No implicit transition
When equipment is ambiguous, the flow asks for the rating plate and a new diagnostic. No automatic model or pack switch is promised.
Who it is for
The right purchase when diagnostics become a product workflow
Perimeter A — Product, CMMS, integration
You must embed the flow in your experience
You own the work order, mobile app, or OEM portal. You need a session API rather than a chatbot that owns field decisions.
- Stateful session usable from your system of record
- Structured checks, measurements, and impossibilities instead of free-form notes
- Explicit decision: safe action, clarification, or abstention
Perimeter B — Manufacturer, operations, quality
You must be able to explain what happened
The pilot is appropriate when reasoning, sources, and a safe stop matter as much as response speed in the field.
- Manufacturer fault information kept separate from the source for a proposed action
- Session journal available for quality review and expert support
- Pilot bounded by brand, family, and use case before wider rollout
Product flow
From resolved model to recorded decision
- 1
Resolve the model
Provide brand and model; when the SKU is ambiguous, your UI collects the rating plate before opening an exact session.
- 2
Start the session
Send the fault code and symptom. Harness retains manufacturer meaning when known, then selects an action only if it is allowed and safe.
- 3
Reply to the pending check
Your product records the measurement, observation, inability to perform it, or repair result for the action actually proposed.
- 4
Resume, escalate, or close
Read the journal by session_id. A missing action or out-of-scope case becomes a clarification or abstention, never an invented procedure.
What you can verify
A bounded safety promise, not universal coverage
The public contract, Beta perimeter, and HVAC-Bench let teams evaluate what is available before they build. Harness is as valuable for explicit stops as for the checks it proposes.
See HVAC-Bench and scope5
Beta anchor brands
2
Heat-pump families
abstain
Out-of-scope decision
Prepare the pilot
Scope a Harness pilot on a real field corridor
Choose a brand, family, intervention type, and escalation criteria with us before exposing the session to your technicians.