Data Management

Data Management is the control plane that governs how information enters, moves through and leaves Nashua 360. It owns the full lifecycle of the platform's data estate: seeding and provisioning, validated import and export, live inspection of the data model, and the safe removal or refresh of working data. Where every other module produces and consumes records, this module sets the rules by which those records are created, migrated, exported for onward use and retired, and gives administrators a single, authoritative view of the shape of the platform.

It sits at the foundation of the suite, beneath the functional modules and alongside the security and privacy layers. Its business problem is one every serious enterprise platform must solve well: keeping data trustworthy, portable and governed as it flows across many purpose-built stores, without letting provisioning shortcuts, ad hoc imports or careless deletions compromise integrity, compliance or continuity.

What the module does

Data Management delivers four tightly integrated capabilities over one governed estate. It seeds the platform, standing up the roles, reference data and configuration a working environment needs, and provisions rich, coherent demo data that populates every module page with realistic content. It performs import and export across the full record set, ingesting external data through validated, mapped pipelines and emitting clean, structured extracts for reporting, migration or archival. It provides a data model viewer that renders the live shape of the platform: the stores, the entities they hold, their fields and the relationships that bind them. And it manages flush, the controlled teardown and refresh of working data, resetting an environment to a known state while protecting the records that must never be casually removed.

Together these functions make the estate reproducible. An administrator can build an environment from nothing, load it, inspect it, export it and reset it, with each operation observing the same integrity rules, the same audit trail and the same protections. The module treats provisioning, movement and removal as first-class governed operations rather than scripts run at the margin.

The domain and data model

The platform's information lives in a data estate: a set of purpose-built stores, each shaped for a distinct job. Operational data captures the live business objects that modules read and write day to day. Transactional data records the postings, movements and events that must be exact and ordered. Configuration holds the rules, workflows and settings that govern behaviour. Documents and their binary content sit in a store built for scale and retrieval, catalogues describe structured product and bill-of-material relationships, and a warehouse holds the shaped, batched data that feeds analysis. Two further stores stand apart by design, holding sensitive personal fields with their consent and retention markers, and holding test material, each protected from routine resets.

What makes this an estate rather than a collection of databases is the model: the entities within each store and, above all, the relationships that cross between them. A company links to its contacts, its invoices, its documents and its consent records; a fiscal period ties postings to the standards under which they are reported. Data Management understands these connections, which is why it can seed a whole environment coherently, import without orphaning records, and export a subject or entity with its related history intact. Overlaying the model are retention and privacy boundaries, the rules that decide how long data persists, which stores are exempt from removal and how personal information is isolated. The module explains these concepts in plain terms through its viewer, so the shape of the platform is legible to the people who govern it, not just to those who query it.

Seed andprovisionImport andvalidateModel andgovernExport andflush
The governed lifecycle by which data enters, is inspected and leaves the Nashua 360 estate.

The principal workflows

Provisioning is the first workflow. An administrator runs the base seed to establish roles, users, modules and reference data, then layers demo data on top, module by module, to produce a fully populated environment that tells a consistent business story across two fiscal years of completed history and in-progress current work. The operation is idempotent: it cleans prior demo content before rebuilding, so it can be run repeatedly to a predictable result.

Import is the second. Source data is mapped to the model, validated against types, keys and referential rules, previewed for the operator, and committed only when it will land cleanly. Export mirrors it, drawing selected entities together with their related records into structured files suitable for downstream systems, statutory submission or migration. Model inspection runs alongside both, letting an administrator open the viewer, trace a relationship, confirm a field's meaning and verify that an import or export addresses the right structures. Flush is the workflow of controlled reset, tearing down working data in dependency order while honouring the stores marked exempt, so an environment returns to a clean baseline without ever touching protected personal or test material. Each workflow writes to the audit record, so who provisioned, imported, exported or flushed, and when, is always recoverable.

The functional depth that matters

Correctness under movement is where the module earns its place. Every operation is referentially aware: seeding creates parents before children, import rejects records that would orphan a relationship, and flush removes in reverse dependency order so nothing is left dangling. Idempotency is guaranteed rather than hoped for, which is what allows environments to be rebuilt safely and demo data to be refreshed without residue. Imports pass a validation gate that checks data types, key uniqueness, cross-store references and value domains, and reports failures precisely enough to correct them before anything is committed.

Governance is built into the lifecycle. Certain stores are flush-exempt by policy: the vault that isolates personal fields with their consent and retention markers, and the store that holds test material. These are never swept away by a routine reset, which keeps privacy commitments and quality assets intact through every environment refresh. Personal data carries its retention period and consent state with it, so exports of a subject respect what may lawfully leave the platform, and retirement of data honours the boundaries set for it. The estate spans multiple reporting standards and jurisdictional data natively, so provisioned and imported financial data arrives already shaped for parallel standards, multiple tax regimes and multi-currency reporting. Runtime activity, including every import, export and flush, is logged, giving the estate a continuous, queryable account of how its own contents changed.

How it fits the Nashua 360 suite

Data Management is the layer the rest of the suite stands on. Its seeders provision realistic, interlocking data for Accounting, including collections and treasury, for Marketing and Sales, for Financial Services, for Manufacturing with its bills of material and catalogues, for Business Relations, for the Knowledge Base and for Document Management. Because it understands the relationships that cross those modules, it can build an environment where a customer in Business Relations owns invoices in Accounting, campaign membership in Marketing and Sales, and files in Document Management, all coherent.

It works in concert with the platform's governance modules. It defers to Privacy Management for the personal fields, consent and retention held in the vault, treating that store as authoritative and exempt from removal, and it aligns with Test Management to preserve test material across resets. Its export pipelines feed the warehouse that analytics and reporting draw on, and its configuration seeding stands up the approval workflows that Accounting and other modules rely on. In effect, every module inherits its starting data, its portability and its clean-reset behaviour from this one place, which is why the estate stays consistent as the suite grows.

How AI Workers operate inside it

AI Workers are first-class operators in Data Management. An administrator can ask, in plain language, how many records of a given kind exist, which stores a relationship crosses or what a field in the model means, and a Worker answers by querying the live estate and reading the model viewer directly. Workers also execute governed operations on request: seeding an environment, running a mapped import, producing a scoped export or initiating a flush, each carried out through the same validation and audit path a person would follow, never around it.

Beyond execution, Workers watch the estate. They surface anomalies and exceptions: an import batch with a spike in validation failures, a relationship left inconsistent, a retention boundary approaching, a store drifting from its expected shape. When external material must be brought in, Workers extract and structure the data, propose a mapping to the model and flag records that will not land cleanly before anything is committed. They offer decision support, explaining the downstream impact of a flush or the reach of an export across related entities, so the operator understands consequences in advance. And Workers serve as review and approval nodes in sensitive workflows: an export of personal data or a full environment reset can require a Worker's check, or a human sign-off the Worker prepares, so that the most consequential data operations are always deliberate, reviewed and recorded.