The Problem of Time in Enterprise Data
Modern enterprise systems are built around state. A user has a current name. An order has a current status. A contract has a current value. Applications query the current version, state, of these records and proceed accordingly. This works well in traditional databases where data is overwritten and old values fade into log archives. Immutable systems require a different model.
In Walacor, when a schema is created with DoSummary = true, two database objects are automatically generated: a Summary table and a History table. This dual-table model is a structural decision that separates operational state from permanent record.
Understanding this distinction is critical for designing high-assurance enterprise systems.
The Summary Table: Operational State
The Summary table contains one record per UID. It represents the current state of an object.
If a user updates their phone number three times, the Summary table contains only the latest value. It behaves similarly to a traditional OLTP table and supports fast reads for application workflows. Applications typically need to answer questions such as:
- What is the current status of this contract?
- What is the latest address for this customer?
- What permissions does this user have right now?
The Summary table answers those questions efficiently. It gives the system a present tense.
The History Table: Permanent Record
The History table stores every Create, Update, and Delete action for each UID. If a record changes ten times, there will be ten history entries. Nothing is discarded. Every transition is preserved.
This enables full audit trails, point-in-time reconstruction, forensic analysis, and compliance verification. In immutable systems, this is foundational. The History table provides the complete audit log.
Why Both Tables Matter
A system built only on current data struggles to demonstrate how it arrived at its current state. A system built only on historical records can answer every forensic question but struggles to operate efficiently in real time.
Walacor separates these concerns. The Summary table is optimized for present operations. The History table is optimized for proof and traceability. The two coexist. This is one feature that allows the platform to feel like a modern database while maintaining permanent record integrity.
Designing with DoSummary
When creating a schema, the DoSummary flag determines whether a summary table is maintained alongside history. If DoSummary = true, one record per UID exists in Summary while all actions are still written to History. If DoSummary = false, only History exists and every query operates against immutable change records.
Choosing this flag is a design decision. For operational data such as users, roles, contracts, or transactions, Summary tables often make sense. For purely evidentiary or event-stream schemas, history-only structures may be appropriate. Architects can decide based on how the data will be used.
Point-in-Time Reconstruction
Because every update is preserved in History, you can reconstruct a record exactly as it existed at a prior timestamp. This is done using aggregate queries against the history dataset.
This capability is not just about compliance, it is about operational certainty. Organizations can determine what permissions a user had at the moment of an action, what the value of an asset was at approval time, or which data governed a decision.
Traditional systems often require complex logging infrastructure to answer these questions reliably. In Walacor, it is a foundational principle of the data model.
Compliance Without External Logging Systems
Most enterprise systems bolt audit capabilities onto mutable databases by adding log collectors, SIEM tools, or change-data-capture streams.
Walacor integrates audit at the storage layer. Every envelope submission produces immutable records anchored through the platform’s processing flow. The History table becomes a structured, queryable audit ledger. Audit is not an add-on, it is embedded.
Operational Performance Considerations
Summary tables improve performance because queries target a single record per UID, indexes operate on smaller datasets, and pagination remains efficient.
History tables, by design, are append only and grow over time. They require thoughtful index planning, query projection discipline, and aggregate pipeline optimization. Architects should design indexes differently for Summary and History use cases, recognizing that each serves a distinct purpose.
Designing for Artificial Intelligence and Automation
As artificial intelligence systems increasingly rely on enterprise data, lineage becomes critical. AI systems must be able to determine what data trained a model, what information was available when a decision was made, and whether the underlying dataset has evolved since that moment.
Summary tables provide fast access to current state. History tables provide defensible provenance. This duality supports trustworthy automation and defensible decision-making.
Designing for Multi-Organization Sharing
When data is shared across organizations through structured workflows, both parties must be confident they are viewing consistent state. Summary tables enable real-time collaboration. History tables enable verification and dispute resolution.
Shared state without shared history invites suspicion. Shared history without operational state vagueness. Walacor provides both.
An Architectural Mindset Shift
Designing with Summary and History tables requires a shift in thinking. In mutable systems, developers assume that if something changes, the old version is gone. In immutable systems, developers understand that if something changes, the old version still exists and can be examined.
That awareness affects schema planning, index design, performance modeling, compliance strategy, and governance architecture. It encourages intentional design rather than reactive logging.
From Data Storage to Time-Aware Systems
Summary and History tables are architectural commitments. One serves operations. One serves proof. Together, they enable systems that can move quickly, operate efficiently, answer forensic questions, support regulatory scrutiny, and power trustworthy artificial intelligence.
Designing with both is how modern enterprises transition from mutable data stores to verifiable, time-aware data systems.
