Graph Algorithms Engineer (Lineage / Receipts / Dependency Graphs)

About the Role

Our product is only as trustworthy as its ability to answer: what produced this result, under what assumptions, with what data, and what would change it? That’s a graph problem.

Every deployment creates a web of dependencies: devices → telemetry → windows → estimators → contract checks → artifacts → alerts → reports. Customers need auditability (“show me the receipt”), engineering needs reproducibility, and operations needs impact analysis (“if this calibration was wrong, what outputs are affected?”).

This role owns the graph foundation that makes contracts alive at runtime real: lineage graphs, receipt graphs, and the algorithms that make them queryable, explainable, and fast.

What You’ll Own

• Lineage/receipt graph model: canonical representation of dependencies between raw inputs, transforms, versions, validity gates, and outputs.
• Graph query + explanation layer: fast retrieval of “why/how” chains, including minimal subgraph explanations.
• Impact analysis: blast radius computations—what changes if firmware, calibration, configs, or algorithm versions change.
• Incremental recomputation: determine reuse vs recompute when inputs change (memoization, caching, incremental DAG execution).
• Consistency + integrity: prevent cycles and ambiguity; enforce invariants like immutability of receipts and monotonic audit records.

What You’ll Do

• Design the graph schema (node/edge types, identifiers, immutability rules, versioning).
• Build core algorithms: reachability, topological ordering, dependency slicing, transitive reduction (where useful), minimal explanations (“smallest set of causes”), and change propagation.
• Implement graph storage + access patterns (property graph or graph-in-relational patterns), optimized for real queries and scale.
• Ensure every run produces an immutable, queryable receipt manifest linking outputs to sources and validity decisions.
• Support UI primitives: “why did this alert fire,” “why did we abstain,” “what changed since last week,” “show affected results.”
• Integrate with validation and CI so tests and goldens are reproducible and tied to exact input graphs.

Concrete Deliverables

• A Lineage Graph Spec (node/edge types, IDs, immutability rules, versioning strategy).
• A Receipt API: given an output artifact, return the full provenance chain plus a minimized explanation.
• An Impact Analysis Tool: given a change (new firmware/calibration/config), return affected runs/artifacts and a recompute plan.
• An Incremental Recompute Planner: determine reuse vs recompute using stable cache keys derived from the graph.
• A graph QA suite: invariants, cycle detection, integrity checks, and performance benchmarks.

Required Qualifications

• Strong experience with graph algorithms and practical implementations (DAGs, reachability, dependency graphs, incremental computation).
• Experience designing data structures and systems for scale: indexing, caching, query optimization, performance profiling.
• Proficiency in a systems language (Go/Rust/C++/Java) and comfort shipping production services/APIs.
• Ability to translate product questions (“why did this happen?”) into formal graph queries and algorithms.

Preferred Qualifications

• Experience with lineage/provenance systems (workflow engines, build systems, ML pipelines, artifact graphs).
• Familiarity with property graphs / graph databases (Neo4j/JanusGraph) or pragmatic graph-in-relational patterns.
• Experience with distributed-systems constraints: idempotency, retries, partial failure, eventual consistency.
• Observability/monitoring product intuition (alerts, timelines) to shape explanation primitives.

How You’ll Be Measured (First 60–90 Days)

• You ship a first end-to-end receipt chain for a real pipeline slice (telemetry → windows → contract checks → report).
• Engineers can answer “what produced this?” in minutes using your tooling—not hours.
• Impact analysis works: a simulated calibration change produces a correct, bounded blast radius and recompute plan.
• The lineage graph stays clean (no cycles, stable IDs, clear immutability) and performs acceptably on real volumes.

Working Style

• You treat auditability as a first-class feature, not an afterthought.
• You prefer explicit graph semantics and immutability over ad hoc logs.
• You enjoy turning messy causality into clean, queryable structure.

Title & Level

Graph Algorithms Engineer (Lineage / Receipts / Dependency Graphs) (senior IC; can scale to Staff/Principal if owning provenance architecture), partnering with backend/data, validation, and product/UI.