{ "model": { "rank": 4505, "code": "thing-q8803", "model_id": "vr.tr.transmission-control-protocol", "name": "Transmission Control Protocol", "purpose": "Enable an AI agent to recognise TCP behaviour, assess a connection's transport state and delivery limits, and choose justified diagnostic or control actions.", "family": "Thing Registry", "category": "Activities and processes", "status": "research-draft", "kind": "thing", "plane": "ACT", "domain": "ACT.ACT", "industry": "", "version": "", "url": "/models/thing/q8803/", "tier": 2, "score": 75, "payload": { "layer": "wikidata", "aliases": [], "aliasCount": 0, "merged": 0, "knownIn": 75, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q8803", "url": "https://www.wikidata.org/wiki/Q8803", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T20:22:55Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 22.8, "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: 01a087d5-8bf0-7db0-9697-ca606de86d48\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: Transmission Control Protocol\nSense to describe: (none recorded)\nDomain code: ACT.ACT\nAlso known as: (none)\n\n\nContext for this batch of 695 things:\n# Ba", "usd": 0, "recall": true }, "codex": { "seconds": 61.1, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a087d5-8bee-7b72-b45e-6bb7ef33d03b\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: Transmission Control Protocol\nRegistry id: vr.tr.transmission-control-protocol\nPlane / domain: ACT / ACT.ACT\nRegistry definition: (none recorded)\nNam" } } }, "metaModel": { "id": "THING-Q8803", "registryId": "vr.tr.transmission-control-protocol", "name": "Transmission Control Protocol", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "ACT.ACT" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q8803/", "model": { "registry_id": "vr.tr.transmission-control-protocol", "name": "Transmission Control Protocol", "purpose": "Enable an AI agent to recognise TCP behaviour, assess a connection's transport state and delivery limits, and choose justified diagnostic or control actions.", "definition": "Transmission Control Protocol (TCP) is a connection-oriented transport protocol in the Internet protocol suite that provides applications with a reliable, ordered, bidirectional byte stream using sequence numbers, acknowledgements, retransmission, flow control and congestion control.", "scope_statement": "This model owns Transmission Control Protocol as a transport protocol and the evidence needed to assess its implementations and connection instances, distinguishing protocol requirements from optional extensions, implementation choices and application expectations.", "in_scope": [ "Reliable, ordered, bidirectional byte-stream semantics and their limits", "Connection establishment, endpoint identity, lifecycle and termination", "Segment interpretation, sequencing, acknowledgements and loss recovery", "Receiver flow control, sender congestion control and transport performance", "TCP options, implementation variation and evidence-based diagnosis" ], "out_of_scope": [ "IP addressing allocation, routing and network-layer forwarding", "Application message framing, transaction completion and business semantics", "TLS encryption, certificate validation and application authentication", "UDP, QUIC and other transport protocols except as boundary comparisons", "Physical links, network equipment and operating-system internals beyond their observable effects on TCP" ], "distinguishing_features": [ "Presents an ordered byte stream: application write boundaries are not preserved as message boundaries.", "Maintains connection state at endpoints and normally establishes a connection through a SYN, SYN-ACK and ACK exchange.", "Uses byte sequence numbers, acknowledgements and retransmission to recover from loss while suppressing duplicate delivery.", "Separately constrains sending through receiver-advertised flow control and sender congestion control.", "An acknowledgement indicates transport-level receipt, not application processing; TCP itself supplies neither encryption nor authenticated peer identity." ], "characteristics": [ { "name": "Protocol profile", "kind": "category", "unit_or_values": "Base specification, applicable extensions and implementation-specific behaviour", "why_it_matters": "Establishes which requirements and capabilities apply before judging observed behaviour." }, { "name": "Connection identity", "kind": "relation", "unit_or_values": "Local and remote IP addresses and TCP ports, with observation time and network context", "why_it_matters": "Associates evidence with an endpoint pair while accounting for address translation and tuple reuse." }, { "name": "Endpoint connection state", "kind": "state", "unit_or_values": "CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT", "why_it_matters": "Determines which transitions and operations are valid at each endpoint." }, { "name": "Sequence and acknowledgement position", "kind": "measurement", "unit_or_values": "32-bit sequence-space values interpreted modulo 2^32", "why_it_matters": "Supports reasoning about received data, missing ranges and progress; SYN and FIN also consume sequence space." }, { "name": "Effective receive window", "kind": "measurement", "unit_or_values": "Bytes, interpreted with the applicable negotiated window scale", "why_it_matters": "Shows how much additional sequence space the receiver permits the sender to use." }, { "name": "Congestion-control state", "kind": "state", "unit_or_values": "Algorithm, congestion window in bytes, recovery phase and pacing state where observable", "why_it_matters": "Explains sender limits imposed by congestion control and separates them from receiver limits." }, { "name": "Timing estimates", "kind": "measurement", "unit_or_values": "Round-trip time, round-trip variation and retransmission timeout in milliseconds", "why_it_matters": "Supports assessment of delay, retransmission decisions and stalled progress." }, { "name": "Directional option status", "kind": "category", "unit_or_values": "Offered, negotiated, active, absent or unknown for each relevant capability", "why_it_matters": "Prevents assuming that observed options or host capabilities apply equally in both directions." }, { "name": "Observation coverage", "kind": "category", "unit_or_values": "Endpoint telemetry, bidirectional capture, one-sided capture or partial capture; capture location and time interval", "why_it_matters": "Bounds what can be concluded about loss, state, timing and peer behaviour." } ], "affordances": [ "Classify a flow as TCP and associate its observed segments with a connection instance.", "Reconstruct supported endpoint-state transitions and identify missing evidence.", "Assess byte-stream progress, gaps, duplicate acknowledgements and retransmission behaviour.", "Distinguish receiver-window limits, congestion-control limits and application inactivity using available evidence.", "Evaluate compatibility of TCP options and diagnose suspected path interference.", "Recommend or perform authorised connection shutdown, targeted measurements or transport configuration changes with explicit expected effects." ] }, "sources": [], "structure": { "bundles": [ { "id": "byte-stream-contract", "name": "Byte-stream contract", "description": "The service TCP provides and the boundaries of its delivery claims.", "rationale": "An agent must distinguish transport progress from application success and avoid treating segments as application messages.", "layers": [ { "id": "stream-semantics", "name": "Stream semantics", "description": "Ordering, duplication and message-boundary interpretation.", "findings": [ { "id": "ordered-bytes-without-message-boundaries", "name": "Ordered bytes without message boundaries", "description": "Record the two directional byte streams and the application's framing expectations without inferring message boundaries from TCP segments.", "questions": [ { "text": "Does the consumer require an ordered byte stream, and how does it identify application messages within that stream?", "kind": "definition", "id": "ordered-bytes-without-message-boundaries-q01" }, { "text": "Which apparent message boundaries come from application framing, and which are merely segment or capture boundaries?", "kind": "boundary", "id": "ordered-bytes-without-message-boundaries-q02" } ] } ] }, { "id": "delivery-evidence", "name": "Delivery evidence", "description": "What transport acknowledgements and connection outcomes establish.", "findings": [ { "id": "receipt-versus-processing", "name": "Receipt versus processing", "description": "Separate bytes acknowledged by TCP from bytes read, processed or durably committed by the receiving application.", "questions": [ { "text": "Which byte ranges have been cumulatively acknowledged, and what independent evidence shows application consumption?", "kind": "measurement", "id": "receipt-versus-processing-q01" }, { "text": "After a timeout or reset, what application-level evidence is needed before retrying an operation that might already have taken effect?", "kind": "action", "id": "receipt-versus-processing-q02" } ] } ] } ] }, { "id": "connection-lifecycle", "name": "Connection lifecycle", "description": "Connection identity and the endpoint state machines that govern opening and closing.", "rationale": "TCP actions depend on endpoint-local state; an open socket, an established connection and a completed exchange are different conditions.", "layers": [ { "id": "identity-and-establishment", "name": "Identity and establishment", "description": "Endpoint association and evidence of connection opening.", "findings": [ { "id": "handshake-and-instance-identity", "name": "Handshake and instance identity", "description": "Record the endpoint tuple, handshake evidence and temporal context needed to distinguish a connection from earlier uses of the same tuple.", "questions": [ { "text": "Which addresses and ports identify this connection at the observation point, and does translation change that identity elsewhere?", "kind": "boundary", "id": "handshake-and-instance-identity-q01" }, { "text": "What SYN and acknowledgement evidence supports the inferred establishment state at each endpoint?", "kind": "measurement", "id": "handshake-and-instance-identity-q02" } ] } ] }, { "id": "shutdown-and-residual-state", "name": "Shutdown and residual state", "description": "Directional closure, aborts and state retained after exchange completion.", "findings": [ { "id": "fin-reset-and-time-wait", "name": "FIN, reset and TIME-WAIT", "description": "Distinguish an orderly end to one sending direction from an aborted connection and from post-closure TIME-WAIT state.", "questions": [ { "text": "Which direction has sent or acknowledged FIN, has a reset occurred, and what state is supported for each endpoint?", "kind": "measurement", "id": "fin-reset-and-time-wait-q01" }, { "text": "Given pending data and application intent, should the agent wait, half-close, close normally or request an authorised abort?", "kind": "action", "id": "fin-reset-and-time-wait-q02" } ] } ] } ] }, { "id": "sequencing-and-recovery", "name": "Sequencing and recovery", "description": "How TCP represents byte progress and recovers from suspected loss.", "rationale": "A stalled or repeated segment cannot be interpreted correctly without sequence-space, acknowledgement and timer context.", "layers": [ { "id": "sequence-space-accounting", "name": "Sequence-space accounting", "description": "Byte ranges, cumulative acknowledgements and selective acknowledgement evidence.", "findings": [ { "id": "received-and-missing-ranges", "name": "Received and missing ranges", "description": "Track acknowledged progress and selectively reported ranges while accounting for wraparound, SYN and FIN.", "questions": [ { "text": "Which sequence ranges are cumulatively acknowledged, selectively reported as received or still unresolved?", "kind": "measurement", "id": "received-and-missing-ranges-q01" }, { "text": "Could an apparent gap or duplicate arise from capture loss, reordering or an incorrect connection association?", "kind": "boundary", "id": "received-and-missing-ranges-q02" } ] } ] }, { "id": "loss-detection-and-timers", "name": "Loss detection and timers", "description": "Evidence behind retransmissions and recovery decisions.", "findings": [ { "id": "retransmission-cause-and-confidence", "name": "Retransmission cause and confidence", "description": "Record the available evidence for timeout-based or other loss-recovery triggers without treating every retransmission as proof of network loss.", "questions": [ { "text": "Which acknowledgement pattern, timer event or endpoint diagnostic supports the inferred retransmission trigger?", "kind": "provenance", "id": "retransmission-cause-and-confidence-q01" }, { "text": "What additional measurement would distinguish actual loss from reordering, delayed feedback or a spurious retransmission?", "kind": "action", "id": "retransmission-cause-and-confidence-q02" } ] } ] } ] }, { "id": "flow-congestion-and-performance", "name": "Flow, congestion and performance", "description": "Receiver capacity, network feedback and the constraints that determine sending progress.", "rationale": "Receiver protection and network congestion control impose different limits and require different interventions.", "layers": [ { "id": "receiver-flow-control", "name": "Receiver flow control", "description": "Advertised windows, scaling and zero-window behaviour.", "findings": [ { "id": "receive-window-limits", "name": "Receive-window limits", "description": "Record the effective advertised window in each direction and evidence that receiver capacity is limiting progress.", "questions": [ { "text": "What effective receive window is advertised after applying the scale established for that direction?", "kind": "measurement", "id": "receive-window-limits-q01" }, { "text": "If the window remains zero or small, what receiver-side evidence would justify changing application consumption or buffer configuration?", "kind": "action", "id": "receive-window-limits-q02" } ] } ] }, { "id": "sender-congestion-and-throughput", "name": "Sender congestion and throughput", "description": "Congestion algorithms, feedback and useful data-transfer rate.", "findings": [ { "id": "active-throughput-constraint", "name": "Active throughput constraint", "description": "Relate useful acknowledged-byte progress to congestion state, receive-window limits, path timing and application supply.", "questions": [ { "text": "Which congestion-control algorithm and sender metrics are directly known, and which would be guesses from packet traces?", "kind": "provenance", "id": "active-throughput-constraint-q01" }, { "text": "Over the measured interval, does evidence identify congestion control, the receive window, path capacity or application supply as the active constraint?", "kind": "measurement", "id": "active-throughput-constraint-q02" } ] } ] } ] }, { "id": "protocol-profile-and-observability", "name": "Protocol profile and observability", "description": "Applicable requirements, optional capabilities and limits of observation or trust.", "rationale": "Judging TCP behaviour requires the right protocol profile and evidence that distinguishes endpoint behaviour from path and capture effects.", "layers": [ { "id": "requirements-and-capabilities", "name": "Requirements and capabilities", "description": "Standards applicability, TCP options and implementation-specific choices.", "findings": [ { "id": "applicable-tcp-profile", "name": "Applicable TCP profile", "description": "Associate observed behaviour with researched specifications and record option availability separately from successful use.", "questions": [ { "text": "Which authoritative specifications and implementation documentation establish the requirements applicable to this connection?", "kind": "provenance", "id": "applicable-tcp-profile-q01" }, { "text": "Which capabilities, such as selective acknowledgements, timestamps, window scaling or explicit congestion notification, were offered and successfully enabled?", "kind": "measurement", "id": "applicable-tcp-profile-q02" } ] } ] }, { "id": "observation-and-trust-boundaries", "name": "Observation and trust boundaries", "description": "Capture limitations, path transformations and security properties outside TCP's base service.", "findings": [ { "id": "evidence-limits-and-peer-trust", "name": "Evidence limits and peer trust", "description": "Record observation location, offload effects and possible intermediaries while keeping transport endpoint association separate from authenticated identity.", "questions": [ { "text": "Could checksum or segment-size anomalies reflect host offloading, capture position or intermediary behaviour rather than malformed traffic on the wire?", "kind": "boundary", "id": "evidence-limits-and-peer-trust-q01" }, { "text": "What separate mechanism, if any, establishes peer authentication and protects the stream's confidentiality and integrity?", "kind": "boundary", "id": "evidence-limits-and-peer-trust-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "The sense described is the Internet transport protocol, conventionally abbreviated TCP.", "The listed kinds are congestion-control implementation choices and a protocol extension, not a mutually exclusive taxonomy.", "Standard identifiers are recalled without source inspection; researchers should check updates and implementation support, especially for congestion-control variants." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of Transmission Control 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": [ "TCP implementations using Reno congestion control", "TCP implementations using CUBIC congestion control", "TCP implementations using BBR congestion control", "Multipath TCP, an extension supporting multiple subflows within one connection" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of Transmission Control 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": "IANA IP Protocol Numbers", "value_or_pattern": "6", "note": "Identifies TCP in the IPv4 Protocol field and IPv6 Next Header field." }, { "scheme": "IANA Service Name and Transport Protocol Port Number Registry", "value_or_pattern": "TCP port number: 0-65535", "note": "Source and destination ports identify transport endpoints; port 0 is reserved." }, { "scheme": "TCP connection four-tuple", "value_or_pattern": "(source IP address, source port, destination IP address, destination port)", "note": "Distinguishes connections within a network context; this is not a globally persistent identifier." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of Transmission Control 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": [ "IETF RFC 9293, Transmission Control Protocol: core TCP specification.", "IETF RFC 5681, TCP Congestion Control.", "IETF RFC 6298, Computing TCP's Retransmission Timer.", "IETF RFC 7323, TCP Extensions for High Performance.", "IETF RFC 8684, TCP Extensions for Multipath Operation with Multiple Addresses." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of Transmission Control 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": [ "Transport for HTTP/1.1 and HTTP/2 web connections.", "Transport for email protocols including SMTP, IMAP and POP3.", "Transport for SSH remote access and associated file transfers.", "Transport for many database client-server connections.", "Transport for DNS exchanges, including zone transfers and responses requiring TCP." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of Transmission Control 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": "Application goodput", "typical_range": "No universal range; depends on path capacity, round-trip time, loss and endpoint limits.", "unit": "bit/s" }, { "quantity": "Round-trip time", "typical_range": "No universal range; depends on path propagation, processing and queueing.", "unit": "ms" }, { "quantity": "Advertised receive window", "typical_range": "Representable range is 0-65535 bytes without window scaling; negotiated scaling permits larger windows.", "unit": "byte" }, { "quantity": "TCP header length", "typical_range": "20-60, depending on included options.", "unit": "byte" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of Transmission Control 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": [ "Lost data delays delivery of subsequent bytes to the application until the gap is repaired, causing head-of-line blocking.", "Congestion, loss or excessive buffering can reduce throughput and increase latency.", "SYN flooding can exhaust connection-establishment resources.", "TCP alone provides neither encryption nor cryptographic peer authentication; its checksum does not prevent deliberate tampering.", "Path failures, endpoint crashes and middlebox timeouts can interrupt connections; a TCP acknowledgement does not prove that an application processed or durably stored the data." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of Transmission Control 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", "difference": "IP carries addressed datagrams between hosts; TCP runs over IP and supplies reliable byte-stream transport between endpoints." }, { "name": "User Datagram Protocol", "difference": "UDP preserves datagram boundaries and does not itself provide TCP's connection establishment, ordered delivery or retransmission." }, { "name": "QUIC", "difference": "QUIC runs over UDP and integrates cryptographic security and multiple streams, whereas TCP exposes a byte stream per connection without built-in encryption." }, { "name": "Transport Layer Security", "difference": "TLS provides cryptographic protection for application communication; TCP provides transport reliability and ordering." }, { "name": "Stream Control Transmission Protocol", "difference": "SCTP is message-oriented and supports multiple streams within an association; TCP is byte-stream-oriented." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of Transmission Control Protocol this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Which base specification, updates and optional extensions should define the publication's researched TCP profile?", "How much connection state and congestion-control information must an agent obtain from endpoint telemetry when packet observations alone are inconclusive?", "Which operating-system behaviours for keepalive, retransmission limits, user timeouts and aborts require explicit implementation profiles?", "How should the model represent connection identity across NAT, TCP proxies and tuple reuse without merging separate transport connections?", "What evidence thresholds should justify active probing, configuration changes or connection termination in each deployment context?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 28 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "abstract concept", "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 Transmission Control Protocol, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise TCP behaviour, assess a connection's transport state and delivery limits, and choose justified diagnostic or control actions.", "characteristics": { "substance": "activity", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "observed and measured" ], "distinguishingFeatures": [ "Described in 75 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 Transmission Control Protocol, and on what evidence are they told apart?" ], "whatItIsMadeOf": "something that happens over time", "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": [ "observe it, measure it, record its state" ], "howItIsRecognised": [ "Nothing to see. What is recognised is an instance of it, and which instances count is exactly what is argued about." ], "relatedModels": [], "standing": "Described in 75 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one Transmission Control Protocol from another, and a Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control Protocol from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control Protocol between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control Protocol, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "process-and-outcome", "name": "Process, inputs and outcome", "description": "How a Transmission Control Protocol proceeds, what it needs and what it leaves behind.", "rationale": "An activity is known by its steps and its results, and both have to be recordable while it is still running.", "layers": [ { "id": "steps-and-sequence", "name": "Steps and sequence", "description": "The steps of a Transmission Control Protocol, their order and what may run in parallel.", "findings": [ { "id": "steps-and-preconditions", "name": "Steps, preconditions and completion", "description": "What has to be true before each step of a Transmission Control Protocol and what marks it done.", "questions": [ { "id": "steps-and-preconditions-q01", "text": "What identifies and describes a step of a Transmission Control Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "steps-and-preconditions-q02", "text": "Who or what asserted this about a step of a Transmission Control Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "steps-and-preconditions-q03", "text": "What may an agent decide or do once a step of a Transmission Control Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "inputs-and-results", "name": "Inputs, resources and results", "description": "What a Transmission Control Protocol consumes and what it produces.", "findings": [ { "id": "inputs-and-outputs", "name": "Inputs, outputs and side effects", "description": "The resources a Transmission Control Protocol takes and the results it leaves, wanted or not.", "questions": [ { "id": "inputs-and-outputs-q01", "text": "What identifies and describes the inputs and results of a Transmission Control Protocol, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "inputs-and-outputs-q02", "text": "Who or what asserted this about the inputs and results of a Transmission Control Protocol, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "inputs-and-outputs-q03", "text": "What may an agent decide or do once the inputs and results of a Transmission Control Protocol is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "definitions-in-contest", "name": "Definitions and who holds them", "description": "What Transmission Control Protocol is taken to mean, and by whom.", "rationale": "When a field disagrees about a concept, the disagreement is the content. A model that picks one definition silently destroys the information.", "layers": [ { "id": "competing-definitions", "name": "Competing definitions", "description": "The main readings and the traditions behind them.", "findings": [ { "id": "definition-map", "name": "Definitions and their holders", "description": "Each definition with the school or body that holds it.", "questions": [ { "id": "definition-map-q01", "text": "Which definitions of Transmission Control Protocol are in use, and which tradition or body holds each?", "kind": "definition" }, { "id": "definition-map-q02", "text": "What turns on the difference between them in practice?", "kind": "boundary" } ] } ] }, { "id": "operationalisation", "name": "Operationalisation", "description": "How it is measured or applied when it has to be.", "findings": [ { "id": "operational-record", "name": "Measures and proxies", "description": "Instruments and indicators used to stand in for it.", "questions": [ { "id": "operational-record-q01", "text": "How is Transmission Control Protocol operationalised or measured in practice, and by what instrument?", "kind": "measurement" }, { "id": "operational-record-q02", "text": "What does that operationalisation leave out, and when does that matter?", "kind": "boundary" } ] } ] } ] }, { "id": "instances-and-use", "name": "Instances, use and consequence", "description": "What counts as an instance of Transmission Control Protocol and what follows from calling something that.", "rationale": "Applying a concept is an act with consequences, so a model must say what the label licenses and what it does not.", "layers": [ { "id": "instances", "name": "What counts as an instance", "description": "Clear cases, borderline cases and non-cases.", "findings": [ { "id": "instance-tests", "name": "Tests for an instance", "description": "What would settle whether something falls under it.", "questions": [ { "id": "instance-tests-q01", "text": "What would settle whether something is an instance of Transmission Control Protocol?", "kind": "boundary" }, { "id": "instance-tests-q02", "text": "Which borderline cases are argued about, and on what grounds?", "kind": "definition" } ] } ] }, { "id": "consequence", "name": "Consequence of application", "description": "Rights, duties or decisions that follow from the label.", "findings": [ { "id": "consequence-record", "name": "What the label licenses", "description": "What an agent may do once something is classified this way.", "questions": [ { "id": "consequence-record-q01", "text": "What follows practically once something is treated as Transmission Control Protocol?", "kind": "action" }, { "id": "consequence-record-q02", "text": "What must an agent not infer from the label alone?", "kind": "action" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a Transmission Control 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 Transmission Control Protocol and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a Transmission Control 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 Transmission Control 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 Transmission Control 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 Transmission Control Protocol is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a Transmission Control 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 Transmission Control 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 Transmission Control 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 } } } }