{ "model": { "rank": 6874, "code": "thing-q145490", "model_id": "vr.tr.network-topology", "name": "network topology", "purpose": "Enable an agent to recognise a network's arrangement of nodes and connections, assess structural constraints and vulnerabilities, and identify topology changes that warrant further validation.", "family": "Thing Registry", "category": "Information and virtual systems", "status": "research-draft", "kind": "thing", "plane": "INF", "domain": "INF.KNW", "industry": "", "version": "", "url": "/models/thing/q145490/", "tier": 2, "score": 58, "payload": { "layer": "wikidata", "aliases": [ "tree topology", "mesh networking", "fully connected network", "flat neighborhood network", "ring network", "bus network", "star network" ], "aliasCount": 7, "merged": 7, "knownIn": 58, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q145490", "url": "https://www.wikidata.org/wiki/Q145490", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T23:41:09Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 18.9, "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: 01a0888b-2644-73f0-a02b-5a99445fb4f3\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: network topology\nSense to describe: (none recorded)\nDomain code: INF.MED\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 007: 100", "usd": 0, "recall": true }, "codex": { "seconds": 53.9, "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: 01a0888b-263b-7ea3-a413-230a8231c1d6\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: network topology\nRegistry id: vr.tr.network-topology\nPlane / domain: INF / INF.MED\nRegistry definition: (none recorded)\nNames folded into this entry:" } } }, "metaModel": { "id": "THING-Q145490", "registryId": "vr.tr.network-topology", "name": "network topology", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.MED" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q145490/", "model": { "registry_id": "vr.tr.network-topology", "name": "network topology", "purpose": "Enable an agent to recognise a network's arrangement of nodes and connections, assess structural constraints and vulnerabilities, and identify topology changes that warrant further validation.", "definition": "Network topology is the arrangement of nodes and links in a communication network, describing either their physical interconnection or their logical connectivity at a specified network layer.", "scope_statement": "This model owns the physical or logical arrangement of a communications network within an explicit boundary, layer and time interval, including how that arrangement is represented and evidenced; it provisionally interprets the undefined registry entry as communications-network topology.", "in_scope": [ "Network boundary, included nodes, connection endpoints and external attachment points", "Physical, logical and overlay topology views and their mappings", "Connection direction, multiplicity, shared-medium structure and structural patterns", "Structural connectivity, path alternatives and failure dependencies", "Observed, intended and historical topology states with evidence and uncertainty", "Proposed structural changes and the conditions for validating them" ], "out_of_scope": [ "Hardware specifications, procurement and lifecycle of individual network devices", "Packet formats and detailed routing or switching protocol behaviour", "Traffic demand, application behaviour and measured service performance", "Security policies, credentials and authorisation decisions", "Cable materials, civil engineering and facility construction", "General mathematical topology and networks outside the adopted communications scope" ], "distinguishing_features": [ "Describes which endpoints are connected at a stated layer; a device inventory alone does not establish a topology.", "Distinguishes installed connections from logical adjacencies: a logical connection may traverse several physical links.", "Represents structural path possibilities; a routing table describes selected forwarding behaviour and may expose only part of that structure.", "Retains node and connection meaning independently of drawing coordinates; moving symbols on a diagram does not necessarily change topology.", "Requires an explicit scope and observation interval; disconnected components in a partial map do not by themselves establish a network outage." ], "characteristics": [ { "name": "Topology view", "kind": "category", "unit_or_values": "physical, logical, overlay; specify represented network layer", "why_it_matters": "Determines what counts as a node, connection and valid structural inference." }, { "name": "Boundary membership", "kind": "relation", "unit_or_values": "included nodes and segments, excluded regions, external attachment points", "why_it_matters": "Prevents conclusions about a mapped subset from being applied to an entire network." }, { "name": "Connection semantics", "kind": "category", "unit_or_values": "directed or undirected; point-to-point or shared medium; single or parallel", "why_it_matters": "Controls how adjacency and paths can be interpreted." }, { "name": "Node and connection counts", "kind": "measurement", "unit_or_values": "counts under a declared node, link and shared-segment counting convention", "why_it_matters": "Supports comparison between snapshots without confusing representation changes with network growth." }, { "name": "Node degree", "kind": "measurement", "unit_or_values": "incident-connection count per node; in-degree and out-degree for directed views", "why_it_matters": "Identifies attachment concentration and structurally isolated nodes." }, { "name": "Structural pattern", "kind": "category", "unit_or_values": "point-to-point, star, ring, bus, tree, partial mesh, full mesh, hybrid or unclassified", "why_it_matters": "Summarises arrangement while requiring the underlying connections to support the label." }, { "name": "Structural connectivity", "kind": "measurement", "unit_or_values": "component count; weak or strong components for directed graphs; pairwise path existence", "why_it_matters": "Shows which endpoints can be connected structurally under the declared interpretation." }, { "name": "Failure dependency", "kind": "relation", "unit_or_values": "nodes and connections mapped to shared devices, media, conduits, power supplies or other failure domains", "why_it_matters": "Reveals when apparently separate paths share a cause of failure." }, { "name": "Realisation state", "kind": "state", "unit_or_values": "intended, observed, reconciled or disputed; with validity interval", "why_it_matters": "Prevents a design or stale observation from being treated as the current arrangement." }, { "name": "Evidence coverage", "kind": "state", "unit_or_values": "complete within declared scope, partial or unknown; with observation timestamps and unresolved adjacencies", "why_it_matters": "Qualifies conclusions that depend on missing or outdated topology information." } ], "affordances": [ "Construct and compare physical, logical and overlay views using explicit endpoint identities.", "Trace candidate structural paths and identify the additional forwarding evidence needed to establish usable connectivity.", "Locate isolated components, articulation points and bridge connections within a declared graph view.", "Assess alternative paths against node, link and shared-failure dependencies.", "Compare intended and observed snapshots to identify additions, removals and disputed connections.", "Evaluate proposed node or connection changes and define structural checks for validation and rollback." ] }, "sources": [], "structure": { "bundles": [ { "id": "topology-boundary-and-views", "name": "Topology boundary and views", "description": "Establishes which network arrangement is represented and what its elements mean.", "rationale": "Connectivity conclusions are unreliable when network boundaries or abstraction layers are mixed.", "layers": [ { "id": "network-membership", "name": "Network membership", "description": "Defines the mapped region and the treatment of its interfaces with other networks.", "findings": [ { "id": "included-elements-and-external-attachments", "name": "Included elements and external attachments", "description": "Record the membership rule, included elements and boundary connections, including any omitted or opaque regions.", "questions": [ { "text": "Which devices, interfaces, segments or virtual endpoints count as nodes in this topology?", "kind": "definition", "id": "included-elements-and-external-attachments-q01" }, { "text": "Where does the mapped network end, and how are connections into excluded regions represented?", "kind": "boundary", "id": "included-elements-and-external-attachments-q02" } ] } ] }, { "id": "physical-logical-and-overlay-views", "name": "Physical, logical and overlay views", "description": "Separates arrangements at different layers and connects them through explicit mappings.", "findings": [ { "id": "view-semantics-and-underlay-mapping", "name": "View semantics and underlay mapping", "description": "Record the represented layer and known mappings from logical or overlay elements to their supporting network structure.", "questions": [ { "text": "Does an edge mean an installed physical connection, a layer-specific adjacency or an overlay relationship?", "kind": "definition", "id": "view-semantics-and-underlay-mapping-q01" }, { "text": "What evidence maps each logical connection to its underlying nodes and links, and where is that mapping unknown?", "kind": "provenance", "id": "view-semantics-and-underlay-mapping-q02" } ] } ] } ] }, { "id": "adjacency-and-structural-patterns", "name": "Adjacency and structural patterns", "description": "Captures connection semantics and the patterns supported by actual adjacency.", "rationale": "Topology labels alone cannot describe parallel links, shared media, directionality or hybrid arrangements.", "layers": [ { "id": "connection-representation", "name": "Connection representation", "description": "Defines endpoint identity and how different connection forms are represented.", "findings": [ { "id": "endpoint-and-medium-semantics", "name": "Endpoint and medium semantics", "description": "Record connection endpoints, direction and multiplicity, and represent shared media without implying unsupported independent links.", "questions": [ { "text": "Which exact endpoints participate in each connection, and is that relationship directed or bidirectional?", "kind": "definition", "id": "endpoint-and-medium-semantics-q01" }, { "text": "Are parallel links and multi-access segments represented explicitly, aggregated, or expanded into pairwise edges?", "kind": "boundary", "id": "endpoint-and-medium-semantics-q02" } ] } ] }, { "id": "pattern-and-scale", "name": "Pattern and scale", "description": "Describes local and overall arrangement using reproducible structural measures.", "findings": [ { "id": "pattern-supported-by-adjacency", "name": "Pattern supported by adjacency", "description": "Associate pattern labels with the subgraphs and counting conventions that support them, allowing mixed structures.", "questions": [ { "text": "Which observed adjacencies justify a star, ring, tree, bus or mesh label, and to which subgraph does that label apply?", "kind": "definition", "id": "pattern-supported-by-adjacency-q01" }, { "text": "What are the node counts, connection counts and degree distributions under the chosen representation?", "kind": "measurement", "id": "pattern-supported-by-adjacency-q02" } ] } ] } ] }, { "id": "connectivity-and-failure-structure", "name": "Connectivity and failure structure", "description": "Evaluates structural paths, separation and dependencies that affect continuity.", "rationale": "An agent must distinguish graph connectivity from operational reachability and apparent redundancy from independent alternatives.", "layers": [ { "id": "components-and-paths", "name": "Components and paths", "description": "Examines structural connectivity for specified endpoints and edge-selection rules.", "findings": [ { "id": "structural-path-availability", "name": "Structural path availability", "description": "Record components and candidate paths while identifying the operational facts needed to determine whether traffic can use them.", "questions": [ { "text": "Which components and endpoint-to-endpoint paths exist when only connections eligible for this analysis are included?", "kind": "measurement", "id": "structural-path-availability-q01" }, { "text": "Which forwarding, policy or operational-state facts remain necessary before a structural path can be treated as usable?", "kind": "boundary", "id": "structural-path-availability-q02" } ] } ] }, { "id": "cuts-and-shared-failures", "name": "Cuts and shared failures", "description": "Examines elements and common dependencies whose loss could separate required endpoints.", "findings": [ { "id": "independence-of-alternative-paths", "name": "Independence of alternative paths", "description": "Identify relevant cuts and assess path alternatives against declared failure scenarios, including shared supporting infrastructure.", "questions": [ { "text": "Which node or connection removals would disconnect the endpoint pairs that must remain connected?", "kind": "measurement", "id": "independence-of-alternative-paths-q01" }, { "text": "Which alternative paths share an underlying device, conduit, power source or other failure dependency?", "kind": "provenance", "id": "independence-of-alternative-paths-q02" } ] } ] } ] }, { "id": "topology-evidence-and-change", "name": "Topology evidence and change", "description": "Tracks how topology assertions are supported, reconciled and altered over time.", "rationale": "Discovered maps, design diagrams and current network arrangements can diverge, affecting every structural assessment.", "layers": [ { "id": "snapshot-evidence", "name": "Snapshot evidence", "description": "Associates topology assertions with observation methods, coverage and validity intervals.", "findings": [ { "id": "observed-versus-intended-adjacency", "name": "Observed versus intended adjacency", "description": "Record the evidence for each relevant node and connection and distinguish absent connections from unobserved ones.", "questions": [ { "text": "Which discovery output, configuration record, inspection or design document supports each asserted adjacency, and when was it obtained?", "kind": "provenance", "id": "observed-versus-intended-adjacency-q01" }, { "text": "Where do intended and observed arrangements disagree, and which missing connections may reflect incomplete discovery?", "kind": "measurement", "id": "observed-versus-intended-adjacency-q02" } ] } ] }, { "id": "structural-change-validation", "name": "Structural change validation", "description": "Defines proposed topology changes and the structural conditions they must preserve or establish.", "findings": [ { "id": "change-impact-and-postconditions", "name": "Change impact and postconditions", "description": "Describe node and connection changes, evaluate affected connectivity and dependencies, and specify validation evidence.", "questions": [ { "text": "Which nodes or connections would be added, removed or remapped, and which required paths or failure protections would change?", "kind": "action", "id": "change-impact-and-postconditions-q01" }, { "text": "Which observations will confirm the intended post-change topology, and what structural condition should trigger rollback?", "kind": "action", "id": "change-impact-and-postconditions-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": [ "No sense was recorded; this description assumes communication networks rather than mathematical topology or another application of networks.", "Physical and logical topologies can differ, and a topology description should identify its network layer and what counts as a node or link.", "The listed standards support topology discovery or control in particular network technologies; they are not universal requirements for every topology." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of network topology 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": [ "Bus", "Star", "Ring", "Mesh, including full and partial mesh", "Tree", "Hybrid" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of network topology 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": [ "IEEE 802.1AB, issued by IEEE, specifies Link Layer Discovery Protocol for discovering adjacent network devices and their connections.", "IEEE 802.1Q, issued by IEEE, specifies bridges and bridged networks, including mechanisms that control active forwarding topology.", "RFC 2328, published by the IETF, specifies OSPF Version 2, a routing protocol that maintains link-state topology information." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of network topology 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": [ "Designing local-area, wide-area and data-centre networks.", "Planning redundant paths and assessing resilience to equipment or link failures.", "Computing routes and controlling packet forwarding.", "Mapping connectivity for troubleshooting and network inventory.", "Evaluating capacity bottlenecks and expansion options." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of network topology this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "quantity": "Node degree in a simple undirected graph", "typical_range": "0 to N−1 for a network with N nodes; these are mathematical bounds, not an empirical typical range.", "unit": "incident links per node" }, { "quantity": "Graph density in a simple undirected graph", "typical_range": "0 to 1 for N greater than 1.", "unit": "dimensionless" }, { "quantity": "Hop diameter of a connected simple undirected graph", "typical_range": "1 to N−1 for N greater than 1; disconnected graphs require a separate convention.", "unit": "hops" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of network topology 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": [ "A central node or critical link can become a single point of failure.", "Insufficient path redundancy can allow failures to partition the network.", "Forwarding loops can circulate traffic and, in bridged networks, contribute to broadcast storms.", "Traffic concentrated through a few links or nodes can cause congestion.", "Apparently independent logical paths may share physical infrastructure and fail together." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of network topology 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": "Network architecture", "difference": "Architecture specifies roles, protocols and design principles; topology specifies which nodes are connected and how." }, { "name": "Routing", "difference": "Routing selects paths through a network; topology describes the connectivity on which those selections operate." }, { "name": "Network protocol", "difference": "A protocol defines rules for communication; topology describes the arrangement of communicating nodes and links." }, { "name": "Graph", "difference": "A graph is a mathematical structure that can represent topology; a network topology assigns network meaning to its nodes and links." }, { "name": "Topology in mathematics", "difference": "Mathematical topology studies spaces and continuity; communication-network topology usually concerns graph connectivity." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of network topology this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does vr.tr.network-topology cover communications networks only, or should its scope include other network arrangements?", "Does an existing Vercy world model already own this concept, requiring the registry entry to link to it?", "Which node granularity, network layers and shared-medium representations are required by the intended agent tasks?", "Which evidence sources are authoritative for observed topology, and what freshness and coverage requirements apply?", "Which endpoint pairs, failure scenarios and shared dependencies define acceptable connectivity and redundancy for a particular use?" ], "statistics": { "bundles": 5, "layers": 9, "findings": 15, "questions": 23 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "discipline or field of knowledge", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a network topology, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an agent to recognise a network's arrangement of nodes and connections, assess structural constraints and vulnerabilities, and identify topology changes that warrant further validation.", "characteristics": { "substance": "information", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "read and interpreted" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: tree topology, mesh networking, fully connected network, flat neighborhood network, ring network, bus network, star network.", "7 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 58 Wikipedia languages, which is a measure of how widely the thing is known, not of how important it is." ], "openQuestionsForResearch": [ "Which of the bundles below does a real task actually need, and which are ceremony?", "What does this thing have that the facets do not capture at all?", "Which neighbouring kind is most often confused with a network topology, and on what evidence are they told apart?" ], "whatItIsMadeOf": "content that has to be carried by something else", "physicalCharacter": [ "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "read it and act on what it says" ], "howItIsRecognised": [], "relatedModels": [ { "relation": "covers", "note": "Finer kinds folded into this entry because telling them apart needs a task that asks for it. Each is a model waiting to be split out when one does.", "targets": [ "tree topology", "mesh networking", "fully connected network", "flat neighborhood network", "ring network", "bus network", "star network" ] } ], "standing": "Described in 58 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 7 finer distinctions are held inside this entry as names rather than as separate models.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one network topology from another, and a network topology from things that resemble it.", "rationale": "Recognition comes before every other claim. Without stable identity nothing else in the model can be trusted to be about the same thing twice.", "layers": [ { "id": "naming-and-identifiers", "name": "Names and identifiers", "description": "The names this thing goes by and the identifiers that survive translation and time.", "findings": [ { "id": "preferred-name-and-aliases", "name": "Preferred name, aliases and local names", "description": "Which name to use, which names mean the same thing, and which merely sound similar.", "questions": [ { "id": "preferred-name-and-aliases-q01", "text": "What identifies and describes the name of a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "preferred-name-and-aliases-q02", "text": "Who or what asserted this about the name of a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "preferred-name-and-aliases-q03", "text": "What may an agent decide or do once the name of a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "stable-identifiers", "name": "Stable identifiers and external keys", "description": "Identifiers that keep pointing at this kind of thing across systems and languages.", "questions": [ { "id": "stable-identifiers-q01", "text": "What identifies and describes an identifier for a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stable-identifiers-q02", "text": "Who or what asserted this about an identifier for a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stable-identifiers-q03", "text": "What may an agent decide or do once an identifier for a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "classification-and-granularity", "name": "Classification and granularity", "description": "Where a network topology sits among kinds, and how finely a task needs to cut it.", "findings": [ { "id": "kind-and-parents", "name": "Kind, parents and neighbouring kinds", "description": "The classes this thing belongs to and the ones it is next to.", "questions": [ { "id": "kind-and-parents-q01", "text": "What identifies and describes the kind of a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "kind-and-parents-q02", "text": "Who or what asserted this about the kind of a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "kind-and-parents-q03", "text": "What may an agent decide or do once the kind of a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "distinguishing-features", "name": "Distinguishing features", "description": "What separates a network topology from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "distinguishing-features-q02", "text": "Who or what asserted this about what distinguishes a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "distinguishing-features-q03", "text": "What may an agent decide or do once what distinguishes a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "state-and-lifecycle", "name": "State and lifecycle", "description": "The states a network topology passes through and the events that move it between them.", "rationale": "Most decisions about a thing depend on what state it is in now, which is a claim with a time on it, not a property.", "layers": [ { "id": "lifecycle-stages", "name": "Lifecycle stages", "description": "From coming into existence to ceasing to be one of these.", "findings": [ { "id": "stages-and-transitions", "name": "Stages and transitions", "description": "The stages worth naming and what moves a network topology between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stages-and-transitions-q02", "text": "Who or what asserted this about the lifecycle of a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stages-and-transitions-q03", "text": "What may an agent decide or do once the lifecycle of a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "observations-and-status", "name": "Observations and current status", "description": "What is observed about a network topology, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a network topology is recorded so that it can be superseded rather than overwritten.", "questions": [ { "id": "observation-record-q01", "text": "What identifies and describes an observation of a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "observation-record-q02", "text": "Who or what asserted this about an observation of a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "observation-record-q03", "text": "What may an agent decide or do once an observation of a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "content-and-access", "name": "Content, encoding and access", "description": "What a network topology says, how it is encoded and who may read it.", "rationale": "An informational thing carries content that can be copied, versioned and withheld, none of which its physical carrier explains.", "layers": [ { "id": "content-and-encoding", "name": "Content and encoding", "description": "The content itself, its format and its language.", "findings": [ { "id": "content-and-format", "name": "Content, format and language", "description": "What a network topology contains and in what form it is held.", "questions": [ { "id": "content-and-format-q01", "text": "What identifies and describes the content of a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "content-and-format-q02", "text": "Who or what asserted this about the content of a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "content-and-format-q03", "text": "What may an agent decide or do once the content of a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "access-and-rights", "name": "Access, rights and retention", "description": "Who may read, copy or change it, and for how long it is kept.", "findings": [ { "id": "access-rules", "name": "Access rules and retention", "description": "The permissions attached to a network topology and the period it survives.", "questions": [ { "id": "access-rules-q01", "text": "What identifies and describes access to a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "access-rules-q02", "text": "Who or what asserted this about access to a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "access-rules-q03", "text": "What may an agent decide or do once access to a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "subject-and-method", "name": "Subject matter and method", "description": "What network topology studies and how it establishes anything.", "rationale": "A field is identified by its questions and its methods, and those are what distinguish it from the fields next to it.", "layers": [ { "id": "subject", "name": "Subject matter", "description": "The questions it takes as its own.", "findings": [ { "id": "subject-record", "name": "Questions and objects of study", "description": "What it is about, stated so a neighbouring field can be told apart.", "questions": [ { "id": "subject-record-q01", "text": "What questions and objects does network topology take as its own?", "kind": "definition" }, { "id": "subject-record-q02", "text": "Which questions does it share with a neighbouring field, and who claims them?", "kind": "boundary" } ] } ] }, { "id": "method", "name": "Method and evidence", "description": "How claims are established and what counts as evidence.", "findings": [ { "id": "method-record", "name": "Methods and standards of evidence", "description": "The methods used and what they are taken to establish.", "questions": [ { "id": "method-record-q01", "text": "By what methods does network topology establish claims, and what counts as sufficient evidence?", "kind": "provenance" }, { "id": "method-record-q02", "text": "What kind of claim can this field not settle, and where should an agent look instead?", "kind": "action" } ] } ] } ] }, { "id": "institutions-and-classification", "name": "Institutions and classification", "description": "Where network topology is practised and how catalogues place it.", "rationale": "The institutional footprint is the evidence that a field exists as a field rather than as a topic.", "layers": [ { "id": "institutions", "name": "Institutional markers", "description": "Societies, journals, degrees and departments.", "findings": [ { "id": "institution-record", "name": "Bodies and venues", "description": "Where the field organises itself.", "questions": [ { "id": "institution-record-q01", "text": "Which societies, journals or degrees mark network topology as an established field?", "kind": "provenance" }, { "id": "institution-record-q02", "text": "What would show that it is emerging or dissolving rather than established?", "kind": "boundary" } ] } ] }, { "id": "classification", "name": "Classification schemes", "description": "Where library and research classifications put it.", "findings": [ { "id": "classification-record", "name": "Codes and their disagreements", "description": "The classification codes that place it, and where they differ.", "questions": [ { "id": "classification-record-q01", "text": "Which classification schemes place network topology, under what codes?", "kind": "definition" }, { "id": "classification-record-q02", "text": "Where do those schemes disagree about its scope?", "kind": "boundary" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a network topology came from and when it held.", "rationale": "A claim without a source and a time cannot be superseded, only overwritten, and an agent that overwrites loses the ability to explain itself.", "layers": [ { "id": "source-and-authority", "name": "Source and authority", "description": "Who said it, on what evidence, and how strongly.", "findings": [ { "id": "claim-provenance", "name": "Claim provenance and confidence", "description": "The authority behind each claim about a network topology and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "claim-provenance-q02", "text": "Who or what asserted this about a claim about a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "claim-provenance-q03", "text": "What may an agent decide or do once a claim about a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "time-and-versions", "name": "Time, versions and supersession", "description": "When a claim was true, when it was learnt, and what replaced it.", "findings": [ { "id": "validity-and-supersession", "name": "Validity period and supersession", "description": "How an old claim about a network topology is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a network topology, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "validity-and-supersession-q02", "text": "Who or what asserted this about the validity of a claim about a network topology, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "validity-and-supersession-q03", "text": "What may an agent decide or do once the validity of a claim about a network topology is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 12, "findings": 14, "questions": 38 } } } }