{ "model": { "rank": 6818, "code": "thing-q193076", "model_id": "vr.tr.functional-programming", "name": "functional programming", "purpose": "Enable an agent to recognise functional programming practices, assess their semantic and operational constraints, and choose transformations that preserve intended behaviour.", "family": "Thing Registry", "category": "Activities and processes", "status": "research-draft", "kind": "thing", "plane": "ACT", "domain": "ACT.ACT", "industry": "", "version": "", "url": "/models/thing/q193076/", "tier": 2, "score": 58, "payload": { "layer": "wikidata", "aliases": [ "purely functional programming", "functional logic programming", "functional reactive programming", "total functional programming" ], "aliasCount": 4, "merged": 4, "knownIn": 58, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q193076", "url": "https://www.wikidata.org/wiki/Q193076", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T23:34:18Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 17.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: 01a08884-c9cc-7493-82ca-2912b9b4bc53\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: functional programming\nSense to describe: (none recorded)\nDomain code: ACT.ACT\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 00", "usd": 0, "recall": true }, "codex": { "seconds": 59.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: 01a08884-c9bb-79b0-8087-9afad65640d1\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: functional programming\nRegistry id: vr.tr.functional-programming\nPlane / domain: ACT / ACT.ACT\nRegistry definition: (none recorded)\nNames folded into" } } }, "metaModel": { "id": "THING-Q193076", "registryId": "vr.tr.functional-programming", "name": "functional programming", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "ACT.ACT" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q193076/", "model": { "registry_id": "vr.tr.functional-programming", "name": "functional programming", "purpose": "Enable an agent to recognise functional programming practices, assess their semantic and operational constraints, and choose transformations that preserve intended behaviour.", "definition": "Functional programming is a programming paradigm that structures computation through the evaluation and composition of functions, typically emphasizing immutable data, higher-order functions, and explicit control or avoidance of side effects.", "scope_statement": "This model owns functional programming as a programming paradigm and practice, including function composition, explicit data flow, treatment of state and effects, and reasoning about program behaviour; it records the criteria used to distinguish strict and broader interpretations.", "in_scope": [ "Criteria for identifying functional programming in a language, module, or implementation", "Function values, higher-order functions, closures, and composition", "Purity, referential transparency, immutable data, and explicit state transitions", "Evaluation strategy, termination, and resource consequences of functional constructions", "Functional decomposition, testing, and semantics-preserving refactoring" ], "out_of_scope": [ "Complete specifications and implementations of individual programming languages", "General software delivery, project governance, and development lifecycle management", "Lambda calculus and type theory beyond their application to functional programming decisions", "Application-domain requirements and business rules expressed by a program", "General concurrency, distributed systems, and database transaction models" ], "distinguishing_features": [ "Inspect whether functions are passed, returned, and composed to organise computation; merely declaring named functions does not establish a functional design.", "Check whether a computation can be replaced by its result without changing observable behaviour under the stated semantics; distinguish this property from a coding-style label.", "Trace whether state changes are represented as explicit input-output transitions or depend on hidden mutation, and identify any intentionally isolated mutable implementation.", "Determine whether effects have explicit boundaries or representations; functional programming does not require an application to perform no I/O.", "Separate functional organisation from adjacent features: static typing, recursion, laziness, and concise syntax are each insufficient on their own." ], "characteristics": [ { "name": "Classification basis", "kind": "category", "unit_or_values": "strict purity criterion | broader functional practice criterion | mixed paradigm | unresolved", "why_it_matters": "Makes the interpretation behind a functional-programming classification explicit." }, { "name": "Unit of assessment", "kind": "category", "unit_or_values": "expression | function | module | application | language", "why_it_matters": "Prevents language capabilities from being mistaken for properties of every program written in that language." }, { "name": "Function-value support", "kind": "category", "unit_or_values": "native first-class functions | restricted function values | emulated function values", "why_it_matters": "Determines which composition and higher-order designs are directly expressible." }, { "name": "Effect exposure", "kind": "category", "unit_or_values": "implicit effects | documented boundaries | explicit values or interfaces | language-enforced tracking; combinations allowed", "why_it_matters": "Indicates how an agent can discover and constrain observable interactions." }, { "name": "State representation", "kind": "category", "unit_or_values": "immutable values | persistent structures | encapsulated mutation | shared mutable state; combinations allowed", "why_it_matters": "Determines aliasing risks and which state-transition assumptions hold." }, { "name": "Evaluation strategy", "kind": "category", "unit_or_values": "strict | call-by-name | call-by-need | mixed or explicitly deferred", "why_it_matters": "Affects demand, repeated computation, termination, effect timing, and memory retention." }, { "name": "Behavioural equivalence criterion", "kind": "relation", "unit_or_values": "links a proposed transformation to preserved observations, assumptions, and evidence", "why_it_matters": "Makes refactoring claims conditional on the actual language and execution context." } ], "affordances": [ "Classify an implementation against explicit functional-programming criteria and identify mixed-paradigm regions.", "Extract a pure computational core and define interfaces for state, I/O, and other effects.", "Compose transformations through higher-order functions while checking input-output compatibility and execution order.", "Replace hidden state updates with explicit transitions or immutable values where the behavioural contract permits.", "Evaluate refactorings using equations, property tests, and operational measurements appropriate to the implementation." ] }, "sources": [], "structure": { "bundles": [ { "id": "paradigm-boundaries", "name": "Paradigm boundaries", "description": "Records what functional programming means in the assessed context and what evidence supports that classification.", "rationale": "A language label or isolated feature cannot resolve whether an implementation follows functional principles.", "layers": [ { "id": "interpretation-and-unit", "name": "Interpretation and unit", "description": "Separates the adopted definition from the level at which it is applied.", "findings": [ { "id": "functional-classification", "name": "Functional classification", "description": "Record the adopted criterion, its provenance, and whether the assessment concerns a language capability or actual program organisation.", "questions": [ { "text": "Does the adopted definition require purity, emphasise function composition, or admit a mixed style with controlled effects?", "kind": "definition", "id": "functional-classification-q01" }, { "text": "Whose definition is being applied, and what evidence supports applying it to this expression, module, application, or language?", "kind": "provenance", "id": "functional-classification-q02" } ] } ] }, { "id": "neighbouring-paradigms", "name": "Neighbouring paradigms", "description": "Distinguishes functional organisation from procedural decomposition, object-oriented interfaces, and broader declarative programming.", "findings": [ { "id": "discriminating-evidence", "name": "Discriminating evidence", "description": "Record whether computation is organised around composed value transformations and where other paradigms participate.", "questions": [ { "text": "Which concrete parts use composed value transformations, and which rely on commands that update hidden state?", "kind": "boundary", "id": "discriminating-evidence-q01" }, { "text": "Would the functional classification still hold if recursion, static types, or concise expression syntax were removed from the evidence?", "kind": "boundary", "id": "discriminating-evidence-q02" } ] } ] } ] }, { "id": "functions-and-composition", "name": "Functions and composition", "description": "Captures how function values connect computations and carry dependencies.", "rationale": "An agent needs to distinguish composable transformations from superficially similar calls with hidden dependencies.", "layers": [ { "id": "function-values-and-capture", "name": "Function values and capture", "description": "Examines higher-order use and the environment retained by closures.", "findings": [ { "id": "function-dependencies", "name": "Function dependencies", "description": "Record arguments, returned function values, captured bindings, and dependencies reachable through the captured environment.", "questions": [ { "text": "Which functions accept or return functions, and what role does that serve in organising computation?", "kind": "definition", "id": "function-dependencies-q01" }, { "text": "Does a closure capture stable values, mutable references, or external resources that alter its behaviour across calls?", "kind": "boundary", "id": "function-dependencies-q02" } ] } ] }, { "id": "composition-contracts", "name": "Composition contracts", "description": "Describes compatibility and sequencing obligations when transformations are connected.", "findings": [ { "id": "pipeline-compatibility", "name": "Pipeline compatibility", "description": "Record intermediate value contracts, failure representations, and any order-sensitive stages.", "questions": [ { "text": "Do each stage's outputs satisfy the next stage's input requirements, including optional, failing, or deferred results?", "kind": "boundary", "id": "pipeline-compatibility-q01" }, { "text": "Which stages may be regrouped or reused, and what assumptions about effects and evaluation justify doing so?", "kind": "action", "id": "pipeline-compatibility-q02" } ] } ] } ] }, { "id": "purity-state-and-effects", "name": "Purity, state, and effects", "description": "Makes value dependencies, state transitions, and observable interactions explicit.", "rationale": "Reasoning about functional code depends on knowing where substitution is valid and where execution interacts with its environment.", "layers": [ { "id": "referential-transparency", "name": "Referential transparency", "description": "Assesses substitution claims against the actual observation boundary.", "findings": [ { "id": "purity-contract", "name": "Purity contract", "description": "Record the evidence and assumptions behind treating a computation as a value-producing expression without observable effects.", "questions": [ { "text": "Can an expression be replaced by its result without changing the observations admitted by this program's semantics?", "kind": "definition", "id": "purity-contract-q01" }, { "text": "Could hidden inputs, exceptions, nontermination, identity-sensitive operations, or observable mutation invalidate the proposed substitution?", "kind": "boundary", "id": "purity-contract-q02" } ] } ] }, { "id": "state-and-effect-boundaries", "name": "State and effect boundaries", "description": "Examines how evolving state and external interactions enter otherwise composable computations.", "findings": [ { "id": "explicit-transitions-and-execution", "name": "Explicit transitions and execution", "description": "Record immutable state transitions, any encapsulated mutation, and the mechanism that executes represented effects.", "questions": [ { "text": "Where is state passed and returned explicitly, and where can aliases observe mutation?", "kind": "boundary", "id": "explicit-transitions-and-execution-q01" }, { "text": "How are I/O, randomness, time, and failures represented or isolated, and what determines when and in which order they execute?", "kind": "definition", "id": "explicit-transitions-and-execution-q02" } ] } ] } ] }, { "id": "data-and-evaluation", "name": "Data and evaluation", "description": "Connects functional data processing to demand, termination, allocation, and retention.", "rationale": "Equivalent-looking value transformations can have different operational consequences under different evaluation and data representations.", "layers": [ { "id": "immutable-data-processing", "name": "Immutable data processing", "description": "Records how values are constructed, traversed, shared, and retained.", "findings": [ { "id": "updates-and-traversals", "name": "Updates and traversals", "description": "Assess mapping, filtering, folding, and value updates using the actual data structure rather than assuming immutability determines their cost.", "questions": [ { "text": "Do updates copy whole structures, share unchanged parts, or use mutation hidden behind an immutable interface?", "kind": "definition", "id": "updates-and-traversals-q01" }, { "text": "For representative inputs, what allocation, traversal, and retained-memory costs arise from the chosen transformations?", "kind": "measurement", "id": "updates-and-traversals-q02" } ] } ] }, { "id": "demand-and-termination", "name": "Demand and termination", "description": "Examines when expressions run and how recursive or deferred computations progress.", "findings": [ { "id": "evaluation-obligations", "name": "Evaluation obligations", "description": "Record evaluation strategy, forcing points, termination assumptions, and stack behaviour relevant to a proposed change.", "questions": [ { "text": "Which values are evaluated immediately, recomputed on demand, or shared after evaluation, and what forces deferred work?", "kind": "definition", "id": "evaluation-obligations-q01" }, { "text": "Before replacing a loop, fold, or recursive definition, what evidence establishes termination or productivity and acceptable stack and memory use?", "kind": "action", "id": "evaluation-obligations-q02" } ] } ] } ] }, { "id": "reasoning-and-transformation", "name": "Reasoning and transformation", "description": "Defines how functional properties support validation and changes to executable code.", "rationale": "Functional abstractions are useful to an agent only when their laws and operational limits support concrete decisions.", "layers": [ { "id": "laws-and-properties", "name": "Laws and properties", "description": "Records the equations and invariants a specific implementation is expected to satisfy.", "findings": [ { "id": "lawful-behaviour", "name": "Lawful behaviour", "description": "Associate proposed algebraic laws with their domain, preconditions, and verification evidence.", "questions": [ { "text": "Which composition, mapping, folding, or state-transition laws are claimed, and for which inputs and observations?", "kind": "definition", "id": "lawful-behaviour-q01" }, { "text": "What proofs, property tests, or counterexamples support those laws, including failure cases and numeric edge cases?", "kind": "provenance", "id": "lawful-behaviour-q02" } ] } ] }, { "id": "safe-refactoring", "name": "Safe refactoring", "description": "Evaluates opportunities such as fusion, memoisation, and parallel evaluation against explicit preconditions.", "findings": [ { "id": "transformation-permission", "name": "Transformation permission", "description": "Record what a transformation must preserve and what semantic and resource evidence permits it.", "questions": [ { "text": "Before fusion, memoisation, or parallel evaluation, which assumptions about purity, ordering, termination, equality, and shared state must be checked?", "kind": "action", "id": "transformation-permission-q01" }, { "text": "Which observable behaviours and resource limits must remain acceptable, and how will the changed implementation be compared with the original?", "kind": "measurement", "id": "transformation-permission-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": [ "There is no universally accepted boundary for functional programming; definitions differ over whether purity is required or merely encouraged.", "Pure versus impure and strict versus lazy are separate classification axes, not mutually exclusive varieties.", "This description is recalled knowledge, not source-verified research; language-specific guarantees and performance behavior require checking against the relevant implementation." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of functional programming 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": [ "Pure functional programming", "Functional programming with unrestricted side effects", "Strict functional programming", "Lazy functional programming" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of functional programming 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": [ "Data transformation pipelines using operations such as map, filter, and fold", "Compilers and interpreters that transform symbolic representations", "Concurrent systems that reduce shared mutable state", "Business logic expressed as pure functions with separately managed input and output", "Property-based testing and equational reasoning about program behavior" ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of functional programming 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": [ "Uncontrolled allocation and copying can increase memory use and garbage-collection overhead.", "Lazy evaluation can retain unevaluated computations and cause unexpected memory growth.", "Deep recursion can exhaust the call stack where suitable optimization or execution support is absent.", "Hidden side effects or mutable dependencies can invalidate reasoning that assumes pure functions.", "Function composition and abstractions can obscure execution costs and complicate debugging." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of functional programming 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": "Declarative programming", "difference": "Declarative programming is a broader category; functional programming specifically organizes computation around functions, whereas declarative approaches also include logic and constraint programming." }, { "name": "Imperative programming", "difference": "Imperative programming principally describes sequences of commands that change state; functional programming principally describes computations through expressions and function application." }, { "name": "Object-oriented programming", "difference": "Object-oriented programming principally organizes behavior around objects and their interfaces; functional programming principally organizes behavior around functions and their composition, although a program can combine both." }, { "name": "Lambda calculus", "difference": "Lambda calculus is a formal system for abstraction and application; functional programming is a programming paradigm informed by that system." }, { "name": "Pure function", "difference": "Purity is a property of an individual function whose result depends only on its inputs and whose evaluation has no observable side effects; functional programming is a broader paradigm that does not universally require every function to be pure." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of functional programming this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Which reference definitions should anchor the registry entry, and how should disagreements between purity-centred and broader practice-centred accounts be represented?", "Does an existing Vercy world model already own functional programming or part of this scope, requiring a link or narrower ownership?", "What evidence threshold should distinguish a functional module from a mixed-paradigm module without imposing an arbitrary feature count?", "Which observation boundary should purity and equivalence assessments use for exceptions, nontermination, identity, and encapsulated mutation?", "Which language-specific evaluation and runtime guarantees require linked models before an agent can authorise refactoring or optimisation?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 15, "questions": 25 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "abstract concept", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a functional programming, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an agent to recognise functional programming practices, assess their semantic and operational constraints, and choose transformations that preserve intended behaviour.", "characteristics": { "substance": "activity", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "observed and measured" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: purely functional programming, functional logic programming, functional reactive programming, total functional programming.", "4 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 58 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 functional programming, and on what evidence are they told apart?" ], "whatItIsMadeOf": "something that happens over time", "physicalCharacter": [ "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "observe it, measure it, record its state" ], "howItIsRecognised": [ "Nothing to see. What is recognised is an instance of it, and which instances count is exactly what is argued about." ], "relatedModels": [ { "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": [ "purely functional programming", "functional logic programming", "functional reactive programming", "total functional programming" ] } ], "standing": "Described in 58 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 4 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 functional programming from another, and a functional programming 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 functional programming, 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 functional programming, 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 functional programming 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 functional programming, 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 functional programming, 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 functional programming 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 functional programming 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 functional programming, 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 functional programming, 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 functional programming 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 functional programming from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a functional programming, 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 functional programming, 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 functional programming 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 functional programming 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 functional programming between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a functional programming, 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 functional programming, 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 functional programming 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 functional programming, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a functional programming 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 functional programming, 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 functional programming, 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 functional programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "process-and-outcome", "name": "Process, inputs and outcome", "description": "How a functional programming proceeds, what it needs and what it leaves behind.", "rationale": "An activity is known by its steps and its results, and both have to be recordable while it is still running.", "layers": [ { "id": "steps-and-sequence", "name": "Steps and sequence", "description": "The steps of a functional programming, their order and what may run in parallel.", "findings": [ { "id": "steps-and-preconditions", "name": "Steps, preconditions and completion", "description": "What has to be true before each step of a functional programming and what marks it done.", "questions": [ { "id": "steps-and-preconditions-q01", "text": "What identifies and describes a step of a functional programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "steps-and-preconditions-q02", "text": "Who or what asserted this about a step of a functional programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "steps-and-preconditions-q03", "text": "What may an agent decide or do once a step of a functional programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "inputs-and-results", "name": "Inputs, resources and results", "description": "What a functional programming consumes and what it produces.", "findings": [ { "id": "inputs-and-outputs", "name": "Inputs, outputs and side effects", "description": "The resources a functional programming takes and the results it leaves, wanted or not.", "questions": [ { "id": "inputs-and-outputs-q01", "text": "What identifies and describes the inputs and results of a functional programming, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "inputs-and-outputs-q02", "text": "Who or what asserted this about the inputs and results of a functional programming, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "inputs-and-outputs-q03", "text": "What may an agent decide or do once the inputs and results of a functional programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "definitions-in-contest", "name": "Definitions and who holds them", "description": "What functional programming is taken to mean, and by whom.", "rationale": "When a field disagrees about a concept, the disagreement is the content. A model that picks one definition silently destroys the information.", "layers": [ { "id": "competing-definitions", "name": "Competing definitions", "description": "The main readings and the traditions behind them.", "findings": [ { "id": "definition-map", "name": "Definitions and their holders", "description": "Each definition with the school or body that holds it.", "questions": [ { "id": "definition-map-q01", "text": "Which definitions of functional programming are in use, and which tradition or body holds each?", "kind": "definition" }, { "id": "definition-map-q02", "text": "What turns on the difference between them in practice?", "kind": "boundary" } ] } ] }, { "id": "operationalisation", "name": "Operationalisation", "description": "How it is measured or applied when it has to be.", "findings": [ { "id": "operational-record", "name": "Measures and proxies", "description": "Instruments and indicators used to stand in for it.", "questions": [ { "id": "operational-record-q01", "text": "How is functional programming operationalised or measured in practice, and by what instrument?", "kind": "measurement" }, { "id": "operational-record-q02", "text": "What does that operationalisation leave out, and when does that matter?", "kind": "boundary" } ] } ] } ] }, { "id": "instances-and-use", "name": "Instances, use and consequence", "description": "What counts as an instance of functional programming and what follows from calling something that.", "rationale": "Applying a concept is an act with consequences, so a model must say what the label licenses and what it does not.", "layers": [ { "id": "instances", "name": "What counts as an instance", "description": "Clear cases, borderline cases and non-cases.", "findings": [ { "id": "instance-tests", "name": "Tests for an instance", "description": "What would settle whether something falls under it.", "questions": [ { "id": "instance-tests-q01", "text": "What would settle whether something is an instance of functional programming?", "kind": "boundary" }, { "id": "instance-tests-q02", "text": "Which borderline cases are argued about, and on what grounds?", "kind": "definition" } ] } ] }, { "id": "consequence", "name": "Consequence of application", "description": "Rights, duties or decisions that follow from the label.", "findings": [ { "id": "consequence-record", "name": "What the label licenses", "description": "What an agent may do once something is classified this way.", "questions": [ { "id": "consequence-record-q01", "text": "What follows practically once something is treated as functional programming?", "kind": "action" }, { "id": "consequence-record-q02", "text": "What must an agent not infer from the label alone?", "kind": "action" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a functional programming 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 functional programming and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a functional programming, 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 functional programming, 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 functional programming 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 functional programming is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a functional programming, 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 functional programming, 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 functional programming is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 12, "findings": 14, "questions": 38 } } } }