Questions teams ask before building on current operational state.

Operational State is a continuously maintained representation of the latest known business state needed by operational consumers.

Examples include the current state of a customer, account, order, inventory item, shipment, entitlement, or service case.

It is designed for repeated operational use rather than historical analysis alone.

The Operational State Layer is the architectural capability established between systems of record and the applications, APIs, workflows, automation, and agents that need current operational context.

tapstate is the engine used to build and maintain that layer.

The layer is the architectural outcome; tapstate is the deployable product.

No.

Systems of record continue to own authoritative transactions, business rules, and writes.

tapstate maintains operational state for downstream consumption so applications do not have to reconstruct the same cross-system context or repeatedly query protected production systems.

Operational state primarily answers:

"What is true now?"

Analytical systems primarily help answer:

"What happened over time?"

Operational state is typically optimized around continuously changing current views and action-oriented consumers. Warehouses and lakehouses remain important for historical analysis, reporting, data science, and governed analytical workloads.

The two are complementary.

Yes.

The current tapstate product and CLI are being developed openly, and the public documentation and release artifacts are available for evaluation.

Use the release notes and connector directory to distinguish the current preview surface from broader target architecture.

No.

CDC is one mechanism inside Capture.

A CDC tool acquires source changes. tapstate’s broader responsibility is to capture change, transform and combine operational data, maintain usable current state, and serve that state downstream.

CDC can also remain the right standalone choice when change capture alone is the requirement.

Debezium, Kafka, Flink, and serving stores form a proven composable architecture.

tapstate makes a different tradeoff: it provides one governed Capture–Transform–Serve product model for teams whose main problem is maintaining current operational state.

A composable stack provides greater independent component choice and deeper specialized stream-processing capabilities. tapstate aims to reduce the integration and operating boundaries between capture, transformation, state maintenance, and serving.

A composable stack may be the better choice when:

• advanced event-time processing is central to the workload
• complex windows or specialized stateful computation are required
• Kafka is already the organization-wide backbone
• each layer must scale or be replaced independently
• the team already operates the stack effectively
• mature production evidence for the existing stack matters more than a unified operating model

tapstate is not intended to make those architectures obsolete.

Yes.

The boundaries are not mutually exclusive.

Kafka may remain useful for organization-wide event distribution or specialized streaming workloads. Warehouses and lakehouses remain appropriate for analytical history and reporting.

tapstate focuses on the operational source-to-state path where current, reusable state is the primary requirement.

MongoDB is the current reference backend and the target used by the v0.1.0 local end-to-end demo.

It is the current validation baseline for serving operational state, not a statement that MongoDB must remain the only possible backend permanently.

Availability and support for any other serving backend should be evaluated against the current product release and documentation.

tapstate can support patterns such as source-system offloading or live system transition where data must remain current while the original system continues to accept writes.

However, tapstate is not positioned as a generic “move anything anywhere” database migration product.

For the current v0.1.0 preview, use non-production systems and data for evaluation rather than production migration.

The connector directory covers databases, streams and messaging systems, APIs, SaaS systems, and structured file sources.

Connector capabilities vary by system.

Always check the individual connector guide for:

• source or target role
• available capture modes
• permissions
• preparation steps
• limitations
• maturity

No.

Do not infer CDC support from the database family or from the existence of a transaction log.

Check the connector directory for the declared role and read mode, then verify that the required connector artifact and tapstate release support the path you intend to run.

The product model defines four source patterns:

Full load

Read the selected existing data once.

Full load + CDC

Load existing data and then continue following supported inserts, updates, and deletes.

Stream

Consume records from a broker, queue, or another stream source.

API

Read records through a SaaS or business-system API.

The modes actually available depend on the connector and release.

That is part of the tapstate product model: operational data can be reshaped into consumer-oriented state spanning multiple systems.

However, implementation maturity matters.

The current v0.1.0 runtime supports filter, map, JavaScript, and union in the pipeline DAG. Stateful Nest and Join belong to the declared target model but are refused by the current preview runtime.

Do not describe stateful cross-system composition as generally available in v0.1.0.

Schema behavior depends on the connector, source, destination, and runtime path.

Do not assume universal automatic schema evolution.

Before production, define and test:

• schema-change policy
• type conversion
• keys
• updates and deletes
• failure behavior
• reconciliation

Use the connector-specific documentation as the source of truth.

A connector defines how tapstate understands a system.

A connection supplies the endpoint, credentials, scope, and role for one use of that connector.

Prefer narrowly scoped connections when environments, credentials, databases, source/target privileges, or recovery policies differ.

Use your organization’s normal least-privilege and credential-management model.

No.

tapstate is not an agent-building platform.

Its role is to provide applications and agents with maintained operational context drawn from enterprise systems.

The agent, model, tool-selection logic, business policy, and action controls remain outside tapstate’s product boundary.

Not necessarily.

Document assistants and isolated AI experiments can be built without tapstate.

The challenge changes when autonomous or semi-autonomous agents begin acting on live enterprise systems. Those agents often need current, coherent operational context spanning multiple systems.

Teams can build that capability themselves from capture, streaming, transformation, state, and serving infrastructure. tapstate is designed as a unified operational-data path for that responsibility.

No.

Current context is important, but it is not sufficient for safe action.

Identity, authorization, governance, observability, decision controls, application policy, and human oversight remain separate responsibilities.

tapstate should never be presented as replacing those controls.

The current public v0.1.0 release is a preview intended for local use and evaluation, not production use.

The broader architecture describes product direction and should not be interpreted as a promise that every target capability is already implemented.

Today you can:

• install the native CLI on supported macOS and Linux environments
• author and validate .tap.yml workspaces
• run the local MySQL-to-MongoDB demo
• perform an initial snapshot followed by CDC in that demo
• register connectors
• apply resources
• discover schemas
• start the pipeline
• inspect status, metrics, and logs

Other connector combinations require separate verification.

Not in v0.1.0.

The current server is a headless service with an authenticated control plane.

The CLI is the current authoring and operational interface for the preview.

The v0.1.0 runtime is single-node and keeps runtime state in memory.

A server restart currently replays from the source rather than resuming from a persisted source offset.

Durable checkpoint recovery and high-availability behavior belong to the target architecture and are not part of the current preview contract.

Evaluate at least these layers:

Connector support

Confirm connector ID, role, capture mode, permissions, external-system preparation, and known limitations.

Resource validation

Confirm the installed tapstate version accepts the resource configuration you intend to use.

Runtime behavior

Verify connectivity, data movement, keys, updates, deletes, checkpoint and recovery behavior, and relevant schema changes.

Operational evidence

Measure correctness, freshness, source impact, security behavior, capacity, failure handling, and recovery in the intended environment.

Do not treat architecture diagrams or configuration simplicity as substitutes for production evidence.