Compliance

Audit-ready by default.

ISO 9001, AS9100, IATF 16949, ISO 13485. Every one of them asks the same questions. Who authored the work instruction? What version was on the floor when the unit was built? Who approved the deviation? Ignite Lean answers those questions automatically, because the answers fall out of the build flow instead of needing a binder.

Work instruction authoring

Draft, mark up, publish. All controlled.

Engineers open a real photo of the part, drop numbered callouts where the operator needs to look, and add short text where tolerances or torques matter. Every change writes a draft against the next version. Nothing reaches the floor until somebody clicks Publish — and that publish event is attributed by name and timestamp. The editor is the document control workflow.

  • Drag-and-drop canvas: callouts, arrows, text, photos, barcodes
  • Drafts are auto-saved as you go; the floor keeps showing v4 until v5 is published
  • Publish is attributed (who, when) and increments the version number
  • Every published version is a permanent snapshot — JSON scene + rendered PNG
  • Linked steps: each callout can reference a step in the BOM/sequence
EngineeringWork InstructionsWI-007 Brake caliper sub-assembly · L/F
v5 · Draft Autosaved · 12s ago
Page 1 of 2 · Snug to caliper bolts
123
Editing: Eric F. History: 4 versions · last published v4 (May 14)68% · Fit
Versioned work instructions

Every revision, every editor, every snapshot

When an engineer opens a WI, edits a callout, and saves, Ignite Lean bumps the version, stamps who edited it, when, and stores a complete snapshot. Both the editable scene and a rasterized PNG that prints identically to what the floor saw. The history is immutable; old versions are browseable forever. The kiosk always shows the latest published version. No obsolete revision on the floor, ever.

  • Auto-incrementing version number per work instruction
  • Every save records the editor (name + user id) and the timestamp
  • Snapshot per version. JSON scene + rendered PNG, stored side by side
  • Kiosk always serves the latest. No stale revisions in use (ISO 7.5.3)
  • Click any past version to view it exactly as the floor saw it
Version history current v4
  • v4
    Eric Flint current
    May 17, 2026 · 2:22 PM · changed torque to 12 ft-lb
  • v3
    Maya Rodriguez
    May 14, 2026 · 9:48 AM · updated bolt callouts
  • v2
    Jorge Lee
    May 09, 2026 · 11:04 AM · added rotor close-up photo
  • v1
    Eric Flint
    May 05, 2026 · 4:15 PM · initial publish
Immutable build records

A complete record per serial. No exceptions

Every build is a row that captures the operator, the station, the start and finish timestamps, every consumed component, every parent serial scanned, every defect flagged, every supervisor approval, and every photo. Rows are append-only; corrections are new events, not edits. When the auditor asks "show me the build record for serial X" it's one click.

  • Append-only build event log. Corrections are new events, never overwrites
  • Operator + station + timestamps captured automatically
  • Consumed components, parent serials, photos, approvals. All attached
  • Searchable build history with filters by date / operator / station / serial
Approval audit trail

Every deviation has a name on it

When an operator flags "over tolerance" on a brake-caliper bore, the unit drops into the supervisor queue. The supervisor either ships as-is (with reason), reworks, or scrapps. And that decision is attributed to them. No more "I think Pat approved it on the third shift". The audit trail names who did what, with what reason, when.

  • Defect / scrap / variance flags trigger a supervisor approval queue
  • Three dispositions per decision: ship as-is, rework, scrap. All with reason
  • Each decision attributed to the supervisor (name + user id + timestamp)
  • Photo attached at the flag stays attached through the decision
Role-based access + tenant isolation

Quality data your auditor can trust

Viewer, Operator, Manager. Each tier sees only what they should and can only do what they should. Row-level security enforces tenant isolation at the database level: your data physically cannot leak across organisations. Encrypted in transit (TLS 1.3) and at rest (AES-256). The "did the wrong person change the WI?" risk is closed at the schema, not in app code.

  • Three tiers: viewer, operator, manager. With row-level enforcement
  • Postgres row-level security: tenant isolation at the database
  • TLS 1.3 in transit, AES-256 at rest
  • Every write attributed to an authenticated user. No shared accounts
Get started

Ready to run your line on Ignite Lean?

Free during early access — 1 manager seat included, unlimited operators.

Get early access