Problems 1 — 7
Infrastructure
The systems that must work before the model matters.
[01]
Composable Data Platform
10/10
Run transactions and live analytics on the same tenant-specific schema, without ETL.
Why it is hard
*Physicalized adaptive schema. Every tenant gets real Postgres tables with real indexes, not an EAV store. Schema changes must propagate without downtime.
*HTAP without compromise. Transactional writes and analytical reads on the same live data, no ETL pipeline, no sync lag.
*Cell-level event generation. Every mutation becomes a training event for CENTARI without degrading OLTP performance.
CENTARI needs a clean event record from live operations. Producing it at write time removes a separate ETL system and its lag.
[02]
Agentic HTAP
8/10
Give agents the same typed database controls as engineers, including safe schema changes.
Why it is hard
*Agent-safe DDL. Agents need to propose schema changes that are validated, sandboxed, and reversible before touching production.
*Dual-write CENTARI Data Log. Every mutation becomes an EAV-formatted training event in real time.
*MCP server interface. SQL, RLS/FLS, clone/branch/merge, all exposed as typed tool calls.
An agent cannot operate the full application if database changes still require a separate human-only path.
[03]
Hi-TX Durable Execution
8/10
Persist every workflow step, retry failures, and emit the event record as work runs.
Why it is hard
*Durable execution at enterprise scale. Thousands of concurrent workflows with automatic state persistence and exactly-once semantics.
*OCEL 2.0 event emission. Every workflow step generates a structured event. The orchestration layer is simultaneously an event stream generator.
*Human-agent composition. The same workflow handles human approvals and agent actions through the same typed interface.
Long-running work fails, pauses, and waits for people. The runtime has to resume it without losing state or repeating side effects.
[04]
Meta-Ledgers
8/10
Record state changes and decisions once for audit, recovery, and training.
Why it is hard
*Append-only at scale. Ledgers grow fast. Multi-tenant ledger storage with efficient querying across billions of entries.
*Causal context. Every ledger entry must capture why the change happened, which workflow, which trigger, which upstream event.
*Regulatory compliance. Financial ledgers must satisfy SOX, GAAP, and industry-specific audit requirements natively.
The same record should explain what changed, support recovery, satisfy an audit, and feed later model evaluation.
[05]
ZSL: System of Schema
7/10
Define data, logic, workflow, policy, and UI in one TypeScript program.
Why it is hard
*Full type system with static analysis. Parser, type-checker, and compiler catch errors before deployment.
*Plan/Apply semantics. Like Terraform: preview what will change before deploying. Deterministic plans with diff output.
*E2E deployment. A single zsl apply deploys schemas to ZebraDB, workflows to ZFlow, and permissions to the auth layer.
A single definition keeps the database, workflow, permissions, and interface from drifting apart as the application changes.
[06]
CI/CD of the Configbase
7/10
Test, plan, merge, and deploy application definitions with the discipline of code.
Why it is hard
*Topological migration ordering. Schema changes must be applied in dependency order across tables, workflows, and permissions.
*Generated test suites. Every ZSL change automatically generates unit tests that validate the migration path.
*Branch/merge semantics for enterprise config. Two teams editing different parts of the same application need to merge without breaking each other.
Enterprise configuration changes production behavior. It needs the same review, test, and rollback controls as code.
[07]
Context Christmas Tree
7/10
Know exactly which model context becomes stale when the business changes.
Why it is hard
*Semantic cache invalidation. When a price changes, which predictions are stale? The dependency graph is dynamic and deep.
*Real-time context assembly. Every prediction needs fresh context from ZebraDB, ZFlow state, and upstream events, assembled in milliseconds.
*Cross-entity context. A demand forecast for Product A depends on Supplier B's lead times, Warehouse C's capacity, and Customer D's order patterns.
A prediction is not useful if its source data changed five minutes ago and the system cannot tell that it is stale.
Problems 8 — 15
Intelligence
The parts that still require new model, training, and evaluation work.
[08]
Cell-Level Tokenization
7/10
Turn every cell change into a causal event without slowing the transaction.
Why it is hard
*Dual-write without degrading OLTP performance. The hot path can't slow down.
*Causal context capture. Every cell change needs to know why it happened: which workflow, which trigger, which upstream event.
*Schema evolution. When ZSL changes the schema, the Data Log format has to adapt without breaking the training pipeline.
*Volume. A mid-market customer doing 10K transactions/day generates millions of cell-change events/month.
The training record should be created with the transaction, including its cause, instead of reconstructed later from snapshots.
[09]
Foundation Models for Enterprise Data
5/10
Train across relational structure, not table names.
Why it is hard
*Schema transfer. The model has to generalize across tenants with different schemas. It needs to learn relational structure, not field names.
*Graph-aware attention. Attention masks must follow schema topology, including key relationships and formula dependencies.
*Cross-tenant transfer. Every new customer should benefit from what the model learned on previous customers. Proving this works at scale is open research.
*Cold start. A new customer with no historical data still needs predictions.
A useful model has to transfer what it learns about collections, stockouts, vendors, and demand across different schemas.
[10]
Enterprise World Modeling
4/10
Simulate what happens next across an enterprise system.
Why it is hard
*No benchmark exists. There is no standard evaluation framework for enterprise dynamics prediction or process simulation.
*Event sequence complexity. Enterprise processes involve branching, parallel paths, exception handling, and cross-entity interactions.
*Neuro-symbolic fusion. The model must be regularized by business constraints: accounting identities, inventory conservation, process ordering rules.
*Long-horizon rollout. Simulating 30/60/90 days of operations compounds errors through interconnected processes.
Operators need to test a decision, such as a reorder-point change, against downstream inventory, capacity, and service levels before applying it.
[11]
Neuro-Symbolic Fusion
5/10
Use business rules to constrain model training and inference.
Why it is hard
*Differentiable constraint enforcement. Constraints must provide gradient signals during training AND hard enforcement at inference.
*Constraint diversity. Business rules range from simple (field X must be positive) to arbitrarily complex multi-condition approval chains.
*Customer-specific constraints. Every tenant has different business rules. The constraint layer is dynamically composed per tenant.
A statistically likely answer can still violate accounting, inventory, or approval rules. Those constraints must hold at inference time.
[12]
Cross-Tenant Transfer
4/10
Learn across different customer schemas without leaking customer data.
Why it is hard
*Schema alignment. Different tenants model the same real-world concepts differently. The model must recognize structural similarity despite surface differences.
*Privacy boundaries. One tenant's data cannot appear in another tenant's predictions. Federated and differential-privacy approaches still carry material tradeoffs.
*Scaling law uncertainty. No Chinchilla-style compute-optimal curves exist for relational foundation models.
The model should improve from broader operating patterns without exposing any tenant's records or memorizing tenant-specific values.
[13]
Human-Agent Parity
6/10
Give agents the same interfaces, permissions, and audit trail as people.
Why it is hard
*Agent harness design. Typed function call interfaces auto-generated from ZSL, constrained by the same permission model that applies to humans.
*Explanation and reversibility. Agent actions need rationale (grounded in predictions and simulations) and must be reversible through standard workflows.
*Trust calibration. The business defines trust boundaries: what agents do independently, what requires human approval, what is off-limits.
*Self-extending. When new ZSL declarations create new entity types, the agent automatically gains the ability to operate on them.
A recommendation only matters when it can enter the same permissioned workflow as a human action and leave the same audit record.
[14]
Self-Building Applications
7/10
Generate a usable application, not just CRUD, from a typed definition.
Why it is hard
*UI generation quality. The gap between 'technically correct CRUD form' and 'application humans want to use' is enormous.
*Workflow composition. New workflows must compose with existing ones. Composition rules must be derivable from ZSL relationships.
*Incremental evolution. Schema changes must update generated applications without breaking existing customizations.
If each module still requires a custom frontend project, the typed application definition has not removed the implementation bottleneck.
[15]
Network Intelligence
3/10
Learn across trading partners without exposing their transactions.
Why it is hard
*Network bootstrapping. The chicken-and-egg problem: retailers won't join without suppliers, suppliers won't join without retailers.
*Data normalization. EDI is a format from the 1970s. Different trading partners use different standards, qualifiers, and interpretations.
*Cross-entity privacy. Network intelligence must provide cross-network insights without leaking individual transaction data.
*Value capture. Free connectivity gets partners in the door. Real value requires enough network density to be meaningful.
Cross-company forecasts need signals from both sides of a trading relationship without disclosing either side's private transactions.
Closing
Why solve them together
These problems depend on one another. A model cannot act safely without the database, workflow engine, permissions, and application model underneath it.
DOSS is building the data, execution, application, and intelligence layers together. Operational events train the models. The models propose work. The same runtime applies that work under the same permissions as a person.
The test is simple: can one system keep learning and changing after go-live without another implementation project?
