Mathematical Data Modeling Engineer (Anchor Modeling / Pipeline Semantics)

About the Role

We’re building a data platform where trust is encoded as contracts: provenance receipts, validity gates, window semantics, and traceable transformations from raw telemetry to customer-facing outputs. We want our data model to match that philosophy.

Anchor modeling is attractive because it’s evolution-friendly and explicit about change over time. We also want to push it further: make the model as mathematically disciplined as practical—using compositional thinking to reason about transformations, lineage, and invariants.

This is an enabling role: you create the modeling framework, schemas, and semantic guardrails that make the pipelines auditable and evolvable.

What You’ll Own

• Anchor-modeled schema design: anchors, attributes, ties, historization strategy, schema evolution patterns for devices, runs, windows, contracts, artifacts, receipts.
• Mathematical semantics for pipelines: a compositional view of transformations that clarifies meaning and invariants at each stage.
• Lineage + provenance modeling: ensure every derived artifact traces back to raw inputs, configs, versions, and validity decisions.
• Contracts at runtime in the data model: represent validity gates, abstentions, failure labels, and acceptance tests so the system can answer “why did we trust this?” programmatically.
• Modeling support for the data team: review decisions, naming conventions, documentation, schema-change processes.

What You’ll Do

• Design and iterate an anchor modeling blueprint for core entities (Device, Site, Run, Window, ContractCheck, CalibrationState, Artifact, Alert, Report).
• Define how transformations compose: what the “object” is at each stage (raw stream, window, spectrum, delay track, validity verdict, report) and what each transform preserves.
• Model partial outcomes cleanly (abstain/invalid windows) without breaking downstream consumers.
• Establish schema evolution patterns (historization, bitemporality/as-of queries where needed) that don’t destroy auditability.
• Produce documentation and reference diagrams so engineers and analysts can use the model consistently.
• Pair with backend/data engineers on implementation details (DB choices, constraints, migrations) without owning all ETL.

Concrete Deliverables

• An Anchor Model Spec (v1) for core operational data: devices, telemetry, runs/windows, contract checks, artifacts, audit receipts.
• A transformation semantics doc: a compositional map of pipeline stages and invariants (readable, not decorative).
• Naming + modeling conventions (anchors/attributes/ties, historization rules, version modeling).
• A schema evolution playbook: how changes are introduced, backfilled, and validated.
• Optional: a lightweight consistency rule set (constraints + automated tests) that enforces key semantics.

Required Qualifications

• Strong experience in data modeling (conceptual + logical) and schema evolution for real systems.
• Familiarity with Anchor Modeling (or similar evolvable modeling approaches) and disciplined historization.
• Comfort with mathematical formalism: reasoning about composition and invariants, and communicating them clearly.
• Ability to collaborate as an enabling specialist: you build frameworks and conventions that make teams faster.

Preferred Qualifications

• Working knowledge of category-theory-inspired compositional thinking for software/data (or equivalent formal framing).
• Familiarity with lineage/provenance systems and data contracts (manifests, metadata graphs, reproducibility).
• Experience modeling event/time-series systems and audit logs.
• Ability to express semantics in both human docs and machine-enforceable constraints/tests.

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

• The team adopts a coherent anchor-modeled schema for at least one end-to-end slice (device → run → windows → contract checks → artifacts → report).
• Receipts and lineage become queryable and consistent—fewer ad hoc joins and mystery fields.
• Schema changes become safer: clear conventions, migration patterns, and validation tests.
• The pipeline is easier to reason about because transformation meaning and invariants are explicit (and partly enforced).

Working Style

• You like models that age well: explicit history, explicit meaning, minimal ambiguity.
• You use math as a clarity tool, not decoration.
• You build conventions that make everyone else faster.

Title & Level

Mathematical Data Modeling Engineer (Anchor Modeling / Pipeline Semantics) (senior enabling IC; can scale to Staff), partnering closely with backend and data engineering.