{ "model": { "rank": 5425, "code": "thing-q174989", "model_id": "vr.tr.file-system", "name": "file system", "purpose": "Enable an AI agent to recognise a computer file system, assess its accessibility and integrity, and determine which file and maintenance operations its semantics and current state permit.", "family": "Thing Registry", "category": "Physical world and living systems", "status": "research-draft", "kind": "thing", "plane": "PHY", "domain": "PHY.OBJ", "industry": "", "version": "", "url": "/models/thing/q174989/", "tier": 2, "score": 67, "payload": { "layer": "wikidata", "aliases": [ "extended file system", "clustered file system", "cryptographic file system", "network file system", "Hierarchical File System", "A Virtual File System", "+D", "SAFS", "Linux file system", "Sinclair QL filesystem", "log-structured file system", "flash file system", "journaling file system", "multi-device file system", "Record-oriented filesystem", "Steganographic file system", "synthetic file system", "hierarchical file system", "Filesystem in Userspace", "OrangeFS", "distributed file system for cloud", "Self-certifying File System" ], "aliasCount": 22, "merged": 22, "knownIn": 67, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q174989", "url": "https://www.wikidata.org/wiki/Q174989", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T22:20:51Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 20.2, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a08841-7d2a-7fd1-892e-6033a12d3d5d\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: file system\nSense to describe: (none recorded)\nDomain code: PHY.OBJ\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 005: 1001 reg", "usd": 0, "recall": true }, "codex": { "seconds": 63.1, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a08841-7d19-76c2-af44-033dbdb723c3\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: file system\nRegistry id: vr.tr.file-system\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\n\n" } } }, "metaModel": { "id": "THING-Q174989", "registryId": "vr.tr.file-system", "name": "file system", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q174989/", "model": { "registry_id": "vr.tr.file-system", "name": "file system", "purpose": "Enable an AI agent to recognise a computer file system, assess its accessibility and integrity, and determine which file and maintenance operations its semantics and current state permit.", "definition": "A file system is a method of organizing, naming, storing and retrieving files and their metadata, implemented through data structures and operations over storage devices or other data services.", "scope_statement": "This model covers the computer file system as a mechanism for organising, naming, storing or exposing files and associated metadata, including the properties needed to assess an implementation or deployed instance; it does not treat the file system as the physical storage device itself.", "in_scope": [ "File and directory organisation, object identity and pathname resolution", "File contents, metadata and supported object types", "Storage backing, allocation and capacity accounting", "Access rules, operation semantics and concurrent access", "Mount or attachment state, integrity, recovery and maintenance" ], "out_of_scope": [ "Physical construction, electrical characteristics and health of storage devices", "Internal meaning and application-level correctness of stored documents or datasets", "General operating-system scheduling, process management and virtual memory", "Network transport operation beyond its effects on file-system access", "Database query semantics and transaction models", "Paper filing systems and archival classification schemes" ], "distinguishing_features": [ "Provides file objects and naming or lookup rules; a raw block device provides addressable blocks without necessarily providing files.", "Defines how file content and metadata are accessed or changed; an archive format alone does not establish a live file-system service.", "Organises or exposes files independently of their application-level meaning; a database primarily organises records under a data and query model.", "Is distinct from a mount point: the mount point attaches a file system to a namespace and is not the complete file system.", "Can be persistent, memory-backed, remote or synthetic, so neither a physical disk nor durable storage is a necessary recognition test." ], "characteristics": [ { "name": "Backing and exposure type", "kind": "category", "unit_or_values": "local persistent storage | memory-backed | remote service | synthetic | layered | other; combinations permitted", "why_it_matters": "Determines dependencies, persistence expectations and which maintenance operations apply." }, { "name": "Implementation and format", "kind": "relation", "unit_or_values": "Implementation, driver or service; format and feature version where applicable", "why_it_matters": "Identifies the actual source of supported semantics and compatibility constraints." }, { "name": "Attachment and write state", "kind": "state", "unit_or_values": "Detached, attached or inaccessible; read-only or writable; observed namespace and time", "why_it_matters": "Determines whether operations can reach the file system and whether mutation is currently permitted." }, { "name": "Namespace rules", "kind": "category", "unit_or_values": "Hierarchy or other organisation; case handling, encoding, normalisation, reserved names and path limits", "why_it_matters": "Controls whether names are valid, distinct and portable." }, { "name": "Supported object types", "kind": "category", "unit_or_values": "Regular files, directories, symbolic links, special objects and implementation-specific types", "why_it_matters": "Prevents an agent from treating every pathname as an ordinary byte-stream file." }, { "name": "Capacity and allocation", "kind": "measurement", "unit_or_values": "Logical, allocated, free and caller-available bytes; object counts or limits where applicable; unknown or not applicable permitted", "why_it_matters": "Distinguishes apparent content size from actual allocation and writable capacity." }, { "name": "Access-control mechanism", "kind": "category", "unit_or_values": "Permission bits, access-control lists, capabilities, server policy or other mechanisms; combinations permitted", "why_it_matters": "Identifies how the effective caller's authority must be evaluated." }, { "name": "Visibility and durability guarantees", "kind": "category", "unit_or_values": "Documented guarantees for specific operations, concurrent observers, synchronisation calls and failure conditions", "why_it_matters": "Separates successful requests from changes that other clients can observe or that survive a failure." }, { "name": "Integrity assessment", "kind": "state", "unit_or_values": "Unchecked | no issue detected within stated checks | suspected inconsistency | detected inconsistency | recovery in progress; evidence and timestamp", "why_it_matters": "Supports proportionate recovery decisions without equating a successful mount with verified integrity." } ], "affordances": [ "Inspect capabilities, namespace rules, attachment state and storage dependencies.", "Resolve paths and enumerate objects while accounting for links and mount boundaries.", "Read, create, update, rename, link or remove objects when supported and authorised.", "Assess available capacity, quota limits and allocation effects before writing.", "Select supported synchronisation or snapshot operations according to required consistency and durability.", "Evaluate integrity evidence and plan authorised checking, recovery or attachment changes." ] }, "sources": [], "structure": { "bundles": [ { "id": "identity-and-boundaries", "name": "Identity and boundaries", "description": "Establishes what constitutes the file system and which implementation and backing resources determine its behaviour.", "rationale": "A format, driver, volume and mounted instance are related but different referents with different properties.", "layers": [ { "id": "kind-and-instance", "name": "Kind and instance", "description": "Distinguishes shared file-system semantics from a particular deployment.", "findings": [ { "id": "referent-and-implementation", "name": "Referent and implementation", "description": "Record whether an observation concerns a file-system kind, implementation or instance, and identify applicable versions and enabled features.", "questions": [ { "text": "Does the description identify a file-system kind, an on-disk format, a driver or service, or a particular instance?", "kind": "definition", "id": "referent-and-implementation-q01" }, { "text": "Which implementation documentation or instance inspection establishes its version and enabled features?", "kind": "provenance", "id": "referent-and-implementation-q02" } ] } ] }, { "id": "backing-and-attachments", "name": "Backing and attachments", "description": "Locates the file system relative to storage resources and exposed namespaces.", "findings": [ { "id": "storage-and-namespace-boundary", "name": "Storage and namespace boundary", "description": "Record backing resources, remote or layered dependencies, and attachment locations without equating any one attachment with the whole instance.", "questions": [ { "text": "Which devices, pools, memory resources, remote exports or lower file-system layers back this instance?", "kind": "boundary", "id": "storage-and-namespace-boundary-q01" }, { "text": "Where is it exposed to the relevant agent, and which mount or layer boundaries can a path traversal cross?", "kind": "boundary", "id": "storage-and-namespace-boundary-q02" } ] } ] } ] }, { "id": "namespace-and-file-objects", "name": "Namespace and file objects", "description": "Captures naming, lookup, object identity and the distinction between file contents and metadata.", "rationale": "Correct file operations require knowing what a path identifies and whether multiple paths identify the same object.", "layers": [ { "id": "names-and-resolution", "name": "Names and resolution", "description": "Describes how names become object references.", "findings": [ { "id": "pathname-equivalence-and-traversal", "name": "Pathname equivalence and traversal", "description": "Record name validity, case and Unicode handling, lookup roots and link-resolution behaviour.", "questions": [ { "text": "Which naming rules determine whether two submitted pathnames resolve to the same name or object?", "kind": "definition", "id": "pathname-equivalence-and-traversal-q01" }, { "text": "How must an agent resolve a path while enforcing its permitted root and rules for symbolic links and mount crossings?", "kind": "action", "id": "pathname-equivalence-and-traversal-q02" } ] } ] }, { "id": "objects-and-metadata", "name": "Objects and metadata", "description": "Describes the objects reachable through the namespace and their observable attributes.", "findings": [ { "id": "object-type-identity-and-attributes", "name": "Object type, identity and attributes", "description": "Record supported object types, identity lifetime, link relationships and available metadata with its interpretation.", "questions": [ { "text": "Which object types are supported, and how can identity be tracked across renames, hard links and identifier reuse?", "kind": "definition", "id": "object-type-identity-and-attributes-q01" }, { "text": "Which timestamps, ownership fields, extended attributes or additional data streams exist, and what are their units and meanings?", "kind": "measurement", "id": "object-type-identity-and-attributes-q02" } ] } ] } ] }, { "id": "allocation-and-limits", "name": "Allocation and limits", "description": "Describes how content consumes resources and what constrains further growth.", "rationale": "A file system can reject writes despite apparently free space, and logical file size need not equal physical allocation.", "layers": [ { "id": "content-allocation", "name": "Content allocation", "description": "Relates logical file contents to allocated or shared storage.", "findings": [ { "id": "logical-and-allocated-size", "name": "Logical and allocated size", "description": "Distinguish logical length from allocated space and record relevant sparse-file, compression, sharing or copy-on-write behaviour.", "questions": [ { "text": "How are logical length and allocated storage measured, including units and accounting boundaries?", "kind": "measurement", "id": "logical-and-allocated-size-q01" }, { "text": "Which supported allocation features change the space required by copying, overwriting or deleting a file?", "kind": "action", "id": "logical-and-allocated-size-q02" } ] } ] }, { "id": "capacity-and-quotas", "name": "Capacity and quotas", "description": "Identifies resource ceilings and the capacity available to a particular caller.", "findings": [ { "id": "effective-write-headroom", "name": "Effective write headroom", "description": "Record space, metadata or object limits, quotas, reservations and backing-resource constraints that can prevent writes.", "questions": [ { "text": "How many bytes and object allocations are available to this caller after quotas and reservations are applied?", "kind": "measurement", "id": "effective-write-headroom-q01" }, { "text": "Which file-size, directory, metadata, pool or remote-service limits could prevent the planned write?", "kind": "boundary", "id": "effective-write-headroom-q02" } ] } ] } ] }, { "id": "authority-and-operation-semantics", "name": "Authority and operation semantics", "description": "Establishes who may operate on files and what individual or concurrent operations promise.", "rationale": "Path access, mutation authority and operation guarantees must be evaluated separately before an agent changes files.", "layers": [ { "id": "effective-authority", "name": "Effective authority", "description": "Connects caller identity and applicable policies to permitted operations.", "findings": [ { "id": "operation-specific-permissions", "name": "Operation-specific permissions", "description": "Evaluate access using the actual caller, path components, object rules and attachment or server restrictions.", "questions": [ { "text": "Which identities and permission mechanisms govern traversal, reading, writing, renaming and deletion?", "kind": "definition", "id": "operation-specific-permissions-q01" }, { "text": "Does the effective caller have authority for the complete planned operation, including its parent-directory changes?", "kind": "action", "id": "operation-specific-permissions-q02" } ] } ] }, { "id": "atomicity-and-concurrency", "name": "Atomicity and concurrency", "description": "Captures operation boundaries, simultaneous access and visibility between observers.", "findings": [ { "id": "mutation-and-observation-guarantees", "name": "Mutation and observation guarantees", "description": "Record operation-specific atomicity, locking and cache visibility without assuming that several file operations form a transaction.", "questions": [ { "text": "What guarantees apply to create, append, replace, rename and delete operations, especially across file-system boundaries?", "kind": "boundary", "id": "mutation-and-observation-guarantees-q01" }, { "text": "Which locking, conditional-operation or validation mechanisms are needed to handle concurrent writers and path changes?", "kind": "action", "id": "mutation-and-observation-guarantees-q02" } ] } ] } ] }, { "id": "durability-and-recovery", "name": "Durability and recovery", "description": "Captures persistence expectations, integrity evidence and conditions for maintenance or recovery.", "rationale": "Readable files and successful writes alone do not establish persistence, structural consistency or recoverability.", "layers": [ { "id": "persistence-contract", "name": "Persistence contract", "description": "Relates acknowledged changes to synchronisation and relevant failure scenarios.", "findings": [ { "id": "acknowledgement-and-survival", "name": "Acknowledgement and survival", "description": "Record whether persistence is intended and which operations and dependencies establish durability for data and namespace changes.", "questions": [ { "text": "What does a successful write or close establish, and which failure scenarios can still lose the acknowledged change?", "kind": "definition", "id": "acknowledgement-and-survival-q01" }, { "text": "Which documented synchronisation steps are required for the intended data and directory changes to survive the relevant failure?", "kind": "action", "id": "acknowledgement-and-survival-q02" } ] } ] }, { "id": "integrity-and-maintenance", "name": "Integrity and maintenance", "description": "Connects observed errors to checking, recovery and safe operational transitions.", "findings": [ { "id": "evidence-and-recovery-options", "name": "Evidence and recovery options", "description": "Record integrity-check coverage, reported errors, recovery mechanisms and prerequisites for operations that may alter or discard data.", "questions": [ { "text": "Which logs, checks or verified recovery copies support the current integrity assessment, and what remains unchecked?", "kind": "provenance", "id": "evidence-and-recovery-options-q01" }, { "text": "What prerequisites and consequences apply to checking, repair, snapshot restoration, read-only transition or detachment?", "kind": "action", "id": "evidence-and-recovery-options-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "The computing sense is assumed because no sense is recorded; the PHY.OBJ classification should be reviewed because a file system is not inherently a physical device.", "The listed kinds overlap: one implementation can be both distributed and network-accessible, for example.", "Capacity limits, filename restrictions, performance, durability guarantees and identifier formats depend on the specific implementation and version; no universal typical measurement range is supplied." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of file system 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": [ "Local disk file systems", "Network file systems", "Distributed file systems", "Memory-resident file systems", "Flash-oriented file systems", "Virtual or pseudo file systems" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of file system 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": "File-system UUID", "value_or_pattern": "Common textual form: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, using hexadecimal digits", "note": "Identifies an instance in implementations that support UUIDs; copying a file-system image can duplicate this identifier." }, { "scheme": "Volume label", "value_or_pattern": "A name subject to implementation-specific length and character restrictions", "note": "A human-readable identifier that need not be unique." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of file system 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": [ "IEEE Std 1003.1 / The Open Group POSIX specifies file-related interfaces and behavior, rather than an on-disk format.", "ISO 9660, issued by ISO, specifies volume and file structure for CD-ROM interchange.", "ECMA-167, issued by Ecma International, specifies volume and file structure for write-once and rewritable media." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of file system 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": [ "Organizing operating-system, application and user files on computers.", "Sharing files between computers over networks.", "Storing files on removable media and embedded devices.", "Providing distributed access to large collections of files.", "Exposing process, device or kernel information through file-like interfaces." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of file system 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": [ "Interrupted writes or power loss can leave inconsistent metadata or incomplete file contents; protection depends on implementation and configuration.", "Storage-media errors can corrupt data or make files inaccessible.", "Exhaustion of free space, metadata capacity or quotas can prevent new files or writes.", "Incorrect permissions or access-control configuration can expose files or block legitimate access.", "Implementation defects or unsuitable concurrent-access arrangements can cause corruption or data loss." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of file system 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": "Storage device", "difference": "A storage device supplies storage capacity; a file system supplies file organization and access semantics over that capacity or another backing service." }, { "name": "Partition", "difference": "A partition defines a region of a storage device; it may contain a file system but does not itself define files and directories." }, { "name": "Database management system", "difference": "A database management system organizes and queries records under a data model; a file system primarily exposes named files and associated metadata." }, { "name": "File manager", "difference": "A file manager is an application for interacting with files; a file system implements their underlying organization and access." }, { "name": "Physical filing system", "difference": "A physical filing system organizes tangible documents; this description covers the computing sense." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of file system this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend the computer file-system sense, and how should that sense be reconciled with its PHY / PHY.OBJ placement?", "Does an existing Vercy world model already own this concept or part of its scope?", "Which primary specifications and implementation documents should ground the common model while keeping platform-specific guarantees explicit?", "Should flat namespaces, object-store file interfaces and synthetic file systems share this scope, and which minimum file semantics define their inclusion?", "Which integrity, durability and capacity observations can be obtained reliably across local, remote and layered implementations?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 17, "questions": 27 } }, "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 file system, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise a computer file system, assess its accessibility and integrity, and determine which file and maintenance operations its semantics and current state permit.", "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: extended file system, clustered file system, cryptographic file system, network file system, Hierarchical File System, A Virtual File System, +D, SAFS, Linux file system, Sinclair QL filesystem, log-structured file system, flash file system.", "22 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 67 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 file system, 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": [ "extended file system", "clustered file system", "cryptographic file system", "network file system", "Hierarchical File System", "A Virtual File System", "+D", "SAFS", "Linux file system", "Sinclair QL filesystem", "log-structured file system", "flash file system" ] } ], "standing": "Described in 67 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 22 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 file system from another, and a file system 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 file system, 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 file system, 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 file system 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 file system, 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 file system, 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 file system 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 file system 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 file system, 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 file system, 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 file system 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 file system from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a file system, 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 file system, 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 file system 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 file system 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 file system, 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 file system, 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 file system 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 file system is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a file system, 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 file system, 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 file system 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 file system is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a file system, 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 file system, 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 file system 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 file system 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 file system is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a file system, 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 file system, 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 file system 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 file system 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 file system, 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 file system, 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 file system 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 file system 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 file system between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a file system, 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 file system, 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 file system 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 file system, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a file system 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 file system, 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 file system, 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 file system 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 file system 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 file system 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 file system, 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 file system 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 file system 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 file system 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 file system 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 file system 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 file system, 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 file system 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 file system and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a file system, 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 file system, 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 file system 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 file system is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a file system, 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 file system, 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 file system 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 } } } }