{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T09:00:59Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 22.0, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a094d8-0f9a-7b70-b086-ba8ca5dc761f\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: data architecture\nSense to describe: (none recorded)\nDomain code: INF.KNW\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 043: 10", "usd": 0.0, "recall": true }, "codex": { "seconds": 77.1, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a094d8-0fa5-7000-ae58-d6ae06407171\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: data architecture\nRegistry id: vr.tr.data-architecture\nPlane / domain: INF / INF.KNW\nRegistry definition: (none recorded)\nNames folded into this entr" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:39:52+00:00", "fields": [ "agent_conduct", "ethics", "owners", "standards_and_regulation" ] }, "revisions": [ { "at": "2026-10-07T11:37:45+00:00", "engine": "codex", "fields": [ "definition", "distinguishing_features", "in_scope", "scope_statement" ], "answering_review": "189880a56f115df2518798f2f908ee058f447ef6c947e01bcd5c53c3a1dd4814" } ], "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T12:16:34+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q638422", "registryId": "vr.tr.data-architecture", "name": "data architecture", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.KNW" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q638422/", "model": { "registry_id": "vr.tr.data-architecture", "name": "data architecture", "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.", "definition": "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.", "scope_statement": "This model owns data architecture as the framework describing an organisation's or system's data structures, interrelationships, flows, responsibilities and lifecycle constraints, distinguishing architectural intent from deployed implementation.", "in_scope": [ "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_of_scope": [ "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" ], "distinguishing_features": [ "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." ], "characteristics": [ { "name": "Referent type", "kind": "category", "unit_or_values": "discipline; organisational architecture; system architecture; architecture description", "why_it_matters": "Prevents confusion between the field of practice, an actual arrangement and a document describing it." }, { "name": "Architectural boundary", "kind": "relation", "unit_or_values": "Named organisations, business domains, systems, data domains and external interfaces", "why_it_matters": "Determines which data decisions the architecture owns and which require coordination." }, { "name": "Representation level", "kind": "category", "unit_or_values": "conceptual; logical; physical; explicitly mapped combination", "why_it_matters": "Prevents implementation details from being mistaken for stable business meanings." }, { "name": "Architecture baseline", "kind": "state", "unit_or_values": "observed current state; proposed target state; approved target state; transitional state; retired baseline", "why_it_matters": "Separates what exists from what is intended or authorised." }, { "name": "Data authority allocation", "kind": "relation", "unit_or_values": "Data entity or attribute linked to its authoritative producer, accountable owner and permitted replicas", "why_it_matters": "Makes conflicting updates and inconsistent copies assessable." }, { "name": "Integration pattern", "kind": "category", "unit_or_values": "batch transfer; request-response; event distribution; replication; federation; mixed, specified per flow", "why_it_matters": "Exposes differences in coupling, freshness and failure behaviour." }, { "name": "Required data freshness", "kind": "measurement", "unit_or_values": "Maximum permitted age in seconds, minutes or days, with reference event and consumer specified", "why_it_matters": "Connects information needs to feasible movement and processing arrangements." }, { "name": "Required recovery point", "kind": "measurement", "unit_or_values": "Maximum tolerable data-loss window in time units, specified per data service", "why_it_matters": "Constrains replication, backup and recovery architecture." }, { "name": "Critical-flow lineage coverage", "kind": "measurement", "unit_or_values": "Percentage of explicitly enumerated critical flows with verified producer-to-consumer lineage", "why_it_matters": "Shows whether change impact and data provenance can be assessed across the declared boundary." }, { "name": "Implementation conformance", "kind": "state", "unit_or_values": "unassessed; conformant within assessed scope; approved exceptions; unresolved deviations", "why_it_matters": "Prevents an approved diagram from being treated as evidence of implementation." } ], "affordances": [ "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." ], "agent_conduct": { "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." ], "must_not": [ "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." ], "requires_human": [ "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." ], "affected_parties": [ "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.", "master_systems": [] }, "standards_and_regulation": [ "ISO/IEC/IEEE 42010, Systems and software engineering - Architecture description, issued jointly by ISO, IEC and IEEE." ], "what_it_is_for": [ "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." ], "failure_modes_and_hazards": [ "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." ], "facets_not_applicable": { "recognition": "Data architecture is an abstract discipline and design framework that cannot be identified from visual appearance alone." } }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q638422: data architecture", "url": "https://www.wikidata.org/wiki/Q638422", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Data architecture", "url": "https://en.wikipedia.org/wiki/Data_architecture", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "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.", "rationale": "The registered term can denote a discipline or a particular architecture; an agent must resolve that ambiguity before assessing it.", "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?", "kind": "definition", "id": "declared-architectural-convention-q01" }, { "text": "Which handbook, framework or institutional source supplies the adopted definition and methods?", "kind": "provenance", "id": "declared-architectural-convention-q02" } ] } ] }, { "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?", "kind": "boundary", "id": "allocation-of-architectural-responsibility-q01" }, { "text": "Which classification schemes, curricula or professional institutions explicitly recognise this field, and how do they place it?", "kind": "provenance", "id": "allocation-of-architectural-responsibility-q02" } ] } ] } ] }, { "id": "data-meaning-and-structure", "name": "Data meaning and structure", "description": "Captures the meanings, identities and structural relationships that data implementations must preserve.", "rationale": "Technically connected systems can still exchange incompatible information when meanings or identifiers differ.", "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?", "kind": "definition", "id": "concept-boundaries-and-mappings-q01" }, { "text": "Where does an apparently shared term denote different concepts, populations or levels of aggregation?", "kind": "boundary", "id": "concept-boundaries-and-mappings-q02" } ] } ] }, { "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?", "kind": "definition", "id": "identifier-and-schema-continuity-q01" }, { "text": "What mappings preserve relationships and historical meaning when logical or physical schemas change?", "kind": "action", "id": "identifier-and-schema-continuity-q02" } ] } ] } ] }, { "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.", "rationale": "Data architecture must make distributed responsibilities and exchange consequences explicit.", "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?", "kind": "definition", "id": "authoritative-data-and-replicas-q01" }, { "text": "Why is each replica, cache or analytical copy needed, and who resolves conflicts between copies?", "kind": "boundary", "id": "authoritative-data-and-replicas-q02" } ] } ] }, { "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?", "kind": "definition", "id": "flow-semantics-and-coupling-q01" }, { "text": "How are contract changes introduced and incompatible consumers identified before release?", "kind": "action", "id": "flow-semantics-and-coupling-q02" } ] } ] } ] }, { "id": "data-lifecycle-and-controls", "name": "Data lifecycle and controls", "description": "Translates ownership, protection and lifecycle obligations into architectural arrangements.", "rationale": "Controls must follow data through copies and transformations, not merely apply to its original store.", "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?", "kind": "provenance", "id": "policy-to-control-mapping-q01" }, { "text": "At which stores, interfaces and transformations are those requirements enforced and verified?", "kind": "action", "id": "policy-to-control-mapping-q02" } ] } ] }, { "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?", "kind": "measurement", "id": "derivation-and-disposition-q01" }, { "text": "How do retention expiry, deletion and authorised preservation requirements propagate to replicas, extracts and backups?", "kind": "action", "id": "derivation-and-disposition-q02" } ] } ] } ] }, { "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.", "rationale": "An architecture can be structurally coherent yet fail the needs of its consumers.", "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?", "kind": "measurement", "id": "quality-thresholds-and-checkpoints-q01" }, { "text": "Where are invalid or late data rejected, quarantined, corrected or exposed with qualifications?", "kind": "action", "id": "quality-thresholds-and-checkpoints-q02" } ] } ] }, { "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?", "kind": "measurement", "id": "disruption-and-reconciliation-q01" }, { "text": "How are replayed events, partial writes and conflicting replicas reconciled after interruption?", "kind": "action", "id": "disruption-and-reconciliation-q02" } ] } ] } ] }, { "id": "architectural-change-and-evidence", "name": "Architectural change and evidence", "description": "Connects architectural intent to observed implementation and controlled evolution.", "rationale": "An agent needs evidence and transition constraints to propose changes without mistaking a target design for current reality.", "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?", "kind": "boundary", "id": "architecture-to-implementation-trace-q01" }, { "text": "What dated evidence supports conformance claims and identifies approved exceptions or unresolved deviations?", "kind": "provenance", "id": "architecture-to-implementation-trace-q02" } ] } ] }, { "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?", "kind": "boundary", "id": "safe-data-transition-q01" }, { "text": "What reconciliation, cutover and rollback evidence is required before authority transfers or an old store is retired?", "kind": "action", "id": "safe-data-transition-q02" } ] } ] } ] }, { "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.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "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.", "evidence": [ "The term can denote both a design discipline and the resulting architecture; no registry sense was supplied.", "The listed varieties overlap and are common scope distinctions rather than a universal taxonomy.", "Standards and frameworks are recalled without source verification; applicability and current editions require checking." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of data architecture this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Enterprise data architecture", "Solution data architecture", "Operational data architecture", "Analytical data architecture" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of data architecture this model covers, and on what evidence?", "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.", "evidence": [ "ISO/IEC/IEEE 42010, Architecture description, provides a framework for describing architectures, including data-related viewpoints.", "ISO/IEC 11179, Metadata registries, provides standards for registering and managing metadata.", "ISO/IEC 25012, Data quality model, defines quality characteristics relevant to data requirements.", "The Open Group Architecture Framework (TOGAF) includes data architecture within enterprise architecture.", "DAMA International's DAMA-DMBOK provides a data-management knowledge framework that includes data architecture; it is guidance rather than regulation." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of data architecture this model covers, and on what evidence?", "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.", "evidence": [ "Aligning shared data structures and flows with organisational capabilities and information needs.", "Designing integration among applications, databases and external data providers.", "Planning data warehouses, data lakes and analytical platforms.", "Guiding system consolidation, migration and modernisation.", "Designing for data ownership, lineage, quality, access control and retention requirements." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of data architecture this model covers, and on what evidence?", "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.", "evidence": [ "Incompatible definitions and identifiers produce conflicting records across systems.", "Uncontrolled duplication causes inconsistent data and unclear authoritative sources.", "Missing ownership, metadata or lineage makes data difficult to interpret and govern.", "Poor access boundaries and retention design expose sensitive data or preserve it unnecessarily.", "Excessive coupling or unsuitable storage and integration choices undermine scalability, reliability and adaptability." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of data architecture this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Privacy, data-localisation and cross-border transfer requirements vary by jurisdiction and constrain deployment and data flows." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of data architecture this model covers, and on what evidence?", "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.", "evidence": [ { "name": "Data modelling", "difference": "Data modelling specifies entities, relationships and constraints; data architecture also addresses their distribution, integration, lifecycle and supporting platforms." }, { "name": "Database design", "difference": "Database design specifies a particular database's logical and physical organisation; data architecture coordinates data across systems and organisational boundaries." }, { "name": "Data engineering", "difference": "Data engineering builds and operates data pipelines and platforms; data architecture defines the structures, principles and relationships that guide their design." }, { "name": "Data governance", "difference": "Data governance establishes decision rights, accountability and policies; data architecture translates relevant requirements into structural and technical arrangements." }, { "name": "Enterprise architecture", "difference": "Enterprise architecture coordinates business, information, application and technology concerns; data architecture focuses on data within that wider scope." }, { "name": "Information architecture", "difference": "In user-experience practice, information architecture concerns organising and labelling information for navigation and retrieval; enterprise usage can overlap substantially with data architecture." } ], "questions": [ { "id": "evidence-neighbours-q01", "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?", "kind": "provenance" } ] } ] } ] } ] }, "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?" ], "statistics": { "bundles": 7, "layers": 13, "findings": 19, "questions": 31 } }