Skip to content
datificial

Delivery and operation

One prepared data product, delivered where the system needs it.

The storage engine is not the product. Datificial selects delivery from the expected queries, latency, volume, refresh, security, ownership, and operating model, then documents the contract the consumer can rely on.

The contract

Every delivery has an explicit contract.

  • product and release identifier
  • schema and schema version
  • stable identifier policy
  • source and method freshness
  • access and authorization model
  • query or file format
  • pagination and sorting behavior where applicable
  • null, missing, redacted, and unavailable states
  • error taxonomy
  • rate, size, and resource limits
  • quality indicators and known limitations
  • deprecation and compatibility policy
  • refresh schedule or event semantics
  • support, incident, and rollback boundary

Targets

Six delivery families.

Files and analytical tables

Best for: Batch analytics, training and evaluation, customer-owned processing, archival releases, and easy handoff.

  • Parquet datasets partitioned by date or entity
  • JSONL for record-oriented processing
  • CSV only where interoperability requires it
  • Arrow and IPC for high-throughput interchange
  • DuckDB package for portable analytics
  • PostgreSQL or warehouse tables
  • manifest, schema, checksums, and release notes packaged alongside data

Requirements: No unversioned file overwrite, machine-readable schema, deterministic naming, checksums, documented partitioning, sample queries, and explicit encoding and timezone rules.

Databases and warehouses

Best for: Internal operational or analytical use with existing infrastructure.

  • PostgreSQL
  • customer warehouse
  • columnar or analytical database
  • graph database where relationship traversal is load-bearing
  • client-managed object store plus query engine

Requirements: Migration and schema versioning, least-privilege roles, a release boundary or effective-date model, reproducible loads, index definitions, rollback access, and consumer views separated from staging.

Search and retrieval indexes

Best for: Semantic search, recommendation, comparison, evidence retrieval, and agent queries.

  • full-text index
  • vector index
  • hybrid lexical-semantic retrieval
  • metadata filters
  • relational lookup backing store
  • graph or adjacency index
  • optional reranker

Requirements: Index tied to a release, stored representation versions, deterministic rebuilds, representative retrieval evaluation, stale-index detection, permission filters enforced server-side, and no vector score presented as factual confidence.

APIs

Best for: Product integration, controlled external access, and stable multi-client consumption.

  • record lookup
  • filtered list and query
  • search
  • comparison
  • evidence retrieval
  • release metadata
  • change feed
  • export job

Requirements: OpenAPI specification, versioned endpoints, machine-readable errors, cursor pagination, rate and query limits, authentication and scoping, request IDs and audit logs, no undocumented fields, and a deprecation period.

Scheduled feeds and change events

Best for: Applications that need updates rather than interactive queries.

  • scheduled file release
  • incremental table sync
  • webhook
  • queue or topic publication
  • typed change-event stream
  • human-facing release notice

Requirements: Every event identifies the record, event type, previous and current release, changed fields, observed and effective time, source and method class, significance state, and a link to evidence where permitted.

MCP and agent tools

Best for: Agents that need bounded, documented access to a product.

  • list available products
  • describe schema and coverage
  • look up a record
  • search records
  • compare entities
  • retrieve supporting evidence
  • list changes since a release
  • request a bounded export

Requirements: Task-level tools rather than raw database access, typed JSON with release and provenance metadata, predictable empty and error states, enforced permissions, bounded result sets, evidence as a separate call, read-only first, and evaluation against representative agent tasks. MCP is a structured interface over prepared data, not autonomous intelligence.

Deployment models

Datificial-managed

Datificial hosts the pipeline and delivery service in an agreed environment. Suitable when sources can legally and securely be processed in the managed boundary and rapid operation matters more than infrastructure ownership.

Customer-cloud deployment

Datificial packages and deploys the product into customer-controlled infrastructure. Suitable when sensitive data must remain inside the customer boundary or long-term operation will be internal.

Hybrid

Sensitive extraction and normalization remain customer-side while de-identified or approved artifacts flow to a managed enrichment or serving boundary.

Handoff models

Managed
Datificial owns day-to-day operation under a service agreement.
Co-managed
Datificial runs specialized stages while customer teams operate source or serving components.
Transferred
Datificial delivers code, containers, infrastructure, documentation, and training for customer operation.

The selected model is explicit in the proposal and runbooks.

Start with the consumer, not the storage engine.

Describe how the application or agent needs to query, refresh, and audit the data. Datificial will recommend the delivery contract that fits.