{ "model": { "rank": 3849, "code": "thing-q8795", "model_id": "vr.tr.internet-protocol", "name": "Internet Protocol", "purpose": "Enable an AI agent to recognise Internet Protocol specifications and deployments, assess packet-delivery constraints, and determine compatible and authorised network actions.", "family": "Thing Registry", "category": "Information and virtual systems", "status": "research-draft", "kind": "thing", "plane": "INF", "domain": "INF.KNW", "industry": "", "version": "", "url": "/models/thing/q8795/", "tier": 2, "score": 81, "payload": { "layer": "wikidata", "aliases": [ "IPv6", "IP addressing", "ephemeral port", "traffic volume", "garlic routing" ], "aliasCount": 5, "merged": 5, "knownIn": 81, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q8795", "url": "https://www.wikidata.org/wiki/Q8795", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T18:54:11Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 29.7, "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: 01a08784-44ce-7793-abf7-af4cfee17652\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: Internet Protocol\nSense to describe: (none recorded)\nDomain code: INF.KNW\nAlso known as: (none)\n\n\nContext for this batch of 695 things:\n# Batch 004: 100", "usd": 0, "recall": true }, "codex": { "seconds": 64.2, "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: 01a08784-44bf-7b13-9fa8-7ddf145ce119\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: Internet Protocol\nRegistry id: vr.tr.internet-protocol\nPlane / domain: INF / INF.KNW\nRegistry definition: (none recorded)\nNames folded into this entr" } } }, "metaModel": { "id": "THING-Q8795", "registryId": "vr.tr.internet-protocol", "name": "Internet Protocol", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.KNW" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q8795/", "model": { "registry_id": "vr.tr.internet-protocol", "name": "Internet Protocol", "purpose": "Enable an AI agent to recognise Internet Protocol specifications and deployments, assess packet-delivery constraints, and determine compatible and authorised network actions.", "definition": "Internet Protocol (IP) is a network-layer protocol that specifies addressing and best-effort delivery of datagrams across interconnected networks without guaranteeing delivery, ordering, or freedom from duplication.", "scope_statement": "This model owns Internet Protocol (IP) as a network-layer protocol family, including IPv4 and IPv6, their addressing and datagram semantics, and the deployment conditions needed to assess their operation; it treats IP as a technical specification rather than a discipline of knowledge.", "in_scope": [ "Identification of IPv4 or IPv6 and the applicable specification profile", "IP address semantics, prefixes, scope and interface assignment", "Datagram headers, payload identification and extension mechanisms", "Forwarding, delivery constraints, packet lifetime and fragmentation", "IP interoperability, diagnostic evidence and security boundaries" ], "out_of_scope": [ "The Internet as a global infrastructure and institutional ecosystem", "Transport-layer reliability, congestion control and application sessions", "Routing-protocol algorithms and their independent operational state", "Physical media and link-layer framing or medium access", "DNS naming and application-level resource identification", "The discipline of computer networking and its practitioners or literature" ], "distinguishing_features": [ "IP provides network-layer datagram addressing and forwarding across interconnected networks; Ethernet provides link-layer delivery.", "IP delivery does not itself guarantee arrival, ordering or freedom from duplication; transport protocols may supply additional guarantees.", "An IP address identifies an addressable network attachment within an addressing context, not necessarily a unique physical device or person.", "IPv4 and IPv6 are versions within this entry, with distinct packet formats and addressing rules; they are not directly interchangeable on the wire.", "IP forwarding uses routing information but does not itself specify how routing protocols discover and distribute routes." ], "characteristics": [ { "name": "Protocol version", "kind": "category", "unit_or_values": "IPv4 | IPv6", "why_it_matters": "Determines address width, header interpretation and forwarding rules." }, { "name": "Applicable specification profile", "kind": "relation", "unit_or_values": "Base specification and relevant updates, extensions and implementation requirements", "why_it_matters": "Makes conformance claims traceable to an explicit technical baseline." }, { "name": "Address width", "kind": "measurement", "unit_or_values": "32 bits for IPv4; 128 bits for IPv6", "why_it_matters": "Constrains address representation and prefix interpretation." }, { "name": "Address role and scope", "kind": "category", "unit_or_values": "Version-specific unicast, multicast, anycast or broadcast role where applicable; scope and special-purpose status", "why_it_matters": "Determines valid destinations and where an address may be used." }, { "name": "Interface address assignment", "kind": "relation", "unit_or_values": "Address and prefix associated with an interface, routing context and observation time", "why_it_matters": "Prevents an address from being mistaken for a persistent device identity." }, { "name": "Path MTU", "kind": "measurement", "unit_or_values": "Octets; measured or inferred for a specified path and time", "why_it_matters": "Constrains packet size and exposes delivery problems caused by fragmentation or missing feedback." }, { "name": "Packet lifetime control", "kind": "measurement", "unit_or_values": "IPv4 Time to Live or IPv6 Hop Limit field value", "why_it_matters": "Limits continued forwarding and supports interpretation of expiry diagnostics." }, { "name": "Observed reachability", "kind": "state", "unit_or_values": "Confirmed for a specified test | failed for a specified test | unknown", "why_it_matters": "Separates observed delivery from assumptions based on address assignment or route presence." } ], "affordances": [ "Classify an IP packet or configuration by version and applicable specification profile.", "Validate address, prefix and scope compatibility within a stated routing context.", "Inspect datagram structure and identify malformed or unsupported header combinations.", "Assess likely forwarding and packet-size constraints using routes, MTU evidence and diagnostics.", "Plan authorised connectivity tests and distinguish observed failures from untested hypotheses.", "Evaluate whether a proposed configuration or transition mechanism preserves required IP connectivity." ] }, "sources": [], "structure": { "bundles": [ { "id": "protocol-identity-and-conformance", "name": "Protocol identity and conformance", "description": "Establishes which IP version and technical requirements govern the subject being assessed.", "rationale": "An agent cannot interpret packets or judge compatibility using an undifferentiated notion of IP.", "layers": [ { "id": "version-and-model-boundary", "name": "Version and model boundary", "description": "Separates the IP family, its versions and concrete implementations.", "findings": [ { "id": "ip-family-and-version", "name": "IP family and version", "description": "Record whether the subject is the protocol family, an IPv4 or IPv6 specification, or a deployment supporting one or both versions.", "questions": [ { "text": "Does this record describe IP generally, a particular version, or a concrete implementation?", "kind": "definition", "id": "ip-family-and-version-q01" }, { "text": "Which responsibilities belong to IP here, and which belong to transport, link or routing protocols?", "kind": "boundary", "id": "ip-family-and-version-q02" } ] } ] }, { "id": "specification-profile", "name": "Specification profile", "description": "Connects claimed behaviour to the technical documents and implementation evidence that support it.", "findings": [ { "id": "applicable-ip-requirements", "name": "Applicable IP requirements", "description": "Record the base specification, relevant updates and extensions, and evidence for implementation support.", "questions": [ { "text": "Which specification documents and updates define the behaviour being assessed?", "kind": "provenance", "id": "applicable-ip-requirements-q01" }, { "text": "What documentation or observed behaviour supports the claimed implementation conformance?", "kind": "provenance", "id": "applicable-ip-requirements-q02" } ] } ] } ] }, { "id": "addressing-and-network-context", "name": "Addressing and network context", "description": "Captures how IP addresses and prefixes acquire meaning within a deployment.", "rationale": "Address syntax alone cannot establish identity, permitted use or reachability.", "layers": [ { "id": "address-semantics", "name": "Address semantics", "description": "Interprets address representation, destination role and scope according to the IP version.", "findings": [ { "id": "address-role-prefix-and-scope", "name": "Address role, prefix and scope", "description": "Record the address, prefix length, version-specific role, scope and any relevant special-purpose designation.", "questions": [ { "text": "What IP version, prefix length and destination role apply to this address?", "kind": "definition", "id": "address-role-prefix-and-scope-q01" }, { "text": "Within which network scope or zone is this address meaningful and usable?", "kind": "boundary", "id": "address-role-prefix-and-scope-q02" } ] } ] }, { "id": "assignment-and-routing-context", "name": "Assignment and routing context", "description": "Relates addresses to interfaces and the forwarding environment in which they operate.", "findings": [ { "id": "contextual-address-assignment", "name": "Contextual address assignment", "description": "Record interface association, assignment evidence, observation time and routing context, allowing multiple addresses and reused address spaces.", "questions": [ { "text": "Which interface and routing context use this address, and when was that association verified?", "kind": "provenance", "id": "contextual-address-assignment-q01" }, { "text": "Could address reuse, translation or anycast make this address refer to different endpoints from different observation points?", "kind": "boundary", "id": "contextual-address-assignment-q02" } ] } ] } ] }, { "id": "datagram-structure-and-processing", "name": "Datagram structure and processing", "description": "Describes the packet information an IP implementation must interpret and the version-specific processing it requires.", "rationale": "Packet validity and interoperability depend on concrete header semantics rather than protocol labels.", "layers": [ { "id": "headers-and-payload-dispatch", "name": "Headers and payload dispatch", "description": "Covers base headers, length interpretation and identification of the following protocol.", "findings": [ { "id": "version-specific-datagram-interpretation", "name": "Version-specific datagram interpretation", "description": "Record header fields and packet-length evidence using the selected version, including IPv4 Protocol or IPv6 Next Header interpretation.", "questions": [ { "text": "Are the version, header structure and length fields consistent with the available packet bytes?", "kind": "measurement", "id": "version-specific-datagram-interpretation-q01" }, { "text": "Which protocol or next header does the datagram identify, and can the observer interpret it?", "kind": "definition", "id": "version-specific-datagram-interpretation-q02" } ] } ] }, { "id": "options-extensions-and-fragments", "name": "Options, extensions and fragments", "description": "Covers additional header processing and reconstruction of fragmented datagrams.", "findings": [ { "id": "additional-processing-requirements", "name": "Additional processing requirements", "description": "Record IPv4 options or IPv6 extension headers, fragmentation state and evidence of receiver or intermediate-device support.", "questions": [ { "text": "Which options, extension headers or fragmentation fields are present, and what processing do they require?", "kind": "definition", "id": "additional-processing-requirements-q01" }, { "text": "Is sufficient fragment evidence available for reassembly, or must the payload remain uninterpreted?", "kind": "action", "id": "additional-processing-requirements-q02" } ] } ] } ] }, { "id": "forwarding-and-delivery-constraints", "name": "Forwarding and delivery constraints", "description": "Captures the conditions under which an IP datagram can progress toward its destination.", "rationale": "An assigned address and a valid packet do not establish successful end-to-end delivery.", "layers": [ { "id": "next-hop-and-packet-lifetime", "name": "Next hop and packet lifetime", "description": "Relates destination lookup, next-hop selection and lifetime limits to forwarding outcomes.", "findings": [ { "id": "forwarding-decision-evidence", "name": "Forwarding decision evidence", "description": "Record the routing context, selected route, next hop, egress interface and remaining TTL or Hop Limit without absorbing routing-protocol design into IP.", "questions": [ { "text": "Which route, next hop and egress interface apply to this destination in the selected routing context?", "kind": "measurement", "id": "forwarding-decision-evidence-q01" }, { "text": "Would the TTL or Hop Limit permit another forwarding step, and what evidence indicates expiry?", "kind": "measurement", "id": "forwarding-decision-evidence-q02" } ] } ] }, { "id": "packet-size-and-delivery-evidence", "name": "Packet size and delivery evidence", "description": "Connects MTU constraints, fragmentation rules and diagnostic observations to delivery assessment.", "findings": [ { "id": "mtu-and-version-specific-fragmentation", "name": "MTU and version-specific fragmentation", "description": "Record packet size, relevant MTU evidence and fragmentation permissions; distinguish IPv4 fragmentation behaviour from IPv6, where routers do not fragment packets.", "questions": [ { "text": "Does the packet fit the known path MTU, and how reliable and recent is that MTU evidence?", "kind": "measurement", "id": "mtu-and-version-specific-fragmentation-q01" }, { "text": "Given the IP version and packet flags or headers, should an oversized packet be fragmented by an eligible node or discarded with applicable diagnostic feedback?", "kind": "action", "id": "mtu-and-version-specific-fragmentation-q02" } ] } ] } ] }, { "id": "interoperability-and-operational-boundaries", "name": "Interoperability and operational boundaries", "description": "Assesses communication across version boundaries and the limits of operational and security conclusions.", "rationale": "Agents must distinguish protocol compatibility from observed connectivity and from permission to change or probe a network.", "layers": [ { "id": "version-coexistence-and-transition", "name": "Version coexistence and transition", "description": "Records how endpoints and intervening networks accommodate IPv4 and IPv6.", "findings": [ { "id": "cross-version-connectivity-mechanism", "name": "Cross-version connectivity mechanism", "description": "Identify native connectivity, dual-stack operation, tunnelling or translation and the address, header and packet-size consequences of the selected mechanism.", "questions": [ { "text": "Which IP versions are available at each endpoint and across the intervening network?", "kind": "measurement", "id": "cross-version-connectivity-mechanism-q01" }, { "text": "What coexistence or transition mechanism is configured, and what constraints does it impose on the proposed communication?", "kind": "boundary", "id": "cross-version-connectivity-mechanism-q02" } ] } ] }, { "id": "diagnostics-trust-and-authorised-actions", "name": "Diagnostics, trust and authorised actions", "description": "Separates observable IP behaviour from identity guarantees, security controls and operational permissions.", "findings": [ { "id": "bounded-connectivity-and-trust-claims", "name": "Bounded connectivity and trust claims", "description": "Record test conditions, filtering and diagnostic evidence; do not treat a source address as authenticated identity or a failed probe as proof that all IP delivery is unavailable.", "questions": [ { "text": "What do the available packet captures, counters and diagnostic responses actually establish about connectivity or filtering?", "kind": "measurement", "id": "bounded-connectivity-and-trust-claims-q01" }, { "text": "Which probes or configuration changes are authorised, and what additional controls are required if authenticity or confidentiality is needed?", "kind": "action", "id": "bounded-connectivity-and-trust-claims-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": [ "This describes the networking protocol, not a discipline or field of knowledge; the batch classification should be checked.", "Standards and identifiers are recalled without consulting sources; RFC updates and errata should be checked during research.", "IPv4 and IPv6 differ in fragmentation, header structure, and supporting mechanisms; detailed findings should distinguish the versions." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of Internet Protocol 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": [ "IPv4", "IPv6" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of Internet Protocol 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": "IP version field", "value_or_pattern": "4 or 6", "note": "A four-bit field identifies IPv4 or IPv6 in the packet header." }, { "scheme": "IPv4 address notation", "value_or_pattern": "Four decimal octets separated by periods", "note": "Represents a 32-bit address; each octet ranges from 0 to 255." }, { "scheme": "IPv6 address notation", "value_or_pattern": "Eight colon-separated hexadecimal groups, with permitted zero compression", "note": "Represents a 128-bit address." }, { "scheme": "CIDR prefix notation", "value_or_pattern": "address/prefix-length", "note": "Prefix lengths range from 0 to 32 for IPv4 and 0 to 128 for IPv6." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of Internet Protocol 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": [ "RFC 791, Internet Protocol: IPv4 specification published in the RFC series.", "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification: IETF.", "RFC 4291, IP Version 6 Addressing Architecture: IETF.", "RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan: IETF.", "RFC 1122, Requirements for Internet Hosts - Communication Layers: IETF." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of Internet Protocol 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": [ "Carrying transport-layer traffic across the public Internet.", "Connecting hosts and subnets within enterprise and private networks.", "Providing addressing and packet forwarding across heterogeneous link technologies.", "Carrying encapsulated traffic through tunnels and virtual private networks." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of Internet Protocol 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": "Address width", "typical_range": "32 for IPv4; 128 for IPv6", "unit": "bit" }, { "quantity": "Base header length", "typical_range": "20-60 for IPv4; 40 for IPv6 before extension headers", "unit": "byte" }, { "quantity": "IPv6 Hop Limit", "typical_range": "0-255 representable; decremented at each forwarding node", "unit": "hop" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of Internet Protocol 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": [ "Congestion and link failures can cause packet loss; IP itself does not retransmit lost packets.", "Routing loops or incorrect routes can cause packet expiry, misdelivery, or unreachable destinations.", "Packets exceeding a path's supported size can be dropped; failed path MTU discovery can produce connectivity black holes.", "Source-address spoofing is possible where appropriate filtering or authentication is absent.", "IP alone does not provide confidentiality or cryptographic authentication." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of Internet Protocol 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": [ "Address allocation and registration are administered through regional Internet registries under globally coordinated arrangements.", "IPv6 deployment and reliance on IPv4 address sharing vary among countries, operators, and networks." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of Internet Protocol 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": "Internet protocol suite", "difference": "The suite includes IP and numerous associated protocols; IP is its network-layer datagram protocol." }, { "name": "Transmission Control Protocol", "difference": "TCP provides reliable, ordered byte streams between endpoints using IP for packet delivery." }, { "name": "User Datagram Protocol", "difference": "UDP adds transport-layer ports and datagram delivery between applications over IP." }, { "name": "Ethernet", "difference": "Ethernet supplies link-layer framing and delivery on a local link; IP supports delivery across interconnected networks." }, { "name": "Border Gateway Protocol", "difference": "BGP exchanges routing information used to select paths; IP defines the datagrams forwarded along those paths." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of Internet Protocol this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend the full IPv4 and IPv6 family, and should its classification be corrected from an apparent field-of-knowledge grouping to a protocol specification?", "Which existing Vercy world models already own IP or overlapping network-layer concepts, requiring linkage instead of a duplicate publication?", "Which base specifications, updates and extensions should define the researched conformance baseline for each IP version?", "How should ownership of ICMP, neighbour discovery, address configuration, translation and IPsec be divided between this model and neighbouring models?", "What deployment evidence and observation freshness are sufficient to support claims about reachability, path MTU and extension-header compatibility?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 19, "questions": 29 } }, "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 Internet Protocol, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise Internet Protocol specifications and deployments, assess packet-delivery constraints, and determine compatible and authorised network actions.", "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: IPv6, IP addressing, ephemeral port, traffic volume, garlic routing.", "5 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 81 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 Internet Protocol, 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": [ "IPv6", "IP addressing", "ephemeral port", "traffic volume", "garlic routing" ] } ], "standing": "Described in 81 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 5 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 Internet Protocol from another, and a Internet Protocol 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 Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a Internet Protocol 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 Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol contains and in what form it is held.", "questions": [ { "id": "content-and-format-q01", "text": "What identifies and describes the content of a Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol and the period it survives.", "questions": [ { "id": "access-rules-q01", "text": "What identifies and describes access to a Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 Internet Protocol is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a Internet Protocol, 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 Internet Protocol, 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 Internet Protocol 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 } } } }