From a company question to a finding you can verify
“Why did operating costs rise?” needs more than a convincing answer. This walkthrough follows our Company AI Brain example through source records, exact calculations, exception rules and the questions that remain unanswered.
Published guide
1. Define what the example can establish
The finance and energy section of the fictional DemoCompany Hotels demo compares two equal 30-day periods. This illustrative dataset is separate from its arrival and room-workspace snapshot. In the cost-spike scenario, its operating ledger moves from AED 50,000.00 to AED 60,000.00: an increase of AED 10,000.00, or 20.0%. The energy component accounts for AED 8,000.00 of that change. That establishes a cost movement; it does not establish why it happened.
The public demo is a deterministic replay in your browser. It uses invented records, fixed scenarios and calculated results. There is no live language model, retrieval service or connection to a company system. It does not upload documents or persist decisions; approvals in the example are local records cleared by reset. Its purpose is to make the evidence and review workflow inspectable before a real integration is scoped.
2. Give each source a specific job
The source register contains five records with stable identifiers. A citation opens the relevant record in the inspector. The ledger supports the total-cost comparison; the separate invoice excerpt supports a duplicate check. The invoice extract is not reconciled to the ledger and must not be added to its totals.
In a production system, the same idea needs a source version, reporting window, permissions and a reliable link back to the original record. The demo’s source identifiers show the relationship between a finding and its evidence; they do not provide those production controls.
| Source ID | Record | What it supports |
|---|---|---|
| ledger | Operating ledger | Total operating cost and the energy-cost component. |
| invoices | Invoice extract | Supplier, reference and amount comparison for two invoice records. |
| occupancy | Room-night report | Occupied room nights for the same two periods. |
| meter | Energy meter | Metered electricity consumption in kWh. |
| work-order | Maintenance note | Operational context to investigate, without proving a cause. |
3. Compare energy use with the work being done
The cost comparison also accounts for demand: AED 50,000.00 / 1,000 = AED 50.00 per occupied room night, versus AED 60,000.00 / 1,050 ≈ AED 57.14. The increase is 14.3%, calculated before rounding the displayed amounts. In the steady scenario both costs and room nights rise 5.0%, so cost per occupied room night stays AED 50.00. Missing meter data does not remove this ledger-and-occupancy comparison.
Occupied room nights rise from 1,000 to 1,050, an increase of 5.0%. Electricity use rises from 50,000 to 90,000 kWh. Comparing consumption alone misses the change in activity, so the example divides kWh by occupied room nights for each period.
The current intensity is approximately 85.7 kWh per occupied room night, compared with 50.0 previously. The relative increase is approximately 71.4%. The implementation compares the original integer ratios and rounds only the displayed result to one decimal place. Calculating the percentage from the rounded 85.7 value would introduce avoidable rounding error.
The illustrative rule flags an increase strictly greater than 20% in normalized intensity. Exactly 20% does not pass that rule. This is a chosen demonstration threshold, not an industry benchmark or a statistical anomaly model. Occupancy normalization also leaves out weather, occupied floor area, equipment changes and other possible influences.
- Previous intensity · kWh per occupied room night
50,000 / 1,000 = 50.0- Current intensity · kWh per occupied room night
90,000 / 1,050 ≈ 85.7- Relative change · calculated before display rounding
((90,000 / 1,050) / (50,000 / 1,000) − 1) × 100 ≈ 71.4%
4. Separate a flag from a conclusion
Invoice records INV-204 and INV-205 have the same supplier identifier, reference SV-7782 and amount AED 6,000.00 in the spike scenario. An exact match on those three fields produces a possible-duplicate review item. It does not establish fraud, a completed duplicate payment or recoverable savings. A reviewer still needs the original invoices, purchase or service context, credit notes and payment status.
The maintenance note describes a pump operating outside its expected schedule. That is a possible explanation to investigate alongside the energy change. An association between the two records is not proof that the pump caused the increase. The suggested next step is to check operating logs and the responsible facilities team, not to control equipment automatically.
5. Let missing evidence change the answer
The missing-meter scenario keeps the cost, invoice, occupancy and maintenance records but removes the meter source. The system can still describe the cost movement and identify the possible duplicate. It cannot calculate kWh per occupied room night or determine whether that measure crossed the threshold.
The energy result therefore becomes unknown, with no meter citation or invented consumption value. This scenario has one item requiring review and one unknown. The spike scenario has two review items and no unknowns. In the steady scenario, energy use and occupied room nights both grow 5.0%, leaving intensity at 50.0; the invoice references differ. That gives no review items or unknowns within these limited checks, not a clean bill of health for the business.
6. Expose execution steps and their evidence
The trace has four stages: retrieve evidence, compare periods, check exceptions and compose findings. Each stage exposes the source identifiers it actually uses. With the meter absent, the trace must not list that source as an input. The comparison and duplicate rules remain inspectable independently of the wording of the final answer.
This is an execution record and a concise explanation of the calculation and rule. It is not a transcript of a model’s internal reasoning. A production version should record which tools ran, which source versions were used, whether an operation failed and what a reviewer approved, with access and retention appropriate to the underlying data.
7. Test what would make the result misleading
The useful test is not whether an answer sounds plausible. It is whether the output changes correctly when the evidence, question or execution state changes. The following checks make that contract concrete.
- Recompute the cost and intensity results from their cited inputs, including the unrounded 20% threshold boundary.
- Use the steady scenario to confirm that activity growth alone does not create an energy outlier.
- Remove the meter and require an unknown result, without a stale value or unavailable citation.
- Change the invoice reference and confirm that the exact-match duplicate flag clears. Test near-matches separately before expanding that rule.
- Change the question or scenario during a run and confirm that a previous run cannot supply the new answer.
- Open every citation and check that the visible source supports the claim. Check the same relationships in English and Arabic.
8. Scope the gap to a production system
A real Company AI Brain needs authorized connectors, source freshness checks, entity and period alignment, permission-aware retrieval, and a defined response to failed tools or conflicting records. If a model drafts explanations, evaluate its claims against the retrieved evidence and the independent calculations. Do not treat a fluent summary as a replacement for either.
Keep actions such as payments, external communication and changes to business records behind agreed approval rules. Use a representative evaluation set, named process owners, operational monitoring and a recovery path before expanding access. The deliverable is a system people can check and operate; the public replay is an inspectable starting point for that discussion.