AQLYRON

ENGINEERING YOU CAN INSPECT

Follow the input.
Inspect the output.

Four bounded examples from actual AQLYRON software. Every input is synthetic. The records show what the current code does; they do not establish diagnostic accuracy on real equipment.

Download the evidence pack Current capability map

01 / RECORDED MODEL CHECK

The next record changes
when the evidence changes.

This example uses an original Boolean control-chain model and existing synthetic traces. It illustrates a changing investigation, with no equipment operation.

  1. INPUT

    No trace value yet

    The model selects the controller record for inspection.

    READ_controller
  2. NEW INPUT

    Controller trace: false

    The next selection changes to the supply record.

    READ_supply
  3. NEW INPUT

    Supply trace: true

    No further observation is selected under this model’s current constraints. Cause stays open.

    selected: null
Why it matters

Previously supplied evidence should affect the next question. A model reaching its boundary must make that boundary visible.

Inspect the exact result and scope

Final status: APPLICABLE_EVIDENCE_OR_ESCALATION_REQUIRED

Root cause proven: false. Execution authorized: false.

This public fixture includes only existing-record candidates derived from the original synthetic model. It demonstrates neither the fastest test nor an optimal investigation. Its scheduling numbers are fixture assumptions, not measured task times.

02 / RECORDED SERVICE CHECK

An incomplete report
doesn’t become a diagnosis.

SYNTHETIC INPUT

“The system has stopped.”

The equipment identity is unknown. The statement is a customer report, and controller information is unavailable.

ACTUAL SOFTWARE OUTPUT
Case closure
DIAGNOSIS_OPEN
Root cause proven
false
Why it matters

A useful case record preserves what is known without treating a reported symptom as component proof.

03 / RECORDED EVIDENCE CHECK

Withdraw the finding.
Reconsider what depended on it.

A deliberately artificial rule first accepts a simulated value. Then the supporting finding is withdrawn. These values and conditions have no HVAC/R meaning.

BEFORE WITHDRAWAL
Synthetic check current
true
Artificial hypothesis
DIRECTLY_ESTABLISHED
AFTER WITHDRAWAL
Synthetic check current
false
Artificial hypothesis
INVALIDATED
Why it matters

A conclusion should not outlive the evidence supporting it. The original input prefix and the earlier recorded output remain inspectable.

What is established by this artificial rule?

Only the rule condition in this synthetic exercise. The fixture supplies simulated identity and review labels; they do not authenticate real sources or demonstrate a field defect. The original reference text, actual source hashes, input values, and output are included in the pack.

Withdrawal reason: MEASUREMENT_WITHDRAWN. No execution is authorized.

04 / RECORDED OUTCOME CHECK

Operation returns.
The cause still needs evidence.

A restoration report is added to the incomplete case. No defect-specific comparison or verified causal chain is supplied.

ACTUAL SOFTWARE OUTPUT
Operation reported restored
true
Root cause proven
false
Causal authority
OPEN
Actual Field prototype outcome summary: operation reported restored; root cause unproven and competing explanations remain open.
The same distinction in the actual Field prototype, captured with a separate original synthetic case.
Why it matters

Restoration is a service outcome. Keeping it separate from causal proof gives technical review and follow-up a more reliable starting point.

CHECK THE RECORD

Inputs, outputs,
and source identity.

The JSON evidence pack includes original inputs, recorded software outputs or explicitly identified output selections, assertions, and hashes of the executed source files.

Download JSON evidence Capture provenance
Reproduction and proof limits

With the matching source checkout, run node tools/public-site/generate-evidence.mjs --check. The download records outputs; it does not contain a live diagnostic engine.

Source hashes identify the executed files. They are not independent validation, source authentication, or evidence of field effectiveness. The large model testability structure is omitted from the public selection; its complete return value has a recorded hash.

Prototype screenshots use real browser rendering and actual local SQLite replay with intercepted assets. This does not establish hosted operation, production authentication, Android behavior, or physical diagnosis.

IN DEVELOPMENT

Different layers.
Different milestones.

No open trial or customer pilot is available today. Local implementation, synthetic checks, real-equipment validation, and customer readiness remain distinct.

Current development scope
Layer Current evidence Still to establish
Field web prototype Local case capture, history, review, and handoff; actual browser and service checks with synthetic cases. Customer deployment, production identity, operational reliability, and measured technician value.
Diagnostic engine Bounded evidence and model behavior, including the recorded checks above. Qualified real sources, equipment coverage, physical diagnostic validity, and comparative performance.
Android Native source and local policy checks. Build/device validation for this source revision, service parity, and field behavior. No available Android product is claimed.
Team & fleet workflows Local service and evidence foundations. Production operations, integrations, measured outcomes, and customer economics.
What role do models and technical sources play?

Models may assist with intake, extraction, discovery, explanation, and bounded proposals. Applicable, traceable, permitted evidence governs technical conclusions. A model cannot supply a missing measurement or authorize an intervention.

AQLYRON is not offered as a third-party manual repository. No OEM endorsement, certification, complete coverage, or measured customer savings are claimed.