The Platform

Normalization and entity resolution, in one pipeline step.

HyperNorm runs two sequential stages: first it normalizes every field name, unit, and data type across your vendor schemas; then it resolves which rows across all sources represent the same real-world entity.

Read the docs Start Free

HyperNorm platform data flow architecture

01 Layer 1

Normalize

HyperNorm reads your vendor schema on first ingestion, infers a canonical field map, and locks it for future runs. Every incoming feed is coerced to that canonical form before any downstream process sees it.

Schema inference on first run, no manual field mapping YAML to write from scratch
Field canonicalization, gross_revenue_usd, total_rev, revenue_eur all become revenue_usd
Unit conversion, currency (multi-currency to USD), temperature (F/C/K), dates (ISO 8601 standard)
Type coercion, string booleans, loose numerics, null handling per field rule

Canonical schema mapping auto-inferred

gross_revenue_usd total_rev revenue_eur

revenue_usd

last_updated UpdatedAt update_ts

updated_at

company_name CompanyTitle org_name

canonical_entity

region Territory area_code

region_code

02 Layer 2

Resolve

After normalization, HyperNorm runs entity resolution across the unified records. It finds rows that represent the same real-world entity, assigns a confidence score to each match, and outputs a single canonical record with a provenance trail.

Blocking strategy, pre-filters candidate pairs to avoid O(n²) comparisons at scale
Jaro-Winkler fuzzy matching, handles abbreviations, punctuation variants, legal suffixes
Confidence scoring (0.0-1.0), lets you set a threshold; low-confidence pairs surface for manual review
Provenance trail, every canonical record tracks which source rows it merged

{
  "canonical_id": "ent_9f2a1c",
  "canonical_name": "Acme Corporation",
  "confidence": 0.97,
  "match_method": "jaro_winkler",
  "sources": [
    "vendor_a",
    "vendor_b"
  ],
  "duplicates_merged": 3,
  "provenance": [
    { "source": "vendor_a", "raw_value": "Acme Corp" },
    { "source": "vendor_b", "raw_value": "ACME Corp." },
    { "source": "vendor_b", "raw_value": "ACME Corporation" }
  ]
}

Technical specifications

APIs and SDKs

InterfaceREST API + Python SDK

AuthBearer token (API key per workspace)

Base URLhttps://api.hypernormforai.com/v1

VersioningURL-versioned (v1, stable)

Data formats

InputJSON, CSV, Parquet, Avro

OutputJSON, CSV, Parquet

ConnectorsFivetran, dbt, direct DB, S3

Schema formatYAML (versioned)

Performance

Normalization latency< 8ms per record

Entity resolutionAsync batch (near-real-time on Team+)

Max throughput100M records/month (Team plan)

Blocking strategyLSH + phonetic indexing

Compliance

Data residencyCloud SaaS (no self-host at this stage)

EncryptionTLS 1.3 in transit, AES-256 at rest

RetentionConfigurable per workspace

SOC 2Controls documentation (roadmap)

Integrations

HyperNorm fits into your existing data stack. Pull from warehouses and object stores, run normalization and resolution, push clean records to your BI layer or model training pipeline.

Snowflake BigQuery Redshift Postgres dbt Airflow Prefect Looker Metabase CSV / Parquet Salesforce HubSpot

Full connector library: docs/connectors

HyperNorm vs. manual reconciliation

The real cost of hand-built field mapping and entity deduplication scripts is not the initial build time. It is every sprint after that.

	Manual reconciliation	HyperNorm
Initial setup	3-5 days per vendor feed	20-minute config review
Ongoing maintenance	Every schema change = re-mapping sprint	Schema versioning auto-detects drift
Entity match accuracy	Exact string match only (~60-70% coverage)	~94% fuzzy match precision
Unit error detection	Silent; found 6 weeks after training	Detected and converted at ingestion
Team bandwidth cost	1 engineer per 3 vendor feeds	One config file, unlimited feeds