Data control plane

The control plane for customer data you can trust.

Define what data should be allowed to become before it moves downstream.

Bootstrap Data brings versioned contracts, sensitive-data policies, and consent mappings into one source configuration — giving teams a shared model for each downstream decision.

Request early access Explore how it works

Illustrative policy model — deterministic browser demo, not live product telemetry.

Event type

OMIT→ warehouse, analytics

Omitted fields: user_email

event:    checkout_started
consent:  Analytics only
─────────────────────────────
decision: OMIT
removed:  [user_email]
proposed: warehouse, analytics
blocked:  activation (pii_present)

eventcheckout_startedcart_value149.00currencyUSDuser_emailu@example.com

The problem every data team knows.

Most data platforms trust first and govern later. Data spreads across warehouses, analytics tools, and ad platforms before anyone asks whether it should have.

Events reach downstream tools before anyone reviews a schema change.
PII reaches warehouses and ad platforms because no single layer owns the boundary.
Consent is captured in a banner and forgotten the moment data starts flowing.
Governance is a quarterly audit, not a property of the pipeline itself.
Policy handoffs between engineering and legal slow every launch that touches user data.

One control plane changes the equation.

Bootstrap Data inverts that order by bringing contracts, sensitive-data policies, and consent mappings into the same layer where each source is configured.

Define an explicit, versioned contract for each event type.
PII and SPII fields are modeled and classified, making sensitive-data policy visible and reviewable.
Consent categories map directly to destination routing decisions in the same model.
Governance configuration is centralized, permissioned, and auditable across teams.
Reusable synchronized blueprints eliminate redundant work as sources multiply.

Governance as an engineering workflow.

Engineering teams already configure data pipelines. The question is whether governance is modeled at that layer or reconstructed after data has spread. Bootstrap Data makes governance a first-class engineering concern: versioned, reviewable, and connected to each source configuration.

Start with governance at source configuration. Extend the same model across collection, contracts, privacy policy, storage, and activation.

Bootstrap Data is in early access. Capabilities described here are in active development and access is limited.

Three decisions. One shared language.

The policy model makes each intended data movement explicit: allow it, block it, or omit sensitive fields.

ALLOW

Retain and route

Use ALLOW when an event matches its contract, required consent is present, and its fields are approved for declared destinations.

The configuration describes the complete proposed payload and the destinations eligible to receive it.

decision: ALLOW
destinations: [warehouse, analytics, activation]

BLOCK

Stop at the door

Use BLOCK to model a stop condition such as missing consent, a contract mismatch, or an explicit propagation rule.

The blocking condition stays visible in policy configuration so engineering and governance teams can review the same intent.

decision: BLOCK
reason: consent_missing:advertising

OMIT

Strip, then route

Use OMIT to define which PII or SPII fields should be removed before an event is forwarded.

The model identifies the proposed minimized payload and the propagation rule responsible for each omitted field.

decision: OMIT
removed: [email, date_of_birth]
destinations: [warehouse, analytics]

Follow one event through the policy model.

A source configuration connects five concerns — collection, contracts, governance, routing intent, and configuration audit — in one coherent model.

Familiar signals, one collection surface.

Accept Segment-compatible events from web, mobile, server, and batch sources. Familiar event shapes — track, page, screen, identify, group — work without pipeline rewrites.

Generated type-safe clients for TypeScript, Java, Kotlin, Swift, and Python. Source types: Android, iOS, JavaScript, Unity, Direct API.

bd.track("checkout_started", {
  cart_value: 149.00,
  currency: "USD",
  user_id: "u_7732"
});

Give every event a versioned shape.

Define reusable event and property blueprints that become the single explicit contract across all sources. Synchronized read-only copies let teams consume without diverging.

Versioned OpenAPI contracts generate clients in five languages. Reusable event and property blueprints share definitions across sources.

contract: checkout_started @ v3
blueprint: ecommerce/checkout
required: [cart_value, currency]

PII and consent, modeled explicitly.

Fields are classified as PII or SPII using key, value, and regex matcher models. Consent categories are mapped to what was actually granted, with propagation policy configured per rule.

PII/SPII key/value/regex matchers. Allow/block/omit propagation policy configuration. Consent category to destination mapping.

fields.user_email: PII  → omit_rule: strip_before_route
fields.date_of_birth: SPII → omit_rule: strip_always
consent.analytics: granted

Model ALLOW, BLOCK, or OMIT.

Connect governance policy to destination configuration so intended data movement is explicit and reviewable. Destination field filters and mappings share the same governance model.

Lake, warehouse, and destination models. Destination field filters and mappings. Consent-gated routing configuration.

decision: OMIT
removed: [user_email, date_of_birth]
proposed_destinations:
  - warehouse   ✓ (analytics consent)
  - activation  ✗ (advertising consent absent)

Every configuration change, traceable.

Review policy and connection history so teams can understand who changed the control plane and when. Permissioned mutations mean governance changes require explicit authorization.

Permissioned configuration mutations. Entity history for governance and connection changes.

policy.version: 14
change: propagation_rule.updated
actor: data-platform-team
timestamp: 2025-06-12T09:14:22Z

Built for engineering teams that think in contracts.

Each capability is independently deployable and modular — ingestion scales separately from the control plane.

Segment-compatible collection

Drop-in ingestion for events already shaped for Segment-style pipelines. track, page, screen, identify, group, alias, and batch shapes all supported.

Contract-generated clients

Versioned OpenAPI contracts generate type-safe clients for TypeScript, Java, Kotlin, Swift, and Python. Clients stay in sync as contracts evolve.

Reusable blueprints

Define event and property blueprints once. Synchronize read-only copies to sources, or snapshot an editable copy for local customization.

PII / SPII classification

Model sensitive fields using key, value, and regex matchers. Configure allow, block, or omit propagation policies per rule, per destination.

Consent-gated routing

Map consent categories directly to destination routing decisions. Configuration is versioned and reviewable alongside data contracts.

Permissioned audit history

Every governance mutation requires explicit authorization. Policy version, actor, and timestamp are recorded against configuration changes.

Generated clientsGenerated from that contract

TypeScript
Java
Kotlin
Swift
Python

Bootstrap ContractGoverned Schema · One Source of Truth

Source typesCollected into one contract

Android
iOS
JavaScript
Unity
Direct API

One control plane. Every team that touches data.

Replace ad-hoc pipeline policies with versioned configuration.

Define data contracts once; reuse them across every source.
Make schema changes explicit and reviewable at the contract layer.
Review destination policy centrally instead of source by source.
Reduce migration work with familiar Segment-compatible event shapes.

Make trust requirements explicit before data reaches your models.

Keep declared event contracts and schema rules visible in one model.
Define the minimized payload each destination should receive.
Connect warehouse mapping intent to the governing source policy.
Review governance configuration through a normal change workflow.

Make privacy decisions explicit, not archaeological.

Model PII and SPII classifications in the same layer as source configuration.
See consent-to-destination mappings in one reviewable model.
Use configuration history to review who changed which policy and when.
Align engineering and legal on one shared data language.

Design a decision for every event.

Bootstrap Data is in early access. Capabilities are in active development and the initial cohort is limited.

Request early access Explore how it works

Tell us about your data stack and the governance problem you want to solve.