Skip to main content

​
What ION does for you

If you run a hardware company, or run a function inside one, ION is the source of truth about what your factory is actually doing: what’s running right now, what’s stuck, what’s been built, what shipped, and where defects came from. It’s the operational system underneath the metrics, not just the metrics layer on top. Your analysts, your VP of Ops, your VP of Quality, and your VP of Engineering all share one underlying system, with one model. The questions you ask cross-functionally have one answer instead of three.

​
Where to start

  1. What is ION?: the product overview.
  2. Analytics and Dashboards: the built-in reporting surface.
  3. API reference: for the analyses your team will inevitably want to run outside the UI.

​
The questions ION can answer

​
What to ask your team for

  • A live dashboard of in-flight runs by program: easy to build off the API, useful for the weekly operating review.
  • A monthly aBOM-vs-mBOM divergence report: catches drift between design intent and what’s actually shipping.
  • A supplier scorecard derived from receiving inspections + run-time NCRs: see Issues.
  • An open-issue aging report: anything in containment or open disposition that’s been there too long.
  • Don’t ask for the metric. Ask where the metric comes from. Metrics out of context are misleading; the same query in ION can be sliced six different ways and produce six different answers. Have your team document the query.
  • Trust the aBOM. When something goes wrong in the field, the aBOM is the legally-defensible record of what was actually built. Make sure your team is generating clean aBOMs before you need them.
  • Anything you can do in the dashboards, you can do (and automate) over GraphQL. Make sure your analytics team has access.