Real Cases From Our Files
Four real cases pulled from Senzary working sessions:
**Case 1** — A request that came in tagged for Full-Stack Engineer. The skill loaded was smart-industry-architecture. The output was wrong on the first pass because the system of record wasn't checked. Eric corrected the workflow. Outcome: the rule "prove it with a URL" became standard.
**Case 2** — A multi-step task that crossed track boundaries. Full-Stack Engineer handed off to engineering at the right moment. The handoff worked because both sides knew which skill owned the next step.
**Case 3** — A scenario where the wrong skill got loaded. The agent guessed at the answer instead of loading the right skill. Eric flagged it. The lesson: when in doubt, list available skills, pick the one whose triggers match, and load it explicitly.
**Case 4 — Bad alias implementation on PROD - Baghouse.** A URL on dashboard 64884430 carried `currentCustomer = Clarios` and `currentLocation = US Geneva IL` in the state params, yet the card widgets did not filter. Why: the dashboard has 9 entity aliases, but NONE read `currentLocation`. The Attributes card was bound to a `singleEntity` alias (hardcoded — ignores URL state). The 3D Heat Map was bound to a `relationsQuery` rooted on `currentDevice` (null in the URL — returned nothing). Lesson: when a URL carries a state param, every widget that should react MUST be bound to a `stateEntity` (or `relationsQuery rootStateEntity:true`) alias on the matching `stateEntityParamName`. `singleEntity` and rooting on the wrong param are silent failures — the widget renders with no data and no error. Always inspect the alias list before building.
How Eric talks about this
“prove it with a URL”
Real case: an agent claimed a record was updated without the URL. Eric called it out. Prove it with a url became the standard. From that point, no update is real without the artifact.
“which skill owns this”
Real case: a task got handled by the wrong skill and the answer was generic. Eric's rule: when in doubt, ask which skill owns it. The skill index in the system prompt has the trigger phrases.
“hand it off cleanly”
Real case: an item bounced between tracks because neither side knew who owned what. The fix: every handoff includes the artifact, the context, the next action, and the date. No verbal handoffs.
“should filter based on entity in card widget but does not”
Eric flagged that a URL carrying currentCustomer=Clarios and currentLocation=US Geneva IL failed to filter the card widget. Root cause was a bad alias implementation. The Attributes card was bound to a singleEntity alias ("Current Customer for Entity Hierachy") — singleEntity is a hardcoded entity that ignores URL state. The 3D Heat Map was bound to a relationsQuery rooted on currentDevice, but currentDevice was null in the URL, so the query returned an empty set. The fix pattern: ANY widget that should react to URL state must use a stateEntity alias (with the matching stateEntityParamName) or a relationsQuery with rootStateEntity:true on the right param. singleEntity is for pinned reference entities (a known gateway). Rooting on the wrong param fails silently. The smart-industry-dashboards skill §14 has the canonical alias shapes — copy them, don't invent.
From the agent files
DustIQ Geneva — Devices Invisible Under An Asset
session 8b6a956eOn the DustIQ dashboard (`ff476ee0-460f-11ef-baa8-0728d63c7750`, AES tenant, host `iotlogiq.com`), when Eric drills into the Clarios → Geneva location → Stacker 1 machine, the *Devices* table for that machine is **empty**.
When a widget shows empty but the relation graph is correct, look at the **server-attribute predicate** the alias applies (especially `access_users CONTAINS`, `template EQUAL`, `customerTag`). Missing attributes on a single customer's entities is the most common root cause of "same dashboard works for everyone except this one site." The single-thread tunnel-vision lesson: **always pick the cleanest comparator sibling**, not the loudest one. Toledo was loud because it had virtual D25 devices; St Joseph was quiet and structurally identical to Geneva — and that's where the diff lived.
source: source/GENEVA_DUSTIQ_DIAGNOSIS_HANDOFF.md · source/widget_alias_map.csv
Try these exact phrasings
Try it yourself
Pick one of the four cases in this chapter. In ≤400 words: explain what skill the case used, what the original mistake was, what the corrected workflow looks like now, and one place you've seen the same pattern in your own work. For Case 4 (the alias-binding bug), name the three alias filter types involved (singleEntity, stateEntity, relationsQuery) and which one is correct for a URL-state-driven filter.
- correctly names the skill used in the case
- correctly summarizes the original mistake
- identifies the rule the correction established
Quick check
1. What rule does 'prove it with a URL' enforce in real cases?
- a. Style preference
- b. No claim without proof (URL, record, file path)
- c. Use formal language
- d. Keep messages short
Reveal answer
Prove it with a url is the proof rule. Every status update must include the artifact that verifies it.
2. When the wrong skill loads, the typical symptom is:
- a. Faster response
- b. Generic, structurally incorrect output
- c. Errors in the terminal
- d. The site goes down
Reveal answer
Wrong skill → generic answer that's missing the structural pieces (record IDs, attribute trees, etc.) the right skill would have brought in.
3. What makes a handoff between tracks complete?
- a. A verbal note in standup
- b. Artifact + context + next action + date — written down
- c. An @mention in Slack
- d. Tagging the team lead
Reveal answer
Real-case rule: handoffs are written, include the artifact, the context, the next action, and the date. No verbal-only handoffs.
4. A URL carries currentLocation in state params. Which alias filter type makes a widget react to that param?
- a. singleEntity (hardcoded entity)
- b. stateEntity with matching stateEntityParamName
- c. entityType with resolveMultiple
- d. relationsQuery rooted on currentDevice
Reveal answer
stateEntity with stateEntityParamName matching the URL key (or relationsQuery with rootStateEntity:true on the same param) is the only way a widget reacts to URL state. singleEntity is for pinned reference entities. relationsQuery on the wrong param fails silently. Source: smart-industry-dashboards §14, case 4 on dashboard 64884430.
Built 2026-07-31 · 4 teaching moments · 3 prompts