{ "model": { "rank": 2590, "code": "thing-q39531", "model_id": "vr.tr.bluetooth", "name": "Bluetooth", "purpose": "Enable an AI agent to recognise a Bluetooth implementation, assess its supported interactions and current state, and decide which discovery, connection, data exchange or configuration actions are appropriate.", "family": "Thing Registry", "category": "Physical world and living systems", "status": "research-draft", "kind": "thing", "plane": "PHY", "domain": "PHY.OBJ", "industry": "", "version": "", "url": "/models/thing/q39531/", "tier": 2, "score": 101, "payload": { "layer": "wikidata", "aliases": [ "Bluetooth 5" ], "aliasCount": 1, "merged": 1, "knownIn": 101, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q39531", "url": "https://www.wikidata.org/wiki/Q39531", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T10:11:53Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.00546006, "turns": 1, "seconds": 21.7, "error": null }, "codex": { "seconds": 74.8, "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: 01a07b59-34bd-7f92-a235-e66325da378f\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: Bluetooth\nRegistry id: vr.tr.bluetooth\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\nA Ver" } } }, "metaModel": { "id": "THING-Q39531", "registryId": "vr.tr.bluetooth", "name": "Bluetooth", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q39531/", "model": { "registry_id": "vr.tr.bluetooth", "name": "Bluetooth", "purpose": "Enable an AI agent to recognise a Bluetooth implementation, assess its supported interactions and current state, and decide which discovery, connection, data exchange or configuration actions are appropriate.", "definition": "Bluetooth is a short-range wireless communications technology and open protocol stack, specified by the Bluetooth Special Interest Group, that enables devices to discover, pair, and exchange data over unlicensed 2.4 GHz ISM-band radio using frequency-hopping spread spectrum.", "scope_statement": "This model owns Bluetooth-specific identity, capabilities, radio operation, peer relationships, services and security state as realised by an identifiable implementation; the registry has not yet established whether Bluetooth denotes the technology, an interface or a deployed network.", "in_scope": [ "Evidence that an implementation uses Bluetooth and which transports, roles and features it supports", "Bluetooth discovery, advertising, scanning, pairing, bonding and connection states", "Profiles, services and characteristics through which Bluetooth peers can interact", "Radio configuration, observed link quality and coexistence conditions", "Bluetooth-specific permissions, trust relationships and permitted actions" ], "out_of_scope": [ "The complete physical device, its ownership and its non-Bluetooth functions", "Wi-Fi, NFC, Zigbee and other neighbouring communication technologies", "Application meaning and governance of data carried over Bluetooth", "Battery chemistry, charging systems and general device power management", "The full operating system, firmware lifecycle and general vulnerability management", "Bluetooth SIG governance and commercial qualification administration" ], "distinguishing_features": [ "Require Bluetooth protocol, controller or service evidence; operation in the 2.4 GHz band alone does not distinguish Bluetooth from Wi-Fi or other radios.", "Distinguish Bluetooth BR/EDR from Bluetooth Low Energy using supported transport and procedure evidence; a generic Bluetooth label does not establish support for both.", "Identify Bluetooth interaction contracts through advertised or discovered profiles and services; a device name or product category does not establish interoperability.", "Distinguish a Bluetooth peer relationship from proximity alone by recording the actual advertising, discovery, connection or bonding evidence.", "Distinguish a Bluetooth address from enduring device identity by checking its address type and any supported identity-resolution evidence." ], "characteristics": [ { "name": "Modelled Bluetooth subject", "kind": "category", "unit_or_values": "technology definition | controller or interface | peer endpoint | deployment | unresolved", "why_it_matters": "Prevents capabilities of the technology from being mistaken for capabilities of a particular implementation." }, { "name": "Supported transports", "kind": "category", "unit_or_values": "BR/EDR | LE | both | unknown", "why_it_matters": "Determines which discovery, connection and service mechanisms may be applicable." }, { "name": "Reported specification and feature support", "kind": "relation", "unit_or_values": "reported version, explicitly supported features and supporting evidence", "why_it_matters": "A version claim alone is insufficient to establish optional feature support." }, { "name": "Bluetooth roles", "kind": "category", "unit_or_values": "transport-specific supported and active roles, including LE central, peripheral, broadcaster or observer where applicable", "why_it_matters": "Determines which procedures the implementation can initiate or participate in." }, { "name": "Address and identity basis", "kind": "category", "unit_or_values": "observed address, address type, observation time and identity-resolution basis where available", "why_it_matters": "Supports peer recognition without treating changing addresses as new devices or shared names as unique identifiers." }, { "name": "Procedure and connection state", "kind": "state", "unit_or_values": "supported, active or unavailable advertising, scanning, discovery and connection procedures, recorded separately", "why_it_matters": "These activities can overlap, and each permits different next actions." }, { "name": "Service compatibility", "kind": "relation", "unit_or_values": "peer-specific profile, service, characteristic, role and feature compatibility evidence", "why_it_matters": "A radio connection does not establish that the intended function is available." }, { "name": "Observed received signal strength", "kind": "measurement", "unit_or_values": "dBm, with peer, observation time and measurement context", "why_it_matters": "Helps diagnose reception conditions but does not independently establish distance or reliable service." }, { "name": "Negotiated link parameters", "kind": "measurement", "unit_or_values": "transport-specific values, such as LE connection interval in ms, PHY and negotiated data limits", "why_it_matters": "Constrains achievable responsiveness, data exchange and energy use." }, { "name": "Peer security state", "kind": "state", "unit_or_values": "separate pairing, bonding, encryption, authentication and application-authorization states, with unknown allowed", "why_it_matters": "These states are distinct and must not substitute for one another when permitting access." } ], "affordances": [ "Discover or observe Bluetooth peers using supported procedures and granted permissions.", "Evaluate whether a peer supports the transport, roles and services needed for a requested interaction.", "Initiate or accept an authorised connection, pairing or bonding procedure.", "Read, write, subscribe to or exchange data through compatible services within their access requirements.", "Adjust exposed Bluetooth settings or link preferences within implementation limits and operational constraints.", "Diagnose failed interactions and, when authorised, disconnect peers, remove bonds or disable the interface." ] }, "sources": [], "structure": { "bundles": [ { "id": "bluetooth-identity-and-capability", "name": "Bluetooth identity and capability", "description": "Establishes what Bluetooth subject is being described and which capabilities have evidence.", "rationale": "Bluetooth branding and version labels cannot alone establish the behaviour of an individual implementation.", "layers": [ { "id": "subject-and-protocol-evidence", "name": "Subject and protocol evidence", "description": "Separates the registered technology concept from its interfaces and endpoints.", "findings": [ { "id": "identify-bluetooth-subject", "name": "Identify the Bluetooth subject", "description": "Record the subject boundary and the evidence that identifies its communication interface as Bluetooth.", "questions": [ { "text": "Does this record describe Bluetooth as a technology, a particular controller or interface, a peer endpoint or a deployment?", "kind": "boundary", "id": "identify-bluetooth-subject-q01" }, { "text": "Which inspected controller information, protocol observation or implementation documentation establishes Bluetooth support?", "kind": "provenance", "id": "identify-bluetooth-subject-q02" } ] } ] }, { "id": "transport-and-feature-support", "name": "Transport and feature support", "description": "Records supported transports, roles and optional features without inferring them from a version number.", "findings": [ { "id": "establish-usable-capabilities", "name": "Establish usable capabilities", "description": "Distinguish advertised, documented and directly verified capability support.", "questions": [ { "text": "Which BR/EDR or LE transports and roles are supported, and which are exposed to the agent?", "kind": "definition", "id": "establish-usable-capabilities-q01" }, { "text": "What evidence supports each required feature beyond the reported Bluetooth version?", "kind": "provenance", "id": "establish-usable-capabilities-q02" } ] } ] } ] }, { "id": "radio-and-link-behaviour", "name": "Radio and link behaviour", "description": "Describes Bluetooth radio availability and the observed conditions of particular links.", "rationale": "Peer visibility, responsiveness and connection stability depend on radio conditions and negotiated parameters.", "layers": [ { "id": "radio-availability-and-observation", "name": "Radio availability and observation", "description": "Distinguishes an unavailable controller from an enabled radio that has not observed a peer.", "findings": [ { "id": "assess-radio-conditions", "name": "Assess radio conditions", "description": "Record controller availability and contextualised observations without translating signal strength directly into distance.", "questions": [ { "text": "Is the Bluetooth controller enabled and available to the agent, or blocked by hardware, platform policy or permissions?", "kind": "measurement", "id": "assess-radio-conditions-q01" }, { "text": "What timestamped reception, loss or coexistence observations explain the peer's current visibility, and what remains unobserved?", "kind": "measurement", "id": "assess-radio-conditions-q02" } ] } ] }, { "id": "negotiated-link-performance", "name": "Negotiated link performance", "description": "Relates active transport parameters to the requirements of the intended service.", "findings": [ { "id": "assess-link-fitness", "name": "Assess link fitness", "description": "Evaluate actual link behaviour rather than treating nominal radio capability as delivered performance.", "questions": [ { "text": "Which transport, PHY and link parameters are active, and what latency, throughput or failure behaviour has been measured?", "kind": "measurement", "id": "assess-link-fitness-q01" }, { "text": "Which exposed parameter changes could meet the service requirement, and what responsiveness or energy tradeoffs must be accepted?", "kind": "action", "id": "assess-link-fitness-q02" } ] } ] } ] }, { "id": "peer-discovery-and-session-lifecycle", "name": "Peer discovery and session lifecycle", "description": "Tracks how Bluetooth peers become observable, identifiable and connected.", "rationale": "Advertising, discovery, connection and remembered peer identity represent different conditions with different next actions.", "layers": [ { "id": "discovery-and-peer-recognition", "name": "Discovery and peer recognition", "description": "Records visibility procedures and the strength of evidence linking observations to a peer.", "findings": [ { "id": "recognise-observed-peer", "name": "Recognise an observed peer", "description": "Preserve address type, observation context and identity uncertainty when recognising Bluetooth endpoints.", "questions": [ { "text": "Was the peer observed through LE advertising or scanning, BR/EDR discovery or another supported Bluetooth procedure?", "kind": "provenance", "id": "recognise-observed-peer-q01" }, { "text": "What evidence links this observation to the intended peer despite address changes, duplicate names or stale discovery results?", "kind": "provenance", "id": "recognise-observed-peer-q02" } ] } ] }, { "id": "connection-transitions", "name": "Connection transitions", "description": "Separates supported connection procedures from current peer-specific session state.", "findings": [ { "id": "choose-session-transition", "name": "Choose a session transition", "description": "Record active connections, role constraints and failure reasons before choosing the next lifecycle action.", "questions": [ { "text": "For the intended peer, is connection establishment pending, active, failed or ended, and what event or reason supports that state?", "kind": "measurement", "id": "choose-session-transition-q01" }, { "text": "Can the agent initiate, accept, retry or terminate this connection given the active roles, peer availability and concurrent-connection limits?", "kind": "action", "id": "choose-session-transition-q02" } ] } ] } ] }, { "id": "profiles-services-and-data-access", "name": "Profiles, services and data access", "description": "Establishes what useful Bluetooth interactions compatible peers can perform.", "rationale": "Bluetooth connectivity is useful only when the required service contract and access operations are supported.", "layers": [ { "id": "interaction-contract", "name": "Interaction contract", "description": "Identifies profiles and services required for an intended function.", "findings": [ { "id": "verify-service-compatibility", "name": "Verify service compatibility", "description": "Record the profile or service, complementary roles and required features behind the requested interaction.", "questions": [ { "text": "Which Bluetooth profile or service implements the requested function, and which roles must each peer provide?", "kind": "definition", "id": "verify-service-compatibility-q01" }, { "text": "Which advertised, discovered or tested evidence confirms the required service and features on both peers?", "kind": "provenance", "id": "verify-service-compatibility-q02" } ] } ] }, { "id": "permitted-data-operations", "name": "Permitted data operations", "description": "Describes the operations exposed by a discovered service and their prerequisites.", "findings": [ { "id": "select-service-operation", "name": "Select a service operation", "description": "Connect service-specific operations to supported properties, access requirements and freshness of discovery evidence.", "questions": [ { "text": "For the chosen service, which operations are available, including GATT reads, writes, notifications or indications where applicable?", "kind": "definition", "id": "select-service-operation-q01" }, { "text": "What security, authorization, subscription or service-rediscovery prerequisites must be satisfied before the requested operation?", "kind": "action", "id": "select-service-operation-q02" } ] } ] } ] }, { "id": "pairing-trust-and-authority", "name": "Pairing, trust and authority", "description": "Records Bluetooth security relationships and the authority to create, use or revoke them.", "rationale": "A visible, connected or bonded peer is not automatically authenticated sufficiently or authorised for every operation.", "layers": [ { "id": "pairing-and-link-protection", "name": "Pairing and link protection", "description": "Separates pairing method, stored bonding material and protection of the current connection.", "findings": [ { "id": "assess-peer-security", "name": "Assess peer security", "description": "Record independently evidenced security properties and any required human participation.", "questions": [ { "text": "What pairing method and resulting authentication properties are evidenced, and is a bond stored for this peer?", "kind": "measurement", "id": "assess-peer-security-q01" }, { "text": "Is the current link encrypted with protection sufficient for the requested service, and does pairing require user confirmation or an out-of-band step?", "kind": "action", "id": "assess-peer-security-q02" } ] } ] }, { "id": "permission-and-trust-revocation", "name": "Permission and trust revocation", "description": "Connects Bluetooth operations to platform permissions, user intent and peer-specific authorization.", "findings": [ { "id": "bound-agent-authority", "name": "Bound agent authority", "description": "Record who permits discovery, access and trust changes, including the operational consequences of revocation.", "questions": [ { "text": "Which user instruction, platform permission and service authorization permit the agent's proposed Bluetooth action?", "kind": "provenance", "id": "bound-agent-authority-q01" }, { "text": "When may the agent disconnect, remove a bond or disable Bluetooth, and which dependent interactions would that interrupt?", "kind": "action", "id": "bound-agent-authority-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-kinds", "name": "Kinds and varieties", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Bluetooth Classic (BR/EDR)", "Bluetooth Low Energy (LE / BLE)", "Bluetooth Mesh", "Bluetooth High Speed (AMP / 802.11 coexistence)", "Bluetooth Dual-Mode (BR/EDR + LE)", "Bluetooth LE Audio / Auracast", "Bluetooth Direction Finding (AoA/AoD)", "Bluetooth Channel Sounding" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "scheme": "Wikidata", "value_or_pattern": "Q16354", "note": "Bluetooth" } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Bluetooth Core Specification (Bluetooth SIG)", "IEEE 802.15.1 (historical IEEE adoption of Bluetooth PHY/MAC)" ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Wireless audio (headphones, speakers, car kits)", "HID peripherals (mice, keyboards, game controllers)", "Wearables and health sensors", "Smartphone tethering and file transfer", "Industrial/IoT beacons and mesh lighting" ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "quantity": "Carrier frequency", "typical_range": "2400-2483.5", "unit": "MHz" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "RF interference in the 2.4 GHz ISM band", "Pairing/authentication attacks (BlueBorne, KNOB, BIAS)", "Range and throughput collapse through walls or congestion" ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "ISM-band channel restrictions and power limits differ by region (e.g. some 2.4 GHz channels restricted in parts of Asia)" ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "name": "Wi-Fi (IEEE 802.11)", "difference": "Wi-Fi is a LAN technology with infrastructure/AP association and typically higher throughput; Bluetooth is a WPAN with pairing, piconets, and much lower typical power/range." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of Bluetooth this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend Bluetooth to denote the communication technology, a physical interface or a deployed system, and how should that interpretation align with its PHY.OBJ placement?", "Does an existing Vercy world model already own Bluetooth or the relevant wireless-interface concept, requiring this entry to link to it?", "Should Bluetooth Mesh, LE Audio, broadcast services and specialised positioning capabilities be extensions of this entry or references to neighbouring models?", "Which authoritative specification sections and implementation documents should support the final capability, security and lifecycle findings?", "Which controller and platform observations will actually be available to agents, especially for address resolution, pairing authentication and negotiated link parameters?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 28 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "unclassified", "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 Bluetooth, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise a Bluetooth implementation, assess its supported interactions and current state, and decide which discovery, connection, data exchange or configuration actions are appropriate.", "characteristics": { "substance": "material", "origin": "manufactured", "agency": "inert", "mobility": "varies" }, "whatYouCanDoWithIt": [ "observed and measured" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: Bluetooth 5.", "1 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 101 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 Bluetooth, and on what evidence are they told apart?" ], "whatItIsMadeOf": "matter you can touch", "physicalCharacter": [ "Mobility varies between examples.", "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": [ "Recognised by form and material. The registry holds no appearance data, so what a Bluetooth looks like has to come from research." ], "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": [ "Bluetooth 5" ] } ], "standing": "Described in 101 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 1 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 Bluetooth from another, and a Bluetooth 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 Bluetooth, 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 Bluetooth, 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 Bluetooth 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 Bluetooth, 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 Bluetooth, 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 Bluetooth 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 Bluetooth 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 Bluetooth, 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 Bluetooth, 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 Bluetooth 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 Bluetooth from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a Bluetooth, 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 Bluetooth, 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 Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "form-and-composition", "name": "Form, composition and condition", "description": "What a Bluetooth is made of, what shape and size it takes, and what state it is in.", "rationale": "A physical thing can be measured, and a model that cannot record its measurements cannot support any decision that depends on them.", "layers": [ { "id": "form-and-dimensions", "name": "Form and dimensions", "description": "Shape, size, mass and the ranges these take across examples.", "findings": [ { "id": "measurable-dimensions", "name": "Measurable dimensions and their units", "description": "The quantities worth recording and the units they are recorded in.", "questions": [ { "id": "measurable-dimensions-q01", "text": "What identifies and describes the dimensions of a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "measurable-dimensions-q02", "text": "Who or what asserted this about the dimensions of a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "measurable-dimensions-q03", "text": "What may an agent decide or do once the dimensions of a Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "material-and-composition", "name": "Material and composition", "description": "Materials, parts and how they are put together.", "findings": [ { "id": "parts-and-materials", "name": "Parts and materials", "description": "What a Bluetooth is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "parts-and-materials-q02", "text": "Who or what asserted this about the composition of a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "parts-and-materials-q03", "text": "What may an agent decide or do once the composition of a Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "condition-and-integrity", "name": "Condition and integrity", "description": "Wear, damage, health and the difference between working and broken.", "findings": [ { "id": "condition-assessment", "name": "Condition, damage and health", "description": "How the condition of a Bluetooth is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "condition-assessment-q02", "text": "Who or what asserted this about the condition of a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "condition-assessment-q03", "text": "What may an agent decide or do once the condition of a Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "place-and-movement", "name": "Place and movement", "description": "Where a Bluetooth is, how it got there and where it may go (varies).", "rationale": "A thing that can move needs its position recorded with a time, or every later claim about it is about a place it has left.", "layers": [ { "id": "location-and-placement", "name": "Location and placement", "description": "Position, containment and the reference frame the position is given in.", "findings": [ { "id": "position-and-frame", "name": "Position, container and reference frame", "description": "Where a Bluetooth is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "position-and-frame-q02", "text": "Who or what asserted this about the location of a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "position-and-frame-q03", "text": "What may an agent decide or do once the location of a Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "movement-and-transfer", "name": "Movement and transfer", "description": "How a Bluetooth is carried, installed or relocated.", "findings": [ { "id": "movement-events", "name": "Movement events and constraints", "description": "What counts as a movement, what records it and what limits it.", "questions": [ { "id": "movement-events-q01", "text": "What identifies and describes the movement of a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "movement-events-q02", "text": "Who or what asserted this about the movement of a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "movement-events-q03", "text": "What may an agent decide or do once the movement of a Bluetooth 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 Bluetooth 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 Bluetooth between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a Bluetooth, 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 Bluetooth, 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 Bluetooth 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 Bluetooth, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a Bluetooth 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 Bluetooth, 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 Bluetooth, 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 Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "use-and-operation", "name": "Use and operation", "description": "What can be done with a Bluetooth and what it takes to do it.", "rationale": "An agent that can recognise a thing but not act on it has only half a model.", "layers": [ { "id": "intended-use", "name": "Intended use and function", "description": "What a Bluetooth is for, and what it is used for anyway.", "findings": [ { "id": "function-and-purpose", "name": "Function, purpose and misuse", "description": "The function a Bluetooth performs and the uses that fall outside it.", "questions": [ { "id": "function-and-purpose-q01", "text": "What identifies and describes the use of a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "function-and-purpose-q02", "text": "Who or what asserted this about the use of a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "function-and-purpose-q03", "text": "What may an agent decide or do once the use of a Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "handling-and-procedure", "name": "Handling and procedure", "description": "The steps, skills and tools involved in using a Bluetooth.", "findings": [ { "id": "procedures-and-skills", "name": "Procedures, skills and required tools", "description": "What an agent needs before it can act on a Bluetooth at all.", "questions": [ { "id": "procedures-and-skills-q01", "text": "What identifies and describes handling a Bluetooth, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "procedures-and-skills-q02", "text": "Who or what asserted this about handling a Bluetooth, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "procedures-and-skills-q03", "text": "What may an agent decide or do once handling a Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a Bluetooth 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 Bluetooth and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a Bluetooth, 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 Bluetooth, 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 Bluetooth 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 Bluetooth is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a Bluetooth, 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 Bluetooth, 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 Bluetooth is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 13, "findings": 15, "questions": 45 } } } }