{ "model": { "rank": 4520, "code": "thing-q165194", "model_id": "vr.tr.application-programming-interface", "name": "application programming interface", "purpose": "Enable an agent to recognise an application programming interface, assess its contract and operational state, and determine which programmatic interactions are supported and permitted.", "family": "Thing Registry", "category": "Physical world and living systems", "status": "research-draft", "kind": "thing", "plane": "PHY", "domain": "PHY.OBJ", "industry": "", "version": "", "url": "/models/thing/q165194/", "tier": 2, "score": 74, "payload": { "layer": "wikidata", "aliases": [ "Go library", "Rust library", "PHP library", "server-side web API", "Push API", "WebExtension API", "Subsonic API", "Type library", "COM interface", "Amazon S3 API", "OAI-PMH endpoint", "database abstraction layer", "database interface", "D-Bus interface", "Message Passing Interface", "Glide", "CNG key storage provider", "web API", "DirectX", "service provider interface", "foreign function interface", "access method", "Netscape Server Application Programming Interface", "open API", "Server Application Programming Interface", "client-side web API", "libretro core API" ], "aliasCount": 27, "merged": 27, "knownIn": 74, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q165194", "url": "https://www.wikidata.org/wiki/Q165194", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T20:25:30Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 21.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: 01a087d7-e0b2-7713-879a-92c6c33912ba\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: application programming interface\nSense to describe: (none recorded)\nDomain code: PHY.OBJ\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:", "usd": 0, "recall": true }, "codex": { "seconds": 63.3, "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: 01a087d7-e0a7-7300-8a56-79c733d838f2\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: application programming interface\nRegistry id: vr.tr.application-programming-interface\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recor" } } }, "metaModel": { "id": "THING-Q165194", "registryId": "vr.tr.application-programming-interface", "name": "application programming interface", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q165194/", "model": { "registry_id": "vr.tr.application-programming-interface", "name": "application programming interface", "purpose": "Enable an agent to recognise an application programming interface, assess its contract and operational state, and determine which programmatic interactions are supported and permitted.", "definition": "An application programming interface (API) is a specified set of operations, data types and interaction rules through which software components access functionality or exchange information without requiring knowledge of one another's internal implementation.", "scope_statement": "This model owns the API as a defined boundary through which software exposes capabilities to other software, including local library, operating-system and remote-service interfaces; it distinguishes the interface contract from its implementations, deployments and individual calls, while leaving the supplied PHY / PHY.OBJ classification open for review.", "in_scope": [ "Exposed operations, callable symbols, messages, events and associated semantics", "Input and output types, validation rules, errors and behavioural guarantees", "Invocation mechanisms, bindings and interaction patterns", "Access requirements, permissions and constraints on side effects", "Observable interface state, compatibility and lifecycle" ], "out_of_scope": [ "Internal algorithms and architecture of implementing software", "Complete business models and records accessed through the interface", "Hosting infrastructure and physical equipment", "Human-facing user interfaces", "Individual requests, responses and execution traces as independent records", "Complete SDK products and application binary interfaces, except where they constrain API use" ], "distinguishing_features": [ "Exposes operations or interactions intended for consumption by software; a human-facing screen alone does not establish an API.", "Defines how consumers request or receive capabilities and what those interactions mean; a data format alone is insufficient.", "Can retain the same contract across different implementations or deployments, so a server address or running process does not identify the whole API.", "May operate through local function calls, system calls or message exchange; network access and HTTP are not required.", "Is the exposed interface rather than merely its documentation, SDK wrapper or underlying transport protocol." ], "characteristics": [ { "name": "Interface form", "kind": "category", "unit_or_values": "Library API, operating-system API, remote-service API, event interface, other documented form", "why_it_matters": "Determines how a consumer discovers, binds to and invokes the interface." }, { "name": "Contract authority", "kind": "relation", "unit_or_values": "Links to authoritative specifications, declarations, documentation and responsible maintainers", "why_it_matters": "Identifies which evidence governs interpretation when descriptions or implementations disagree." }, { "name": "Interaction pattern", "kind": "category", "unit_or_values": "Synchronous call, asynchronous request, callback, publish-subscribe, stream; combinations allowed", "why_it_matters": "Determines completion handling, correlation and consumer control flow." }, { "name": "Operation effect", "kind": "category", "unit_or_values": "Read, create, update, delete, execute, subscribe or mixed; assessed per operation", "why_it_matters": "Makes consequential interactions distinguishable from observation." }, { "name": "Access context", "kind": "relation", "unit_or_values": "Required identity, permission scopes, process privileges, tenant and resource constraints", "why_it_matters": "Determines whether a particular consumer may perform a particular operation." }, { "name": "Contract version and compatibility", "kind": "state", "unit_or_values": "Version identifier or unversioned; compatible, conditionally compatible, breaking or unassessed relative to a named baseline", "why_it_matters": "Prevents assuming that an existing consumer remains valid after a change." }, { "name": "Invocation limits", "kind": "measurement", "unit_or_values": "Where applicable: requests per stated interval, concurrent calls, bytes per message and seconds per timeout; include scope and evidence", "why_it_matters": "Constrains call planning, batching and resource consumption." }, { "name": "Observed usability", "kind": "state", "unit_or_values": "Available, degraded, unavailable or unknown for a specified implementation, consumer context and observation time", "why_it_matters": "Separates a valid interface contract from whether an agent can currently use a particular realization." }, { "name": "Lifecycle stage", "kind": "state", "unit_or_values": "Experimental, supported, deprecated, retired or unknown according to the provider", "why_it_matters": "Guides adoption, migration and continued reliance." } ], "affordances": [ "Discover exposed capabilities and select an operation that matches a task.", "Construct and validate calls or messages against the applicable contract.", "Assess authorization and expected side effects before invoking an operation.", "Invoke permitted operations and interpret results, errors or emitted events.", "Choose retry, cancellation and recovery actions from documented guarantees.", "Compare contract versions and identify required consumer migrations." ] }, "sources": [], "structure": { "bundles": [ { "id": "interface-identity-and-contract", "name": "Interface identity and contract", "description": "Establishes which API is being described and which declarations govern its exposed capabilities.", "rationale": "An agent must distinguish an interface from similarly named products, wrappers and deployments before relying on its contract.", "layers": [ { "id": "identity-and-boundary", "name": "Identity and boundary", "description": "Locates the software interaction boundary and relates it to providers, consumers and realizations.", "findings": [ { "id": "api-boundary", "name": "API boundary", "description": "Record the interface's identity, intended consumers and separation from its implementing software, SDKs and deployment locations.", "questions": [ { "text": "Which software capabilities and consumer interactions define this API's boundary?", "kind": "definition", "id": "api-boundary-q01" }, { "text": "Which named SDKs, services, bindings or deployments implement or wrap this API rather than constitute separate API contracts?", "kind": "boundary", "id": "api-boundary-q02" } ] } ] }, { "id": "contract-authority-and-surface", "name": "Contract authority and surface", "description": "Identifies authoritative descriptions and the operations or messages they expose.", "findings": [ { "id": "authoritative-capability-inventory", "name": "Authoritative capability inventory", "description": "Record exposed functions, methods, endpoints, events or messages and the evidence defining their supported behaviour.", "questions": [ { "text": "Which specification, source declarations or provider documentation govern this contract, and for which version?", "kind": "provenance", "id": "authoritative-capability-inventory-q01" }, { "text": "Which callable operations or exchanged messages are supported, and which observed behaviours are undocumented?", "kind": "definition", "id": "authoritative-capability-inventory-q02" } ] } ] } ] }, { "id": "inputs-outputs-and-effects", "name": "Inputs, outputs and effects", "description": "Describes what an interaction accepts, returns and changes.", "rationale": "A syntactically valid invocation can still be semantically wrong or produce unintended changes.", "layers": [ { "id": "value-contracts", "name": "Value contracts", "description": "Captures the meaning and admissible forms of arguments, payloads and results.", "findings": [ { "id": "types-validation-and-representation", "name": "Types, validation and representation", "description": "Record required values, types, units, encodings, nullability, defaults and constraints for each interaction.", "questions": [ { "text": "What types, required fields, units and validation rules apply to each operation's inputs and outputs?", "kind": "definition", "id": "types-validation-and-representation-q01" }, { "text": "How do omission, null values, default values and unknown fields affect interpretation?", "kind": "boundary", "id": "types-validation-and-representation-q02" } ] } ] }, { "id": "behavioural-contracts", "name": "Behavioural contracts", "description": "Captures operation meaning beyond value shapes.", "findings": [ { "id": "preconditions-effects-and-guarantees", "name": "Preconditions, effects and guarantees", "description": "Record prerequisites, observable changes, result meaning and any atomicity, consistency or idempotency guarantees.", "questions": [ { "text": "What must hold before invocation, and what results or state changes does successful completion guarantee?", "kind": "definition", "id": "preconditions-effects-and-guarantees-q01" }, { "text": "Which operations cause external effects, and under what documented conditions can they be repeated or reversed?", "kind": "action", "id": "preconditions-effects-and-guarantees-q02" } ] } ] } ] }, { "id": "binding-and-execution", "name": "Binding and execution", "description": "Describes how consumers reach the interface and manage an interaction through completion.", "rationale": "Correct API use depends on binding, sequencing and lifetime rules that cannot be inferred from operation names.", "layers": [ { "id": "binding-and-addressing", "name": "Binding and addressing", "description": "Captures the mechanism for locating and connecting to the intended interface realization.", "findings": [ { "id": "consumer-binding-requirements", "name": "Consumer binding requirements", "description": "Record applicable imports, symbol resolution, endpoint discovery, protocol negotiation and runtime requirements.", "questions": [ { "text": "How does a consumer locate and bind to this API in each supported interface form?", "kind": "action", "id": "consumer-binding-requirements-q01" }, { "text": "Which language, runtime, transport or platform requirements constrain a supported binding?", "kind": "boundary", "id": "consumer-binding-requirements-q02" } ] } ] }, { "id": "interaction-lifecycle", "name": "Interaction lifecycle", "description": "Captures call sequencing, completion signals and ownership of resources created during interaction.", "findings": [ { "id": "completion-ordering-and-resource-lifetime", "name": "Completion, ordering and resource lifetime", "description": "Record synchronous or asynchronous completion, event correlation, ordering, cancellation and cleanup obligations where applicable.", "questions": [ { "text": "How does the consumer distinguish acceptance, progress and completion, and correlate subsequent results or events?", "kind": "definition", "id": "completion-ordering-and-resource-lifetime-q01" }, { "text": "What sequencing, concurrency, cancellation and resource-release rules must the consumer follow?", "kind": "action", "id": "completion-ordering-and-resource-lifetime-q02" } ] } ] } ] }, { "id": "access-and-operational-recovery", "name": "Access and operational recovery", "description": "Establishes who may interact, under which limits, and how failures should be handled.", "rationale": "An agent needs explicit permission and recovery evidence to avoid unauthorized actions, duplicate effects and uncontrolled retries.", "layers": [ { "id": "authorization-context", "name": "Authorization context", "description": "Captures the identity and privilege conditions applicable to an invocation.", "findings": [ { "id": "effective-operation-permissions", "name": "Effective operation permissions", "description": "Record authentication mechanisms and operation-specific permissions, including process privileges or tenant boundaries where relevant.", "questions": [ { "text": "What identity or execution context is required, and how is its authority established?", "kind": "definition", "id": "effective-operation-permissions-q01" }, { "text": "Is the proposed operation permitted for this consumer, target resource and tenant or process context?", "kind": "action", "id": "effective-operation-permissions-q02" } ] } ] }, { "id": "limits-errors-and-recovery", "name": "Limits, errors and recovery", "description": "Captures operational constraints and the meaning of unsuccessful or ambiguous outcomes.", "findings": [ { "id": "failure-aware-invocation", "name": "Failure-aware invocation", "description": "Record error forms, timeout meaning, applicable quotas and evidence supporting retry or reconciliation.", "questions": [ { "text": "What documented or measured call, payload, concurrency and timing limits apply, with what units and scope?", "kind": "measurement", "id": "failure-aware-invocation-q01" }, { "text": "After an error, timeout or lost response, how can an agent determine whether effects occurred and whether retrying is safe?", "kind": "action", "id": "failure-aware-invocation-q02" }, { "text": "Which observations establish current usability for the relevant implementation and consumer context?", "kind": "provenance", "id": "failure-aware-invocation-q03" } ] } ] } ] }, { "id": "compatibility-and-evolution", "name": "Compatibility and evolution", "description": "Tracks supported contract changes and the evidence that consumers can continue operating.", "rationale": "An API can remain reachable while changes to values, behaviour or support policy invalidate existing consumers.", "layers": [ { "id": "version-selection-and-compatibility", "name": "Version selection and compatibility", "description": "Captures how versions are selected and which changes preserve consumer expectations.", "findings": [ { "id": "consumer-compatibility-boundary", "name": "Consumer compatibility boundary", "description": "Record version selection mechanisms and compatibility assessments against a named contract and consumer baseline.", "questions": [ { "text": "How is the applicable contract version selected or identified for an invocation?", "kind": "definition", "id": "consumer-compatibility-boundary-q01" }, { "text": "Which changes to signatures, payloads, errors or behaviour would break the specified consumer's expectations?", "kind": "boundary", "id": "consumer-compatibility-boundary-q02" } ] } ] }, { "id": "support-and-conformance-evidence", "name": "Support and conformance evidence", "description": "Connects lifecycle declarations and observed implementation behaviour to adoption and migration decisions.", "findings": [ { "id": "support-status-and-migration-readiness", "name": "Support status and migration readiness", "description": "Record provider lifecycle notices, implementation deviations and evidence needed to adopt or migrate a consumer.", "questions": [ { "text": "Which dated provider notices establish support, deprecation or retirement, and what replacement is identified?", "kind": "provenance", "id": "support-status-and-migration-readiness-q01" }, { "text": "What contract checks and consumer changes are needed before adopting this implementation or migrating to its successor?", "kind": "action", "id": "support-status-and-migration-readiness-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 general software-interface sense; the supplied PHY.OBJ classification should be reviewed because an API is not ordinarily a physical object.", "The listed kinds overlap, and the standards apply to particular API families rather than to every API.", "Latency, throughput, availability and rate limits characterize particular API implementations or services; no meaningful universal typical ranges apply." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of application programming interface 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": [ "Library APIs", "Operating-system APIs", "Remote procedure call APIs", "HTTP-based web APIs", "Database access APIs", "Graphics and compute APIs" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of application programming interface 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": "URI", "value_or_pattern": "scheme:[//authority]path[?query][#fragment]", "note": "Network APIs may use URIs to identify resources or endpoints; a URI is not a universal identifier for an API specification." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of application programming interface 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": [ "OpenAPI Specification - OpenAPI Initiative; a description format for HTTP APIs.", "POSIX, IEEE Std 1003.1 - IEEE; standardizes operating-system interfaces, among other facilities.", "HTTP Semantics, RFC 9110 - IETF; defines protocol semantics used by HTTP APIs.", "OAuth 2.0 Authorization Framework, RFC 6749 - IETF; defines delegated authorization commonly used to control API access.", "Web IDL - WHATWG; defines an interface description language used to specify web-platform APIs." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of application programming interface 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": [ "Calling reusable functions supplied by software libraries.", "Accessing operating-system services such as files, processes and networking.", "Connecting applications to remote services for payments, mapping or messaging.", "Allowing plugins and extensions to interact with a host application.", "Providing programmatic access to databases, graphics processors and other computing facilities." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of application programming interface 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": [ "Incompatible interface changes break existing clients.", "Ambiguous contracts or inconsistent error handling lead to incorrect integration.", "Missing authentication or inadequate authorization exposes data or privileged operations.", "Timeouts and retries can duplicate side effects unless operations provide suitable idempotency guarantees.", "Unbounded requests, excessive resource consumption or dependency outages degrade service availability." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of application programming interface 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": [ "The core concept is not region-specific, but APIs processing personal data may face jurisdiction-specific requirements concerning access, retention and cross-border transfer." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of application programming interface 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": "implementation", "difference": "The API specifies externally available interactions; the implementation contains the code and mechanisms that perform them." }, { "name": "communication protocol", "difference": "A protocol defines communication rules between participants; an API defines a software-facing interface and may operate locally or use a protocol remotely." }, { "name": "application binary interface", "difference": "An ABI specifies binary-level conventions such as calling conventions and data layout; an API generally specifies interactions at the programming or service-contract level." }, { "name": "software development kit", "difference": "An SDK packages development tools and supporting materials and may include libraries implementing or accessing an API." }, { "name": "web service", "difference": "A web service supplies functionality over a network; its API describes how software accesses that functionality." }, { "name": "user interface", "difference": "A user interface primarily supports human interaction; an API supports interaction by software." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of application programming interface this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does PHY / PHY.OBJ intentionally classify the API as a realized software boundary, or should the registry classify its contract in another plane?", "Which existing Vercy world model, if any, already owns the API concept and should serve as its single source of truth?", "Should this registry entry encompass local library APIs, operating-system APIs and remote interfaces equally, and where should its boundary with an application binary interface fall?", "Which authoritative sources should establish the researched definition and terminology for this broad API model?", "How should later publications distinguish contractual guarantees from provider claims and observations of a particular implementation?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 29 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "device, machine or tool", "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 application programming interface, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an agent to recognise an application programming interface, assess its contract and operational state, and determine which programmatic interactions are supported and permitted.", "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: Go library, Rust library, PHP library, server-side web API, Push API, WebExtension API, Subsonic API, Type library, COM interface, Amazon S3 API, OAI-PMH endpoint, database abstraction layer.", "27 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 74 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 application programming interface, 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, by the arrangement of its controls, and by markings - a plate, a model number, a certification mark. Form alone rarely separates two models that do very different things." ], "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": [ "Go library", "Rust library", "PHP library", "server-side web API", "Push API", "WebExtension API", "Subsonic API", "Type library", "COM interface", "Amazon S3 API", "OAI-PMH endpoint", "database abstraction layer" ] } ], "standing": "Described in 74 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 27 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 application programming interface from another, and a application programming interface 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 application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface 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 application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface 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 application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface 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 application programming interface is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface 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 application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface 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 application programming interface between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a application programming interface 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 application programming interface, 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 application programming interface, 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 application programming interface is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "function-and-principle", "name": "Function and operating principle", "description": "What application programming interface is for and how it achieves it.", "rationale": "Two devices with the same name can work on different principles, and the principle is what predicts failure and constrains use.", "layers": [ { "id": "intended-function", "name": "Intended function", "description": "The job it does, and the jobs it is used for anyway.", "findings": [ { "id": "function-record", "name": "Function, principle and variants", "description": "What it does, how, and which variants do it differently.", "questions": [ { "id": "function-record-q01", "text": "What function does application programming interface perform, on what operating principle, and which variants differ in that principle?", "kind": "definition" }, { "id": "function-record-q02", "text": "What use falls outside the intended function but happens in practice?", "kind": "boundary" } ] } ] }, { "id": "capacity-and-rating", "name": "Capacity and rating", "description": "The numbers that say what it can do and where it stops.", "findings": [ { "id": "ratings", "name": "Ratings and their conditions", "description": "Rated capacity, power, throughput and the conditions each assumes.", "questions": [ { "id": "ratings-q01", "text": "What ratings characterise application programming interface, in what units, and under what stated conditions?", "kind": "measurement" }, { "id": "ratings-q02", "text": "What happens beyond the rating - degradation, refusal, damage - and how is that detected?", "kind": "action" } ] } ] } ] }, { "id": "operation-and-state", "name": "Operation, controls and state", "description": "How application programming interface is operated and what state it is in right now.", "rationale": "An agent acting on a device needs its current state and the controls that change it, not just its specification.", "layers": [ { "id": "controls-and-modes", "name": "Controls and modes", "description": "What can be set, what that changes, and what is interlocked.", "findings": [ { "id": "control-surface", "name": "Control surface and interlocks", "description": "The settings available and the conditions that block them.", "questions": [ { "id": "control-surface-q01", "text": "What controls and modes does application programming interface have, and what does each change?", "kind": "definition" }, { "id": "control-surface-q02", "text": "Which actions are interlocked or forbidden in which state, and what must be true before acting?", "kind": "action" } ] } ] }, { "id": "condition-and-maintenance", "name": "Condition and maintenance", "description": "Wear, service intervals, consumables and the line between working and broken.", "findings": [ { "id": "service-record", "name": "Condition, service and consumables", "description": "What is consumed, what is serviced, and how condition is judged.", "questions": [ { "id": "service-record-q01", "text": "What consumables and service does application programming interface need, at what interval, and on whose authority?", "kind": "measurement" }, { "id": "service-record-q02", "text": "What evidence separates a unit that is working from one that is out of service?", "kind": "boundary" } ] } ] } ] }, { "id": "kind-model-unit", "name": "Kind, model and unit", "description": "Whether a claim about application programming interface is about the kind, a product line, or one physical unit.", "rationale": "This is the boundary most often got wrong for made things, and getting it wrong mixes a catalogue entry with the machine in the yard.", "layers": [ { "id": "level-of-reference", "name": "Level of reference", "description": "The three levels and what belongs at each.", "findings": [ { "id": "level-rules", "name": "What belongs to kind, model and unit", "description": "Which properties are shared by all of them and which are not.", "questions": [ { "id": "level-rules-q01", "text": "Which facts about application programming interface hold for every one of them, which for a model, and which only for one unit?", "kind": "boundary" }, { "id": "level-rules-q02", "text": "What identifies an individual unit, and what should an agent do when it has only the kind?", "kind": "action" } ] } ] }, { "id": "standards-and-conformity", "name": "Standards and conformity", "description": "The standards a working example must meet and who attests it.", "findings": [ { "id": "conformity", "name": "Standards, marks and attestation", "description": "Which standard applies, who certifies, and what the mark means.", "questions": [ { "id": "conformity-q01", "text": "Which standards govern application programming interface, issued by whom, and what does conformity actually assert?", "kind": "provenance" }, { "id": "conformity-q02", "text": "What may an agent conclude from a certification mark, and what may it not?", "kind": "boundary" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a application programming interface 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 application programming interface and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a application programming interface, 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 application programming interface, 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 application programming interface 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 application programming interface is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a application programming interface, 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 application programming interface, 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 application programming interface is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 8, "layers": 17, "findings": 19, "questions": 51 } } } }