{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.tr.data-architecture","code":"thing-q638422","url":"https://ver.cy/models/thing/q638422/","name":"data architecture","alternateNames":[],"kind":"thing","status":"published","version":"0.1.0-research.1","language":"en","classifiers":{"family":"Thing Registry","category":"Information and virtual systems","entryKind":"thing","plane":"INF","domain":["INF.KNW"],"industry":[],"navPath":"","tags":[],"facets":{}},"whatItIs":"Data architecture is a framework for organising data and defining its interrelationships, structures, flows and management constraints in support of an organisation's missions, functions, goals, objectives and strategies.","purpose":"Enable an agent to recognise data architecture, assess whether its representations and decisions meet information needs, and identify justified changes to how data is organised, exchanged and governed.","scope":{"in":["The framework's subject matter, organisational objectives and boundaries.","Conceptual and logical organisation of data, including shared meanings, identifiers and relationships.","Architectural allocation of authoritative data, storage responsibilities and exchange patterns.","Cross-system requirements for data quality, protection, retention and traceability.","Current-state and target-state data architecture, decision rationale and transition dependencies.","Evidence that implementations conform to architectural decisions."],"out":["The contents and individual records of a particular dataset","Detailed database indexing, query tuning and storage-engine configuration","Implementation and operation of individual ingestion or transformation pipelines","Organisation-wide governance policy creation and adjudication","Application behaviour unrelated to data responsibilities or exchanges","Analytical conclusions, statistical models and machine-learning model design"],"boundaries":[]},"distinguishingFeatures":["An architecture connects data meanings and structures to flows, responsibilities and constraints; a data model alone primarily describes entities and relationships.","An architecture explains decisions spanning data producers, stores and consumers; an inventory or catalogue alone lists assets and metadata.","An architecture specifies intended arrangements and trade-offs; a deployed data platform is one implementation that may conform to or diverge from them.","Data governance establishes authority and policy, while data architecture translates those requirements into data boundaries, controls and exchange arrangements.","The framework is distinct from the discipline and methods used to develop it and relates data arrangements to organisational missions, functions, goals, objectives and strategies."],"structure":{"bundles":[{"id":"discipline-and-boundaries","name":"Discipline and boundaries","description":"Establishes what data architecture means in the chosen context and how its practice is distinguished from neighbouring fields.","layers":[{"id":"subject-and-method","name":"Subject and method","description":"Identifies the discipline's subject matter and the methods used to make architectural decisions.","findings":[{"id":"declared-architectural-convention","name":"Declared architectural convention","description":"Record the adopted definition, modelling conventions and methods without treating one convention as universal.","questions":[{"text":"Does this use of data architecture denote a discipline, an organisational arrangement or its description?","id":"declared-architectural-convention-q01","kind":"definition"},{"text":"Which handbook, framework or institutional source supplies the adopted definition and methods?","id":"declared-architectural-convention-q02","kind":"provenance"}]}]},{"id":"neighbouring-disciplines","name":"Neighbouring disciplines","description":"Locates the boundary with data modelling, data engineering, governance and enterprise architecture.","findings":[{"id":"allocation-of-architectural-responsibility","name":"Allocation of architectural responsibility","description":"Record which decisions belong to data architecture and which belong to adjacent practices under the named convention.","questions":[{"text":"Which data decisions are architectural here, and which are delegated to governance, engineering or application teams?","id":"allocation-of-architectural-responsibility-q01","kind":"boundary"},{"text":"Which classification schemes, curricula or professional institutions explicitly recognise this field, and how do they place it?","id":"allocation-of-architectural-responsibility-q02","kind":"provenance"}]}]}]},{"id":"data-meaning-and-structure","name":"Data meaning and structure","description":"Captures the meanings, identities and structural relationships that data implementations must preserve.","layers":[{"id":"domain-semantics","name":"Domain semantics","description":"Defines data domains, business concepts and contextual differences in meaning.","findings":[{"id":"concept-boundaries-and-mappings","name":"Concept boundaries and mappings","description":"Record shared concepts and explicit mappings where domains use different meanings or levels of detail.","questions":[{"text":"Which entities, events and measures must have agreed meanings across the architecture?","id":"concept-boundaries-and-mappings-q01","kind":"definition"},{"text":"Where does an apparently shared term denote different concepts, populations or levels of aggregation?","id":"concept-boundaries-and-mappings-q02","kind":"boundary"}]}]},{"id":"identity-and-representation","name":"Identity and representation","description":"Connects conceptual identity to logical structures and physical representations.","findings":[{"id":"identifier-and-schema-continuity","name":"Identifier and schema continuity","description":"Record how identifiers, relationships and temporal meanings survive representation changes.","questions":[{"text":"How are identities reconciled across sources, including duplicate, merged or reassigned identifiers?","id":"identifier-and-schema-continuity-q01","kind":"definition"},{"text":"What mappings preserve relationships and historical meaning when logical or physical schemas change?","id":"identifier-and-schema-continuity-q02","kind":"action"}]}]}]},{"id":"authority-placement-and-exchange","name":"Authority, placement and exchange","description":"Describes where data authority resides, why copies exist and how data moves between producers and consumers.","layers":[{"id":"authority-and-storage","name":"Authority and storage","description":"Allocates authoritative production, persistence and replication responsibilities.","findings":[{"id":"authoritative-data-and-replicas","name":"Authoritative data and replicas","description":"Record authority at an appropriate entity or attribute level and distinguish authoritative stores from derived copies.","questions":[{"text":"Which source is authoritative for each critical entity or attribute, and under what conditions?","id":"authoritative-data-and-replicas-q01","kind":"definition"},{"text":"Why is each replica, cache or analytical copy needed, and who resolves conflicts between copies?","id":"authoritative-data-and-replicas-q02","kind":"boundary"}]}]},{"id":"exchange-contracts","name":"Exchange contracts","description":"Describes data movement patterns and producer-consumer obligations.","findings":[{"id":"flow-semantics-and-coupling","name":"Flow semantics and coupling","description":"Record exchange contracts covering structure, freshness, ordering, duplication and compatibility where relevant.","questions":[{"text":"For each critical flow, what delivery, ordering and duplicate-handling behaviour do consumers require?","id":"flow-semantics-and-coupling-q01","kind":"definition"},{"text":"How are contract changes introduced and incompatible consumers identified before release?","id":"flow-semantics-and-coupling-q02","kind":"action"}]}]}]},{"id":"data-lifecycle-and-controls","name":"Data lifecycle and controls","description":"Translates ownership, protection and lifecycle obligations into architectural arrangements.","layers":[{"id":"ownership-and-protection","name":"Ownership and protection","description":"Connects accountable roles and approved handling requirements to data boundaries.","findings":[{"id":"policy-to-control-mapping","name":"Policy-to-control mapping","description":"Record the provenance of handling requirements and the architectural points that enforce them.","questions":[{"text":"Which accountable authority supplies classification, access and location requirements for each data domain?","id":"policy-to-control-mapping-q01","kind":"provenance"},{"text":"At which stores, interfaces and transformations are those requirements enforced and verified?","id":"policy-to-control-mapping-q02","kind":"action"}]}]},{"id":"retention-and-lineage","name":"Retention and lineage","description":"Tracks data origins, derivations and lifecycle transitions across the architecture.","findings":[{"id":"derivation-and-disposition","name":"Derivation and disposition","description":"Record how retained, transformed and deleted data can be traced across operational and derived copies.","questions":[{"text":"Which critical producer-to-consumer paths have verified lineage, and where does traceability stop?","id":"derivation-and-disposition-q01","kind":"measurement"},{"text":"How do retention expiry, deletion and authorised preservation requirements propagate to replicas, extracts and backups?","id":"derivation-and-disposition-q02","kind":"action"}]}]}]},{"id":"fitness-and-failure-behaviour","name":"Fitness and failure behaviour","description":"Evaluates whether the architecture supports required data quality and service behaviour under normal and disrupted conditions.","layers":[{"id":"consumer-quality-requirements","name":"Consumer quality requirements","description":"Connects data quality expectations to intended uses and architectural responsibilities.","findings":[{"id":"quality-thresholds-and-checkpoints","name":"Quality thresholds and checkpoints","description":"Record measurable quality requirements and where violations are detected or contained.","questions":[{"text":"What completeness, validity, uniqueness and freshness thresholds apply to each critical use, with what denominators and observation windows?","id":"quality-thresholds-and-checkpoints-q01","kind":"measurement"},{"text":"Where are invalid or late data rejected, quarantined, corrected or exposed with qualifications?","id":"quality-thresholds-and-checkpoints-q02","kind":"action"}]}]},{"id":"consistency-and-recovery","name":"Consistency and recovery","description":"Captures acceptable divergence and recovery behaviour across stores and exchanges.","findings":[{"id":"disruption-and-reconciliation","name":"Disruption and reconciliation","description":"Record acceptable data loss, staleness and inconsistency alongside evidence that recovery arrangements meet them.","questions":[{"text":"What data-loss window, recovery time and cross-store divergence are acceptable for each critical data service?","id":"disruption-and-reconciliation-q01","kind":"measurement"},{"text":"How are replayed events, partial writes and conflicting replicas reconciled after interruption?","id":"disruption-and-reconciliation-q02","kind":"action"}]}]}]},{"id":"architectural-change-and-evidence","name":"Architectural change and evidence","description":"Connects architectural intent to observed implementation and controlled evolution.","layers":[{"id":"baselines-and-decisions","name":"Baselines and decisions","description":"Separates observed, proposed and approved arrangements and preserves decision rationale.","findings":[{"id":"architecture-to-implementation-trace","name":"Architecture-to-implementation trace","description":"Record dated evidence for current-state claims, approved decisions and implementation deviations.","questions":[{"text":"Which diagrams and decisions describe observed implementation, and which describe a proposed or approved target?","id":"architecture-to-implementation-trace-q01","kind":"boundary"},{"text":"What dated evidence supports conformance claims and identifies approved exceptions or unresolved deviations?","id":"architecture-to-implementation-trace-q02","kind":"provenance"}]}]},{"id":"migration-and-retirement","name":"Migration and retirement","description":"Describes dependencies and acceptance conditions for changing data authority, structures and flows.","findings":[{"id":"safe-data-transition","name":"Safe data transition","description":"Record transition sequencing, reconciliation criteria and conditions for retiring old data paths.","questions":[{"text":"Which producers, consumers, identifiers and historical records must migrate together or remain compatible during transition?","id":"safe-data-transition-q01","kind":"boundary"},{"text":"What reconciliation, cutover and rollback evidence is required before authority transfers or an old store is retired?","id":"safe-data-transition-q02","kind":"action"}]}]}]},{"id":"evidence-and-external-alignment","name":"Evidence and external alignment","description":"What the world already says about this thing, gathered so the model can be checked against it.","layers":[{"id":"reported-evidence","name":"Reported evidence","description":"Findings from the breadth pass, kept separate from the structural claims.","findings":[{"id":"evidence-confidence-notes","name":"Check these first","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these check these first hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-confidence-notes-q01","kind":"provenance"}]},{"id":"evidence-kinds","name":"Kinds and varieties","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these kinds and varieties hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-kinds-q01","kind":"provenance"}]},{"id":"evidence-standards-and-regulation","name":"Standards and regulation","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these standards and regulation hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-standards-and-regulation-q01","kind":"provenance"}]},{"id":"evidence-real-world-use","name":"Real-world use","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these real-world use hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-real-world-use-q01","kind":"provenance"}]},{"id":"evidence-failure-modes-and-hazards","name":"Failure modes and hazards","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these failure modes and hazards hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-failure-modes-and-hazards-q01","kind":"provenance"}]},{"id":"evidence-regional-variation","name":"Regional variation","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these regional variation hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-regional-variation-q01","kind":"provenance"}]},{"id":"evidence-neighbours","name":"Neighbouring kinds and how to tell them apart","description":"Recalled without web access and unsourced; every item is a lead to verify.","questions":[{"text":"Which of these neighbouring kinds and how to tell them apart hold for the sense of data architecture this model covers, and on what evidence?","id":"evidence-neighbours-q01","kind":"provenance"}]}]}]}]},"agentConduct":{"may":["Describe and document an organization's data structures, flows and stores for its authorized staff.","Review a data architecture for gaps in ownership, quality, security and retention."],"mustNot":["Design data flows that move personal data to places or parties without a legal basis.","Change production schemas or integrations without the owner's approval and a rollback plan.","Document or expose sensitive systems to people not authorized to see them.","Remove access controls or audit logging to simplify a design."],"requiresHuman":["Migrating, merging or deleting a data store others depend on.","Decisions that change who can access personal data."]},"ethics":{"considerations":["Data architecture decides who sees whose data; privacy depends on it.","Poor design can lock in bias, errors and lost records for years."],"affectedParties":["People whose data is held","Staff using the systems","The organization"]},"owners":{"steward":"The organization that holds the data; a data owner or architect answers for its design.","roles":[],"masterSystems":[]},"relations":[{"target":"Q6030887","type":"parent","note":"registry parent class"}],"interaction":{"identity":{"applicability":"required","items":["Vercy registry: vr.tr.data-architecture","Wikidata: Q638422 (https://www.wikidata.org/wiki/Q638422)"]},"properties":{"applicability":"not-applicable","items":["Referent type: discipline; organisational architecture; system architecture; architecture description","Architectural boundary: Named organisations, business domains, systems, data domains and external interfaces","Representation level: conceptual; logical; physical; explicitly mapped combination","Architecture baseline: observed current state; proposed target state; approved target state; transitional state; retired baseline","Data authority allocation: Data entity or attribute linked to its authoritative producer, accountable owner and permitted replicas","Integration pattern: batch transfer; request-response; event distribution; replication; federation; mixed, specified per flow","Required data freshness: Maximum permitted age in seconds, minutes or days, with reference event and consumer specified","Required recovery point: Maximum tolerable data-loss window in time units, specified per data service","Critical-flow lineage coverage: Percentage of explicitly enumerated critical flows with verified producer-to-consumer lineage","Implementation conformance: unassessed; conformant within assessed scope; approved exceptions; unresolved deviations"]},"recognition":{"applicability":"not-applicable","items":[]},"capabilities":{"applicability":"required","items":["Map information requirements to data domains, authoritative sources and consumer interfaces.","Compare architectural alternatives against explicit freshness, consistency, protection and recovery requirements.","Trace the impact of a schema, identifier or source-system change across dependent data flows.","Identify duplicated authority, incompatible meanings and undocumented transformations.","Assess implementation evidence against an approved architecture and record exceptions.","Propose dependency-aware migration steps with reconciliation and retirement criteria."]},"hazards":{"applicability":"required","items":["Inconsistent definitions and incompatible data structures can produce misleading reports and unreliable automated decisions.","Poorly designed access boundaries can expose confidential or personal information.","Unclear ownership and undocumented dependencies can make changes cause outages or data loss.","Architectures that ignore retention and deletion requirements can leave organisations unable to meet their information governance obligations."]},"interfaces":{"applicability":"required","items":["ISO/IEC/IEEE 42010, Systems and software engineering - Architecture description, issued jointly by ISO, IEC and IEEE."]},"context":{"applicability":"required","items":["Data architecture is used when organisations plan how information moves between operational systems, analytical platforms, and external partners.","It guides decisions about data models, storage, integration, access, and ownership during system development and organisational change."]}},"sources":[{"title":"Wikidata item Q638422: data architecture","url":"https://www.wikidata.org/wiki/Q638422","note":"identity and sense of the item"},{"title":"Wikipedia: Data architecture","url":"https://en.wikipedia.org/wiki/Data_architecture","note":"general description of the item"}],"openQuestions":["Does this registry entry primarily denote the discipline of data architecture, a particular architectural arrangement, or both?","Which existing Vercy world model, if any, already covers this concept and should remain its single source of truth?","Which authoritative definitions and professional conventions should establish boundaries with data management, enterprise architecture and information architecture?","Which classification codes, learned societies, curricula and defining handbooks explicitly recognise data architecture rather than only a broader field?","How should architecture quality be evaluated across centralised and federated arrangements without assuming that one topology is inherently preferable?"],"resources":{"spec":"/models/things/publications/thing-q638422/spec.json"},"provenance":{"origin":"thing registry research (pass 2)","builtFrom":["models/things/publications/thing-q638422/spec.json"],"providers":["Codex"],"researchStatus":"unreviewed","generatedAt":"2026-09-12T09:00:59Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"not-applicable","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"_gate":"Published through the thing publication gate 1.0 on 2026-10-07T12:16:34+00:00: completeness 1.00; sense: Wikidata description; 2 live sources; review by codex: pass","interaction.properties":"Plane INF: no invented physical properties.","interaction.recognition":"Data architecture is an abstract discipline and design framework that cannot be identified from visual appearance alone."},"score":1.0}}