Enterprise AI Project Wiki · Data, knowledge and models
Business data
Also calledBusiness data · Business information · Operational business data · Business-domain data
Business data is data an organisation creates, obtains, maintains, or uses in conducting a business or mission process and that represents, in identifiable form, business objects and attributes, events and transactions, state changes, decisions, responsibilities, or outcomes. Its boundary comes from business meaning and use, not a table name, file format, storage location, or production-environment origin.
Business meaning and use define business data, not its database location
Business data answers whom or what an organisation is handling, what happened, its state, the decision made, and the result. Customers, suppliers, products, and contracts are objects; orders, requests, payments, and service cases are transactions or business records; submission, approval, shipment, and cancellation are events; amount, state, accountable person, and effective date describe those facts.
It can exist in databases, messages, files, spreadsheets, documents, transcripts, paper material, human queues, or external systems. Data in a production database is not necessarily business data—a memory metric may not be—and a test environment may hold a copy of business data. Meaning, purpose, and accountability matter more than medium or environment name.
Business data is a practical umbrella term whose classes vary by industry. In supply-chain practice, GS1 distinguishes relatively stable master data describing entities, transaction data supporting inter-organisational processes, and visibility-event data reflecting physical or digital processes. Other domains use customer, operations, case, clinical, or mission data. A project records its own classification and mappings.
Identify objects, facts, and processes instead of exporting every table
A database contains formal records, caches, technical logs, and intermediate tables created for implementation. Identify business data through objects such as customers, contracts, requests, and payments and the events and decisions they undergo. That reveals what needs durable meaning, governance, and handover.
Bound the business or mission
State the products, services, journeys, internal functions, regions, and organisational units supported. Same-named data in an out-of-scope system does not enter automatically.
List objects and participants
Identify customers, employees, suppliers, products, assets, contracts, requests, and cases needing stable identity, plus people, organisations, systems, and agents acting in roles.
Mark events and transactions along scenarios
Walk through create, submit, confirm, approve, fulfil, pay, amend, cancel, close, and dispute paths, including exceptions, and record input facts and resulting outputs.
Separate current state from historical fact
A current balance or state may derive from transactions and events. Decide which layers remain, how they recalculate, and whether correction may overwrite history.
Identify decisions, rationale, and evidence
Find data, applicable rules, approving actor, supporting material, and outcome for material decisions. An attachment is not automatically a verified fact.
Inventory copies and downstream use
Trace identity, point in time, and purpose as data enters reports, indexes, caches, warehouses, exports, third parties, and model context.
Obtain authorised classification
Business, data, records, security, privacy, operations, and technical roles confirm object, authority, sensitivity, record status, and lifecycle. A discovery scanner cannot decide alone.
Useful classes of business data
Classification is not a label for every table; it separates responsibilities. Master data needs stable identity, transactions preserve events, reference data controls permitted values, and analytical derivatives need a method and applicable time. Authority, quality, and change differ by class.
Master data
Relatively stable data repeatedly referenced to identify core entities consistently across processes—customers, suppliers, products, locations, and organisations. It changes, but typically less often than transactions and needs authority and synchronisation governance.
Reference data
Permitted values, codes, units, territories, states, or rate types used to classify or constrain other data. It need not represent a specific entity; applicable version and effective period matter.
Transaction data
Business or financial interactions and commitments such as purchase orders, invoices, payments, returns, and service requests. It commonly references master data and carries amount, state, and responsibility.
Event data
Records something occurring at a time—submission, scan, shipment, receipt, approval, or device trigger. Events can drive state without every event becoming a contractual or financial transaction.
State and operational data
Represents an object's current stage, queue, balance, inventory, availability, or processing location. State whether it is authoritative, a computed snapshot, or an eventually consistent observation.
Business documents and content
Contracts, applications, receipts, email, images, recordings, and explanations, with their structure, signature, version, and evidence relationships. A file is not inherently trustworthy and its content still needs interpretation.
Decision, rule-execution, and audit facts
Records rule version, input facts, decision, approval or override, actor, and time to explain a business outcome. A technical audit log is only one possible evidence carrier.
Derived and analytical results
Metrics, aggregates, forecasts, scores, segments, and model outputs computed from other data. Mark method, time, version, and permitted purpose; do not silently write them back as source facts.
Business semantics clarify object, time, state, and permitted values
Amount, customer, and complete sound ordinary but may mean gross or net, contracting party or contact, submission complete or payment complete. State object and time boundaries so people, rules, reports, and interfaces interpret the same value consistently.
Object identity
Define what makes the same customer, supplier, product, request, or contract; who issues identifiers; whether they can be reused; and how merge or split preserves history. Names are not unique identity.
Attribute meaning
For each material field, state object, characteristic, unit, precision, permitted values, null meaning, and context. ISO/IEC 11179 highlights both semantic and representational descriptions for data elements.
Business time
Separate occurrence, receipt, recording, effective, expiry, settlement, correction, and observation times, with time zone and late-event treatment. updated_at does not carry them all.
State and transition
Define the business fact represented by each state, entry and exit conditions, terminal states, reversal, and correction. UI text, database codes, and external states need controlled mappings.
Amount and quantity
Retain currency, tax basis, unit, precision, rounding, rate source, and aggregation. Total must say which lines and point in time it uses.
Truth and confirmation level
Distinguish a user assertion, system validation, third-party response, model inference, human confirmation, and formal approval. Available material is not necessarily verified fact.
Version and validity
Master data, code lists, terms, rules, and derived indicators change over time. Reconstruct the version in force for a result rather than interpreting all history with today's definition.
Know who defines, confirms, and keeps the authoritative source
When several systems hold one field, the newest copy is not necessarily authoritative. Define who owns the meaning, which system creates the formal fact, who may correct it, and how quickly copies follow. Disputes can then use governance instead of guessing from timestamps.
Business-definition accountability
An authorised role with domain knowledge confirms meaning, rules, quality, and applicability. Technology teams maintain carriers but cannot infer business truth from the present schema.
System of record or authoritative evidence
For each object or attribute, identify the system, signed material, external registry, or authorised decision that prevails. One system can govern supplier address but not credit state.
Creation and confirmation
Separate data-entry actor, fact provider, reviewer, approver, and system generator; retain the identity chain for delegation, proxy, batch, and automated decisions.
Custody and platform operation
Assign operation, protection, recovery, and monitoring of databases, document stores, messaging, warehouses, and backups. Technical custody does not grant every business use.
Consumer responsibility
Consumers follow purpose, time, quality, access, and onward-sharing conditions. Possession of a copy does not turn it into a new authoritative source.
Conflict decision and escalation
Set an authorised decision-maker, holding state, stop condition, and evidence for inconsistent sources, human/system conflict, historical correction, and unavailable external authority.
Business events change data; copies and derivatives remain in the lifecycle
A request moving from draft to approval, withdrawal, or closure leaves current state, history, notifications, reports, and caches. Correcting or deleting the source does not automatically update them. Lifecycle governance follows propagation so old facts do not continue shaping decisions.
The lifecycle is not a simple create–store–delete line. A request becomes an order, delivery and invoice follow, payment changes a balance, and cancellation creates compensating events. Original facts, current state, snapshots, and downstream aggregates form a network. Decide which facts are immutable, which are corrected by a new event, which may be overwritten, and how to reconstruct a point in time.
The NIST Privacy Framework treats collection, retention, logging, generation, transformation, use, disclosure, sharing, transmission, and disposal as data actions. The list helps expose caches, indexes, exports, and third-party copies even outside personal-data scope; for personal data, authorised privacy roles must confirm purpose and risk.
Not all business data is an official record, and records are not limited to PDF files. NARA explains records as documenting organisational policies, transactions, decisions, and actions across creation or receipt, maintenance and use, and disposition. Applicable records and legal authorities decide which data, documents, metadata, and system documentation must be retained as records.
- Can a business state be reconstructed?
A material outcome links to original facts, events, rules, decisions, and corrections rather than retaining only a current value.
Check: sampled point-in-time reconstruction and reconciliation.
- Do copies and derivatives have identity?
Reports, warehouses, indexes, exports, and third parties state source, time, refresh, and permitted use.
Check: data flow and processing inventory.
- Did an authorised role determine record status?
Retention, hold, and disposition do not come from a developer or database TTL alone.
Check: record class, schedule, and approval.
Tie quality, integrity, and protection to business consequences
A missing telephone extension and a wrong payment account are both data errors with very different consequences. Quality priority, access protection, and remediation time follow use and harm; an overall completeness percentage must not hide a small number of severe records.
Fitness for purpose
Set accuracy, completeness, consistency, timeliness, uniqueness, and validity for submission, payment, service, reporting, forecasting, or audit separately. One copy is not fit for every use by default.
Integrity and defensible facts
Protect material transactions and decisions against unauthorised change and preserve source, sequence, checks, approval, and correction. NIST SP 1800-26 offers engineering reference for detecting and responding to integrity events.
Confidentiality and minimum use
Limit view, export, sharing, and analysis by type, actor, purpose, and risk; reduce unnecessary fields and retention. Internal does not mean visible to every employee.
Availability and recovery
Define stop, read-only, queue, human, and recovery paths when data is unavailable, delayed, or uncertain, and reconcile restored state with external transactions.
Information type and risk category
NIST SP 800-60 illustrates classification by information type and confidentiality, integrity, and availability impact. Projects use their applicable regime and do not copy US federal impact conclusions as defaults.
Issue treatment
Record affected objects, period, source, downstream use, decisions, and ownership; isolate, correct, recalculate, notify, revoke, or accept under authority and close with evidence.
Project handover requires more than a database backup
A backup restores bytes but may not tell the receiving team what objects mean, which source is authoritative, how to validate them, or how to delete them lawfully. Handover also needs vocabulary, lineage, access, quality rules, retention, and open issues.
Business-data catalogue
List objects, events, transactions, states, documents, and derivatives by domain, with purpose, accountability, authority, sensitivity, record status, and main consumers.
Definitions and mappings
Handover controlled dictionary, code lists, relationships, state machines, source–target mapping, transformations, and reconciliation rules, including open items and owners.
Access and operational responsibility
Explain production, support, reporting, export, third-party, and emergency access. Account transfer must not expand business authority; audit and review continue.
Initialisation and migration evidence
Record scope, batches, exclusions, cleansing, failures, before/after counts and material totals, samples, discrepancy closure, approval, and source freeze time.
Backup, recovery, and continuity
Distinguish authority, recovery copy, and archive; provide recovery point and time, keys, dependencies, exercises, post-recovery reconciliation, and transactions code rollback cannot undo.
Retention, export, and retirement
Transfer disposition rules, holds, readable export, third-party return or deletion, system documentation, and retirement evidence so the receiving team need not guess long-term duties.
Constructed business data for a procurement request
This customer-independent procurement request brings object identity, state events, decision records, and derived measures together. The point is not field design but how every class returns to an authoritative source, business time, and permitted use.
Business objects
Request, applicant, supplier, purchase item, budget object, contract, and attachment have stable identity. Supplier references approved master data; the request retains the necessary submission-time snapshot.
Transaction and amount
Lines record item, quantity, unit, currency, tax basis, price source, and rounding. Total is a derived result with rule and version, not an unexplained independent fact.
Event and state
Create, submit, return, correct, approve, reject, send to ERP, acknowledge, and cancel each retain event and record times, actor, prior and new state, and reason.
Decision and evidence
Approval links to then-current input facts, rule version, authority, comments, and material. An AI summary or risk signal is labelled an assisting derivative, not approval fact.
Authority and copy
The request system governs workflow state, identity platform supplies actor identity, supplier master governs active status, and reconciliation confirms whether ERP created its record.
Record and lifecycle
Business and records authorities determine which request, approval, attachment, interface confirmation, and audit facts form records and set correction, hold, retention, export, and disposal. Test copies are separately minimised and destroyed.
Enterprise AI must not collapse input facts, knowledge, and model output into one layer
A model can turn records into a summary, label, or recommendation, but fluent language does not make an inference a formal fact. If generated output shares a field with authoritative data and lacks source and review status, later retrieval may treat the model's old guess as new evidence.
Bound the approved business use
Specify retrieval, summary, extraction, classification, recommendation, prediction, or action and decisions prohibited from model-only handling. Access does not authorise training or cross-purpose reuse.
First distinguish a formal fact, someone’s assertion, and a model inference
Authoritative records, user input, external material, model extraction, model inference, and human confirmation have different standing and need separate labels. A supplier name inferred from an invoice may await review but cannot overwrite master data; otherwise one recognition error becomes a confirmed fact for later systems.
Filter context by object and purpose
Enforce user, tenant, object, field, and purpose authorisation before retrieval, prompts, and tools; send task-required data only. Relevance does not bypass access control.
Expose source and time
Link an AI result to records, version, effective period, and retrieval time. Changed, conflicting, or insufficient evidence triggers a limited answer, refresh, or human handling.
Govern model output as derived data
Summaries, labels, scores, and advice retain model, prompt, knowledge, rules, time, input references, and review state, plus permitted consumer, validity, correction, and write-back conditions.
Keep tool actions inside transaction boundaries
After a model proposes parameters, deterministic controls validate identity, authority, state, amount, and duplicates. Reconcile an unknown result rather than treating timeout as non-occurrence.
Feedback and logs are not automatic training material
Before production conversations, corrections, or failures enter evaluation or training, reconfirm purpose, rights, minimisation, sensitivity, representation, version, period, and approval.
Propagate correction and deletion
When a fact changes or use rights end, identify indexes, caches, features, evaluations, and controllable derivatives. Record and treat effects that cannot be directly removed from model parameters.
Monitor business impact
Monitor distribution, source, missingness, and access change and the effect of wrong outputs on real objects and decisions. Model metrics do not replace transaction reconciliation and outcome confirmation.
How business data differs from neighbouring concepts
Business data consists of facts and records meaningful to the organisation; master, transaction, reference, and analytical data play different roles within it. Database data is broader, while knowledge documents and model output have different authority. The distinction assigns the right source, change, and use responsibility.
| Concept | Boundary from business data |
|---|---|
| Enterprise data | All data controlled or used by an organisation, including business, technical, research, workforce, external, and management data. Business data is the part directly representing business or mission facts. |
| Data requirement | States semantic, source, quality, protection, and lifecycle obligations for specified data. Business data is the facts and records constrained by those requirements. |
| Business object | A person, thing, matter, or concept identified in the domain. Business data represents its attributes, relationships, events, and states; an object is not one table. |
| Master data | Relatively stable business data used to identify core entities consistently across processes. It does not include every transaction, event, document, and result. |
| Reference data | Codes and permitted values used to classify, constrain, or interpret other values, maintained by external or internal authority. It supports interpretation of business data. |
| Transaction data | Orders, payments, and other business or financial interactions, one business-data class. Business data also contains master, events, states, documents, and decisions. |
| Business record | Information retained under an applicable records regime to document policies, transactions, decisions, or actions. Some business data forms records, but the terms are not automatically equivalent. |
| Metadata | Describes definition, origin, structure, time, access, or processing. It may itself carry business evidence but usually explains and manages business data. |
| Technical log and telemetry | Describes system execution, requests, resources, and faults. Some entries may also prove a formal business action; an ordinary CPU metric generally is not a business fact. |
| Analytical data | Integrated, cleansed, or derived for reporting, analysis, or models. Its time, grain, and method may differ and it does not automatically become the transaction authority. |
| Personal data | A category related to individuals under applicable law and policy that can overlap with business data. Authorised roles determine classification and duties. |
| Training data | A dataset used to train or adjust a model, possibly containing authorised business data or public, synthetic, and other sources. Availability does not authorise training. |
Sources and scope
This entry uses business data for data an organisation creates, receives, maintains, or uses while carrying out business or mission activity and that describes business objects, participants, events, transactions, states, decisions, obligations, and outcomes. Classification of business data is not identical across organisations, so each project must state its working scope. This entry does not fully define all enterprise data, master data, reference data, transaction data, event data, business records, data requirements, data models, databases, metadata, technical telemetry, analytical metrics, test data, training data, legal categories of personal data, knowledge documents, or a data-governance system. Authorised roles must decide whether particular data is business data or an official record, which source is authoritative, and which protection and retention duties apply.
- ISO/IEC 11179-1:2023 — metadata-registry framework in which metadata describes data and supports concepts, definitions, and shared understanding
- ISO/IEC TR 20943-1:2003 — data-element identity, contextual names and definitions, data-element concepts, conceptual domains, and permissible values; confirmed current in 2022
- GS1 System Architecture — master data describes relatively stable entities and combines through identifiers with transaction and event data in business documents
- GS1 System Architecture — transaction data supports collaborative processes; visibility-event data evidences physical or comparable digital processes
- ISO/IEC 25012:2008 — structured-data quality model based on satisfying needs under specified conditions
- NIST SP 800-60 Vol. 1 Rev. 1 — mapping mission, management, and support information types to confidentiality, integrity, and availability impact
- NIST Privacy Framework — examining digital and non-digital processing, ecosystem roles, business drivers, and privacy risk from collection through disposal
- NIST SP 1800-26 — engineering reference for identifying, protecting against, detecting, responding to, and recovering from enterprise data-integrity events
- US National Archives records-management FAQ — records document organisational policy, transactions, decisions, and actions across creation or receipt, maintenance and use, and disposition
- NIST AI RMF Core — AI data, provenance, quality, representativeness, privacy, security, actors, third parties, monitoring, and change