{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T14:12:44Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 25.7, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\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: 01a07c35-884f-7ab2-a873-2d3d718a4056\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: router\nSense to describe: (none recorded)\nDomain code: PHY.OBJ\nAlso known as: (none)\n\n\nContext for this batch of 546 things:\n# Batch 003: 1001 registere", "usd": 0.0, "recall": true }, "codex": { "seconds": 87.0, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\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: 01a07c35-883d-7c20-b2b9-56a2c70296ed\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: router\nRegistry id: vr.tr.router\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\n\nContext fo" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T07:59:40+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners" ] }, "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T10:10:31+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q5318", "registryId": "vr.tr.router", "name": "router", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q5318/", "model": { "registry_id": "vr.tr.router", "name": "router", "purpose": "Enable an AI agent to recognise a physical network router, assess its forwarding and security state, and determine which configuration or maintenance actions are appropriate.", "definition": "A router, in the computer-networking sense used here, is a device that forwards packets between IP networks by selecting an outgoing interface or next hop using destination addresses and routing information.", "scope_statement": "This draft provisionally interprets router as a physical device that forwards packets between IP networks; it owns router-specific capabilities, interfaces, routing behaviour, operational evidence and action constraints at the kind level, pending confirmation that the registry does not mean a woodworking router.", "in_scope": [ "Packet forwarding between IP networks and selection of next hops", "Physical and logical interfaces, addressing and network attachment", "Route acquisition, selection, installation and withdrawal", "Management access, traffic policy and separation of routing contexts", "Capacity, power, software lifecycle and recovery of router operation" ], "out_of_scope": [ "Woodworking routers and their cutting operations", "Standalone virtual routing software and application request routers", "Network-wide topology, addressing governance and service architecture", "Switching, wireless access, modem and firewall functions except where their integration affects routing", "Vendor product catalogues, individual device inventories and service contracts as independent models" ], "distinguishing_features": [ "Determine whether the device selects next hops between IP networks, rather than only bridging frames within a link-layer network.", "Check for routing and forwarding tables; a default route can support routing without a dynamic routing protocol.", "Do not identify a router solely by Wi-Fi, Ethernet sockets, NAT or a WAN label; establish its actual routing capability and operating mode.", "Treat a multilayer switch performing IP routing as overlapping this functional kind, with its switching role represented separately.", "Confirm that the registered sense concerns packet forwarding rather than a rotating cutting tool." ], "characteristics": [ { "name": "Routing role and deployment context", "kind": "category", "unit_or_values": "Access gateway, branch, edge, core, industrial, other or unresolved; roles may overlap", "why_it_matters": "Sets expectations for connectivity, resilience and permitted operational changes." }, { "name": "Supported network-layer families", "kind": "category", "unit_or_values": "IPv4, IPv6, both or other explicitly identified support", "why_it_matters": "Determines which networks and packets the device can route." }, { "name": "Interface inventory and roles", "kind": "relation", "unit_or_values": "Physical ports and logical interfaces linked to media, network attachments and assigned roles", "why_it_matters": "Connects forwarding behaviour to actual ingress and egress paths." }, { "name": "Interface link rate", "kind": "measurement", "unit_or_values": "bit/s per interface, distinguishing supported, configured and negotiated rates", "why_it_matters": "Identifies link constraints without treating port speed as forwarding throughput." }, { "name": "Forwarding performance", "kind": "measurement", "unit_or_values": "bit/s and packets/s, with packet size, enabled features, traffic mix and test conditions", "why_it_matters": "Supports capacity judgments under the intended routing workload." }, { "name": "Route acquisition methods", "kind": "category", "unit_or_values": "Connected, static and explicitly named dynamic routing protocols; supported and enabled recorded separately", "why_it_matters": "Explains where route decisions originate and which external dependencies affect them." }, { "name": "Routing and forwarding agreement", "kind": "state", "unit_or_values": "Consistent, pending convergence, discrepant or unknown", "why_it_matters": "A selected route is insufficient evidence that packets follow the intended path." }, { "name": "Path MTU constraints", "kind": "measurement", "unit_or_values": "Bytes, with interface, tunnel and protocol context", "why_it_matters": "Helps explain size-dependent packet loss and encapsulation limits." }, { "name": "Routing context isolation", "kind": "relation", "unit_or_values": "Interfaces and routes assigned to routing instances, with explicit route-leak relationships", "why_it_matters": "Determines which networks can exchange traffic despite address overlap or separation requirements." }, { "name": "Management exposure", "kind": "state", "unit_or_values": "Enabled management services, reachable source networks and authentication controls", "why_it_matters": "Defines who can change forwarding behaviour and through which paths." }, { "name": "Power requirements", "kind": "measurement", "unit_or_values": "Input voltage in V, maximum or measured draw in W, and supply or PoE requirements where applicable", "why_it_matters": "Constrains installation, backup power and safe replacement." }, { "name": "Software and recovery readiness", "kind": "state", "unit_or_values": "Installed release, support status, configuration backup status and verified recovery method", "why_it_matters": "Determines whether updates and disruptive changes have a workable recovery path." } ], "affordances": [ "Trace an intended destination through route selection, forwarding installation and egress reachability.", "Compare configured, negotiated and observed interface behaviour to localise connectivity faults.", "Assess whether traffic load and enabled services fit measured forwarding and state-table limits.", "Evaluate and, when authorised, change routes, interfaces or traffic policies with reachability checks and rollback.", "Inspect management exposure and routing-context boundaries for unintended access or route leakage.", "Plan firmware updates, failover tests or hardware replacement around service dependencies and recovery access." ], "agent_conduct": { "may": [ "Read routing tables, interface state and logs on routers it is authorized to manage.", "Apply approved configuration changes and keep a record of each one.", "Report faults, unusual traffic and outdated firmware to the network operator." ], "must_not": [ "Access or reconfigure a router on a network it does not administer.", "Redirect, intercept or inspect traffic passing through a router without lawful authority.", "Disable logging, filtering or security updates to hide activity.", "Announce routes that hijack or blackhole other networks' address space." ], "requires_human": [ "Changes to core routing or border routes that can cut off many users.", "Restarting or replacing a router that carries emergency or critical services." ] }, "ethics": { "considerations": [ "Routers decide whether people can reach services, including emergency ones.", "Control of a router allows surveillance of everyone behind it." ], "affected_parties": [ "Network users", "Network operators", "Services reached through the network" ] }, "owners": { "steward": "The network operator or the household that owns the device.", "master_systems": [ "Regional internet registry routing records" ] }, "failure_modes_and_hazards": [ "A misconfigured route can cut off whole networks or send traffic to the wrong place.", "Default passwords and unpatched firmware let attackers take control of the device." ], "what_it_is_for": [ "Routers connect separate IP networks in homes, workplaces, data centres and telecommunications infrastructure.", "They direct traffic towards its destination and may also provide access controls, address translation and network monitoring." ], "standards_and_regulation": [ "RFC 1812, issued by the Internet Engineering Task Force, specifies requirements for routers that forward IPv4 packets.", "RFC 8200, issued by the Internet Engineering Task Force, specifies the IPv6 protocol used by routers that forward IPv6 packets." ], "visual_identification": [ "Separate network interfaces labelled WAN and LAN suggest a router, although these labels are not universal.", "A chassis identification label describing the equipment as a router provides stronger evidence than antennas or enclosure shape.", "Ethernet sockets and link indicators also occur on switches and access points, so appearance alone cannot confirm routing capability." ] }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q5318: router", "url": "https://www.wikidata.org/wiki/Q5318", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: Router (computing)", "url": "https://en.wikipedia.org/wiki/Router_%28computing%29", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "router-identity-and-boundaries", "name": "Router identity and boundaries", "description": "Establish the intended sense and separate routing capability from adjacent integrated functions.", "rationale": "The registry supplies no definition, and both the word router and network appliance labels can conceal materially different kinds.", "layers": [ { "id": "registered-sense", "name": "Registered sense", "description": "Resolve the meaning of router and the level at which the kind is represented.", "findings": [ { "id": "physical-network-router-sense", "name": "Physical network router sense", "description": "Record evidence for the provisional network-device interpretation and any existing canonical model that already owns it.", "questions": [ { "text": "Does the registry source identify an IP packet-routing device, a woodworking tool or another sense?", "kind": "definition", "id": "physical-network-router-sense-q01" }, { "text": "Does an existing world model already cover this precise sense and therefore require a link rather than another publication?", "kind": "boundary", "id": "physical-network-router-sense-q02" } ] } ] }, { "id": "routing-role-and-integration", "name": "Routing role and integration", "description": "Distinguish the routing role from functions packaged in the same enclosure.", "findings": [ { "id": "routing-capability-versus-appliance-label", "name": "Routing capability versus appliance label", "description": "Describe what establishes routing capability and which integrated functions need neighbouring models.", "questions": [ { "text": "What evidence shows that the device can select next hops and forward packets between IP networks?", "kind": "definition", "id": "routing-capability-versus-appliance-label-q01" }, { "text": "Which switching, wireless, modem, NAT or firewall functions are integrated, and which remain active when routing is disabled?", "kind": "boundary", "id": "routing-capability-versus-appliance-label-q02" } ] } ] } ] }, { "id": "interfaces-and-network-attachment", "name": "Interfaces and network attachment", "description": "Represent how packets enter and leave through physical links and logical network attachments.", "rationale": "Correct routes cannot deliver traffic when link negotiation, addressing or encapsulation is incompatible.", "layers": [ { "id": "physical-link-capabilities", "name": "Physical link capabilities", "description": "Capture media, port capabilities and observed link operation.", "findings": [ { "id": "port-and-media-compatibility", "name": "Port and media compatibility", "description": "Associate each interface type with connection requirements and operating evidence.", "questions": [ { "text": "Which connectors, media, transceivers and link standards are supported, and which issuing bodies and specification versions establish compatibility?", "kind": "provenance", "id": "port-and-media-compatibility-q01" }, { "text": "What link rate, duplex mode where applicable, error counts and flap history are observed on each active connection?", "kind": "measurement", "id": "port-and-media-compatibility-q02" } ] } ] }, { "id": "logical-attachment-and-mtu", "name": "Logical attachment and MTU", "description": "Connect interfaces to addresses, segmentation and encapsulated paths.", "findings": [ { "id": "addressing-and-packet-size-boundaries", "name": "Addressing and packet-size boundaries", "description": "Record logical attachments and the constraints they impose on reachability.", "questions": [ { "text": "How are addresses, prefixes, VLAN subinterfaces and tunnel endpoints assigned to physical interfaces and routing contexts?", "kind": "boundary", "id": "addressing-and-packet-size-boundaries-q01" }, { "text": "What interface and effective tunnel MTUs apply in bytes, and what evidence establishes behaviour for oversized packets?", "kind": "measurement", "id": "addressing-and-packet-size-boundaries-q02" } ] } ] } ] }, { "id": "route-selection-and-forwarding", "name": "Route selection and forwarding", "description": "Connect route knowledge to actual packet handling and failure response.", "rationale": "Routing correctness requires both valid route selection and successful installation and use of forwarding state.", "layers": [ { "id": "route-origins-and-selection", "name": "Route origins and selection", "description": "Explain how candidate routes arise and become selected paths.", "findings": [ { "id": "route-authority-and-preference", "name": "Route authority and preference", "description": "Identify route sources, selection policy and the evidence supporting preferred paths.", "questions": [ { "text": "Which routes originate from connected networks, static configuration or named routing peers, and what establishes their intended authority?", "kind": "provenance", "id": "route-authority-and-preference-q01" }, { "text": "How do prefix matching, route preference, protocol metrics and policy-based routing interact for the traffic being assessed?", "kind": "definition", "id": "route-authority-and-preference-q02" } ] } ] }, { "id": "forwarding-evidence-and-convergence", "name": "Forwarding evidence and convergence", "description": "Assess installed forwarding state, next-hop resolution and response to path changes.", "findings": [ { "id": "installed-path-and-failure-response", "name": "Installed path and failure response", "description": "Tie route decisions to observed packet delivery and bounded disruption.", "questions": [ { "text": "Do forwarding entries, next-hop neighbour resolution, counters and packet observations agree with the selected route?", "kind": "measurement", "id": "installed-path-and-failure-response-q01" }, { "text": "How can an authorised path-withdrawal or failover test measure convergence time and packet loss while preserving recovery access?", "kind": "action", "id": "installed-path-and-failure-response-q02" } ] } ] } ] }, { "id": "traffic-boundaries-and-router-control", "name": "Traffic boundaries and router control", "description": "Represent permitted packet flows and control over the router itself.", "rationale": "A reachable destination may still be forbidden, and access to router management can alter every attached network's connectivity.", "layers": [ { "id": "forwarded-traffic-policy", "name": "Forwarded traffic policy", "description": "Locate routing isolation, filtering and translation within packet processing.", "findings": [ { "id": "isolation-filtering-and-translation", "name": "Isolation, filtering and translation", "description": "Record supported policy mechanisms without assuming all routers provide stateful firewalling or NAT.", "questions": [ { "text": "Which routing contexts, route leaks and ingress or egress policies determine the permitted source-to-destination paths?", "kind": "boundary", "id": "isolation-filtering-and-translation-q01" }, { "text": "Where supported, how do filtering and address translation interact with route lookup, return paths and existing flow state?", "kind": "definition", "id": "isolation-filtering-and-translation-q02" } ] } ] }, { "id": "management-and-control-plane", "name": "Management and control plane", "description": "Describe access to configuration and protection of locally processed control traffic.", "findings": [ { "id": "administrative-and-routing-control-access", "name": "Administrative and routing-control access", "description": "Identify who may administer the router and which networks or peers can reach its control services.", "questions": [ { "text": "Which management services and routing adjacencies are reachable from each network, and what authentication and traffic restrictions apply?", "kind": "boundary", "id": "administrative-and-routing-control-access-q01" }, { "text": "What authorisation, configuration comparison and alternate access are required before changing management or control-plane policy?", "kind": "action", "id": "administrative-and-routing-control-access-q02" } ] } ] } ] }, { "id": "capacity-serviceability-and-recovery", "name": "Capacity, serviceability and recovery", "description": "Assess sustainable routing performance and the ability to maintain or restore service.", "rationale": "Port labels alone do not establish usable throughput, and maintenance can interrupt all networks dependent on the router.", "layers": [ { "id": "workload-and-resource-limits", "name": "Workload and resource limits", "description": "Relate traffic and enabled features to forwarding, table and environmental constraints.", "findings": [ { "id": "effective-routing-capacity", "name": "Effective routing capacity", "description": "Record capacity evidence under explicit feature and workload conditions.", "questions": [ { "text": "What throughput in bit/s and packets/s, latency and loss are supported by measurements with the intended packet sizes and enabled features?", "kind": "measurement", "id": "effective-routing-capacity-q01" }, { "text": "Which route, neighbour, queue or optional connection-state limits apply, and what observations reveal exhaustion, CPU overload or thermal throttling?", "kind": "measurement", "id": "effective-routing-capacity-q02" } ] } ] }, { "id": "installation-and-service-recovery", "name": "Installation and service recovery", "description": "Connect physical operating requirements and software changes to safe restoration of routing service.", "findings": [ { "id": "physical-operating-requirements", "name": "Physical operating requirements", "description": "Identify the requirements specific to installing and servicing the applicable router class.", "questions": [ { "text": "What dimensions, mounting clearances, input power and temperature limits apply, with units and manufacturer evidence?", "kind": "measurement", "id": "physical-operating-requirements-q01" }, { "text": "Which electrical, EMC and, if applicable, radio requirements and certification marks apply in the installation jurisdiction, and what maintenance or interlocks are documented?", "kind": "provenance", "id": "physical-operating-requirements-q02" } ] }, { "id": "software-change-and-restoration", "name": "Software change and restoration", "description": "Establish whether configuration or firmware changes can be completed and recovered without losing essential access.", "questions": [ { "text": "What evidence establishes firmware support status, update authenticity and compatibility with the installed hardware and configuration?", "kind": "provenance", "id": "software-change-and-restoration-q01" }, { "text": "What backup, console or out-of-band access, rollback method and post-change routing checks are required before an authorised update or reset?", "kind": "action", "id": "software-change-and-restoration-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, and PHY.OBJ fits both networking and woodworking routers; this description provisionally selects the networking sense.", "Standards are recalled references, not researched sources; applicability depends on implemented protocols and interfaces.", "Measurement ranges describe selected compact-device classes, not the whole category; forwarding throughput must be assessed separately from nominal port speed." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of router 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": [ "Residential gateway router", "Enterprise branch router", "Provider edge router", "Core router", "Industrial router", "Cellular router" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of router this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "scheme": "Manufacturer model and serial number", "value_or_pattern": "Manufacturer-specific model designation and unit serial number", "note": "Identify a product model and an individual device respectively; neither identifies the general kind." }, { "scheme": "IP interface address", "value_or_pattern": "IPv4: four decimal octets; IPv6: colon-separated hexadecimal groups", "note": "Identifies an addressed interface within a network context, not a permanent hardware identity." }, { "scheme": "IEEE MAC address", "value_or_pattern": "48-bit address, commonly written as six hexadecimal octets", "note": "Applies to Ethernet and Wi-Fi interfaces; a router can have several, and addresses may be locally assigned." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of router 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": [ "IETF RFC 1812: Requirements for IP Version 4 Routers.", "IETF RFC 8200: Internet Protocol, Version 6 (IPv6) Specification.", "IETF RFC 4271: A Border Gateway Protocol 4 (BGP-4), applicable to routers implementing BGP.", "IEEE 802.3: Ethernet, applicable to Ethernet interfaces.", "IEEE 802.11: Wireless LAN standards, applicable when Wi-Fi functionality is integrated." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of router 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": [ "Connecting a home or office network to an internet service provider.", "Connecting enterprise subnets, sites and wide-area networks.", "Exchanging traffic and routing information between autonomous systems.", "Forwarding traffic through service-provider backbone networks.", "Providing connectivity for industrial equipment or remote sites over wired or cellular links." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of router 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": "Nominal Ethernet port data rate", "typical_range": "1-10 for many home and small-office devices; enterprise and carrier interfaces can be substantially faster", "unit": "Gbit/s" }, { "quantity": "Electrical power consumption", "typical_range": "Approximately 5-30 for compact home routers, depending on radios, interfaces and load", "unit": "W" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of router 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": [ "Incorrect routes or routing loops cause dropped packets, unreachable destinations or traffic sent along unintended paths.", "Congestion or exhaustion of forwarding, connection-tracking or routing resources causes loss and increased latency.", "Power-supply failure, overheating or interface failure interrupts connectivity.", "Vulnerable firmware, exposed administration interfaces or compromised credentials can permit unauthorized control and traffic interception.", "Incorrect filtering, segmentation or address-translation configuration can expose services or block legitimate traffic." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of router 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": [ "Integrated Wi-Fi and cellular radios are subject to jurisdiction-specific spectrum, channel and transmit-power rules.", "Electrical safety, electromagnetic compatibility and radio-equipment conformity requirements depend on the market.", "Available access technologies and service-provider authentication or configuration requirements vary by region and provider." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of router 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": "Ethernet switch", "difference": "A Layer 2 switch forwards Ethernet frames using MAC-address information; a router forwards IP packets between networks. A multilayer switch can perform both functions." }, { "name": "Modem", "difference": "A modem performs modulation and demodulation for an access link; routing selects where packets go. One enclosure may provide both." }, { "name": "Wireless access point", "difference": "An access point connects wireless stations to a network, usually through bridging; routing between IP networks is a separate function." }, { "name": "Firewall", "difference": "A firewall enforces traffic-access policy; a router selects packet-forwarding paths. Devices commonly combine these functions." }, { "name": "Woodworking router", "difference": "A woodworking router uses a rotating cutter to shape material and is an unrelated physical-tool sense of the same word." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of router this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does vr.tr.router denote a network router or a woodworking router, and which original registry source resolves that ambiguity?", "Does an existing world-model publication already own the confirmed concept, requiring this registry entry to link to it?", "How should the canonical model relate physical routers, virtual routers and multilayer switches without duplicating shared routing semantics?", "Which deployment classes need distinct capacity, resilience and maintenance questions, and which authoritative sources establish their meaningful ranges?", "Which protocol specifications, installation standards and jurisdiction-dependent certifications should be researched for the confirmed scope?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 20, "questions": 31 } }