A formal or learned representation used for prediction, decision, or simulation; spans statistical models, ML models, financial models, and mental models.
On the ward, a model is the score or alert that appears in the EHR — a sepsis risk number, a deterioration index, a no-show probability — produced by logic the clinician did not build and usually cannot see. Clinicians operationalize it through its behavior in use: which patients it fires on, how often it is wrong, whether it changes what they would have done anyway. The working question is not what the model is mathematically but how much weight its output deserves next to examination findings, history, and clinical judgment for this patient.
Interpret a model's score or alert as one input alongside clinical findings, recognize situations where it is unreliable, and document when and why you override it.
e.g., a ward nurse receiving a sepsis alert on a post-surgical patient must judge whether it reflects infection or the model misreading routine post-operative inflammation markers.
Clinical communities differ on whether model outputs are advisory information a clinician may freely discount or default recommendations requiring documented justification to override; hospitals encode different answers in their EHR workflows.
OmniGloss seed synthesis, 2026 (machine-drafted, pending expert validation)
For hospital executives and clinical governance committees, a model is a potential medical device: regulatory status settles what it is. Whether the predictive component qualifies as software as a medical device under FDA or MDR rules determines who may authorize deployment, what evidence of clinical validity must exist first, and who carries liability when it errs. Deciding to switch on a vendor's risk model is operationally an act of accepting clinical risk on behalf of patients, so the model is treated as an intervention requiring the same authorization discipline as a new device purchase or drug protocol.
Determine a model's regulatory classification, require documented evidence of clinical validity for your own patient population, and formally accept or reject deployment risk before authorizing clinical use.
IDx-DR's 2018 FDA authorization as an autonomous diagnostic for diabetic retinopathy made explicit that the model, not the clinician, was the regulated decision-maker — changing what hospital sign-off had to cover.
Where the device boundary falls for predictive tools embedded in EHRs is live: many deployed sepsis and deterioration models operate outside FDA clearance under the non-device clinical-decision-support carve-out, while some governance committees demand device-grade evidence regardless of regulatory status — institutions and regulators draw the line differently.
FDA, Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) Action Plan, 2021
SaMD framing; total product lifecycle approach
In clinical ML development, the model is a trained function — features in, prediction out — whose identity is fixed by its learned parameters and version, and whose adequacy is established empirically: discrimination, calibration, and decision-relevant metrics on data from the intended care setting, ideally external to development. Builders in this school do not require the model to encode a defensible causal account of disease; a gradient-boosted mortality predictor is acceptable if it is validated, monitored, and locked or updated under an explicit change protocol. Fitness is what the evaluation shows on the target population, not what the mathematical form claims about physiology.
Specify the model as a versioned trained artifact, validate discrimination and calibration on the intended patient population, and define a locked-versus-update protocol before clinical deployment.
The Epic Sepsis Model's proprietary penalized-regression predictor showed an external-validation AUC of 0.63 versus reported 0.76-0.83 (Wong et al. 2021), showing why this community treats external validation, not model form, as the acceptance test.
Anchors the model-as-predictive-instrument position in the documented adequacy dissensus; official-statistics and regulated quantitative-modeling communities require defensible assumptions about the data-generating process, not performance alone.
NIST AI 100-3, The Language of Trustworthy AI: An In-Depth Glossary of Terms (entry 'model', attributed to AI Fairness 360)
glossary entry 'model' (function from features to predicted labels)
G. Shmueli (2010). To Explain or To Predict. Statistical Science
For clinical AI governance and quality-assurance staff, a model is an inventory item with a lifecycle: an entry in the organization's model register carrying owner, intended use, version, training-data summary, validation evidence, deployment sites, and monitoring thresholds. Stewardship operationalizes the concept through the artifacts that surround it — model cards, update logs, drift dashboards, incident reports — because in a hospital the same predictive core may run in dozens of workflows. A model that is not registered, monitored for performance drift across patient subgroups, and assigned a responsible owner is treated as an unmanaged clinical risk, whatever its published accuracy.
Maintain a model inventory with owners, versions, and intended uses; schedule recurring subgroup performance monitoring; and trigger review when drift or incident thresholds are crossed.
e.g., a health system discovers during audit that a readmission model retrained by its vendor two years earlier is still being scored against the original validation report, prompting a registry-wide revalidation requirement.
Mitchell et al., 'Model Cards for Model Reporting', FAT* 2019
For credit officers, underwriters, and front-line analysts, the model is the score, limit, or price the system hands them, together with the reason codes attached to it. It is operationalized through use rules: cutoffs that determine automatic approval or referral, the conditions under which an officer may override, and the documentation an override requires. What matters day to day is knowing which decisions are the model's, which are theirs, and what the adverse-action reasons attached to a declined applicant actually mean — because the officer, not the model, faces the customer and signs the file.
Apply model-driven scores within approved cutoffs, exercise and document overrides under the institution's override policy, and translate reason codes accurately when communicating decisions to customers.
e.g., a small-business application referred to manual review because its score falls in a grey zone requires the officer to combine the score with bank-statement evidence and record why the final decision departs from the model recommendation.
For bank executives and model owners, a model is a booked risk position: supervisory guidance makes senior management accountable for model risk as for credit or market risk. Owning a model means accepting documented responsibility for its use — approving its purpose, its limitations, and the compensating controls — and answering to the board and supervisors when it fails. Decisions to use, extend, or retire a model are risk-acceptance decisions taken against validation findings and materiality tiering, and use of a model outside its approved scope is a governance breach even if the numbers happen to be right.
Formally accept ownership of each model you rely on, authorize its use only within validated scope and materiality tier, and act on validation findings before results drive decisions.
JPMorgan's 2012 'London Whale' losses were amplified by an approved VaR model change implemented through error-prone spreadsheets — a model-ownership failure documented in the bank's 2013 task force report, not merely a trading mistake.
Board of Governors of the Federal Reserve System / OCC, Supervisory Guidance on Model Risk Management (SR 11-7), 2011
Simona Cosma et al. (2023). Knowledge mapping of model risk in banking. International Review of Financial Analysis
For quantitative developers in banking, the term is pinned by supervisory definition: a quantitative method, system, or approach applying statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. Practically, a model has three components — inputs, processing, and reporting — each of which can fail independently, and building one means documenting theory, assumptions, data lineage, and limitations to a standard an independent validator can test. The definition deliberately includes judgment-based inputs so long as output is quantitative, which is why quants document expert overlays as model components rather than as exceptions.
Develop models with documented theory, assumptions, and component structure — inputs, processing, reporting — so that an independent validation function can effectively challenge every element.
e.g., a probability-of-default model whose macroeconomic overlay is set quarterly by an expert committee must document that overlay as a model component with its own assumptions, not as an informal adjustment.
For model-risk validators and internal audit, the operative question about any analytical tool is whether it meets the supervisory definition of a model, because that classification pulls it into the inventory, assigns a validation tier, and triggers effective-challenge requirements. Validation practice deliberately draws the boundary wide: scorecards, spreadsheet-based estimators, vendor black boxes, and judgment-fed calculators all count when they turn inputs into quantitative estimates that decisions rely on. An analytical tool kept off the inventory is, in this practice, an unmanaged risk — the steward's first task is finding models that their builders never called models.
Assess candidate tools against the institution's model definition, maintain the complete model inventory with risk tiers, and subject each entry to independent validation proportionate to materiality.
e.g., an internal audit finding that a desk's Excel-based provisioning calculator constitutes an unregistered model requiring retroactive validation — a routine outcome of applying the SR 11-7 boundary during inventory attestation.
Anchors the wide-governance-boundary position in the documented dissensus over what counts as a model; engineering communities restrict the term to trained learned artifacts and resist inventorying rules and spreadsheets as models.
definition and scope of 'model'; validation
In studio and newsroom practice, a model is a creative instrument with a recognizable disposition: writers, designers, and editors speak of what a given model is good at, what its default voice sounds like, and which prompts coax usable material from it. It is operationalized through craft knowledge — model choice per task, iteration until output meets the brief, and judgment about what may leave the building — rather than through parameters or benchmarks. The practical boundary that matters is between material a model drafted and material a human authored, because that line drives credit, disclosure, and editorial responsibility.
Select and steer models per creative task, evaluate outputs against the brief and house standards, and flag machine-drafted material for the disclosure and credit rules that apply.
e.g., a games writer uses a language model to generate ambient dialogue variants, then rewrites accepted lines by hand so that credited dialogue meets the studio's authorship standard.
For publishers, editors-in-chief, and commissioning executives, a model is a legal-exposure object attached to every piece of content it touched: adopting one raises the questions of what it was trained on, what licence covers its outputs, and what disclosure the audience and the law require. Decision practice operationalizes 'model' through contract and policy — indemnities from the provider, permitted-use clauses for staff, labeling rules for synthetic content — because outputs that resemble existing works or persons can trigger copyright and deep-fake liabilities that land on the publisher, not on the model vendor.
Authorize model use only under policies covering training-data licensing, output rights, indemnification, and audience disclosure, and verify synthetic-content labeling obligations before publication.
Getty Images' litigation against Stability AI over training on its photo library made the training corpus a due-diligence question publishers now put to any model vendor before adoption.
Art. 50 (transparency obligations for synthetic content and deep fakes)
For ML engineers and technical artists in media and games pipelines, a model is a concrete versioned artifact: a checkpoint file of learned weights, with an architecture, a training run, a licence, and a hash. It is what you fine-tune, quantize, ship, or roll back — categorically distinct from the prompts, samplers, guardrails, and asset pipelines wrapped around it. When production behavior changes, the first diagnostic question is whether the model changed or the surrounding system did, so builders enforce the boundary strictly: only the trained parameter artifact is the model; everything else is configuration or code.
Version model checkpoints with training-run metadata and licences, track which weights each product build ships, and distinguish model changes from pipeline changes when diagnosing behavior.
e.g., a studio pins a specific open-weights image-generation checkpoint for an art tool and treats a LoRA fine-tune as a new model requiring fresh licence review before it enters production.
Anchors the trained-artifact position in the documented boundary dissensus; governance and register communities count rule-based and spreadsheet tools as models, which pipeline engineers reject as diluting the term.
NIST AI 100-3, The Language of Trustworthy AI: An In-Depth Glossary of Terms (entry 'model', attributed to EU-U.S. TTC Joint Roadmap taxonomy)
glossary entry 'model' (model as core component of an AI system)
For rights-management and standards stewards in the creative sector, a model is a derivative repository of the works it was trained on: its weights are assessed as the residue of a training corpus whose provenance must be accounted for. Stewardship operationalizes the concept through documentation duties — sufficiently detailed summaries of training content, respect for machine-readable rights reservations under the EU text-and-data-mining regime, and audit trails linking model versions to corpus snapshots. A model whose training provenance cannot be documented is treated as carrying unquantified rights liability, regardless of output quality.
Demand documented training-corpus provenance for each model version, verify compliance with rights reservations and disclosure duties, and assess outputs' substantial-similarity risk to catalogued works.
Under the AI Act, general-purpose model providers must publish a sufficiently detailed summary of training content — turning what was an engineering detail into an auditable rights document.
Art. 53(1)(d) (training-content summary for general-purpose AI models)
In case-handling practice, a model is the risk flag or priority score that lands in a caseworker's queue — an output of central analytics that colors the file before the citizen is ever seen. Caseworkers operationalize it through procedural questions: does the score merely order the workload or does it change the applicable scrutiny; what must be recorded when acting on or against it; and how to keep individualized assessment real when the screen already suggests an answer. The model matters as an influence on discretion that administrative law says must remain the official's own.
Treat model scores as case-prioritization inputs, conduct and record the individualized assessment the law requires, and escalate when a flag cannot be reconciled with the file's facts.
In the Dutch childcare-benefits affair, risk-scored parents faced fraud presumptions that caseworkers operationalized as heightened scrutiny — later found by parliamentary inquiry to have displaced individualized assessment with devastating effect.
For agency heads and programme directors, adopting a model is making policy by other means: its thresholds, features, and weightings fix how a legal standard will be applied to thousands of cases, so the adoption decision is treated as a question of delegable authority. What must be settled before go-live is whether the statute permits automating this judgment, who signs as accountable when courts ask for reasons, and whether the model's operation can be explained in proceedings. A model whose logic cannot be defended before a judge or a parliamentary committee is, for this community, unusable however accurate.
Verify legal authority for model-supported decisions, assign named accountability for outcomes, and require that the model's decision logic can be explained in court and to oversight bodies.
The Hague District Court's 2020 SyRI ruling struck down a welfare-fraud risk-model regime as violating Article 8 ECHR, confirming that deploying an opaque model can itself be an unlawful administrative act.
In official-statistics production, a model is an explicit, published representation of a data-generating process: a small-area estimator, a seasonal-adjustment specification, an imputation model, each with stated assumptions that must be scientifically defensible and open to scrutiny under statistical codes of practice. Builders in this tradition judge a model by whether its assumptions can be stated, tested, and defended — sound methodology precedes predictive convenience — because published figures must survive methodological challenge years later. A model that fits well but rests on assumptions the institute cannot justify is not publishable, however strong its holdout performance.
Specify model assumptions explicitly, test them against the data and document departures, and publish methodology so external experts can reproduce and challenge the estimates.
e.g., a national statistical institute publishing model-based small-area unemployment estimates documents the underlying area-level model and its assumptions in a methodology report open to peer scrutiny.
Anchors the model-as-representation position in the documented adequacy dissensus; clinical and industrial machine-learning communities accept models justified by out-of-sample performance alone.
European Statistics Code of Practice, Eurostat, 2017 revision
For algorithm-register maintainers and transparency stewards in government, a model is any automated logic that materially shapes decisions about citizens — learned or hand-coded — and the operative task is getting it registered. Register practice defines the concept by decision influence rather than by technique: a machine-learning classifier, a points-based eligibility formula, and a hard-coded prioritization rule all belong in the public register with purpose, legal basis, and contact point, because citizens' rights to know do not depend on whether parameters were fitted or written. What escapes the register escapes scrutiny; that is the failure mode this community polices.
Register every decision-shaping automated logic with purpose, legal basis, and responsible unit; audit departments for unregistered systems; and keep register entries current across versions.
The Dutch national Algorithm Register, launched in 2022, lists impactful government algorithms by decision impact, including rule-based systems alongside machine-learning models.
Anchors the wide-governance-boundary position in the documented dissensus over what counts as a model; engineering communities restrict the term to trained learned artifacts and would exclude hand-coded rules.
For machine-learning engineers inside financial institutions, a model is the trained artifact produced by a training pipeline — an object with weights, hyperparameters, feature schema, and a registry entry — not the business rule, policy overlay, or spreadsheet that consumes its score. This school operationalizes the concept through MLOps practice: a model exists when a training run is logged, is promoted through environments as an immutable versioned object, and is retired by registry state change. Deterministic cutoffs and expert adjustments are 'strategy', governed as code and policy; calling them models, on this view, dilutes the monitoring and retraining discipline built for learned artifacts.
Register each trained artifact with lineage from data to training run, promote only immutable versioned models to production, and keep decision rules governed separately as strategy code.
e.g., a fraud-detection team logs every retrained gradient-boosting artifact in its model registry, while the score threshold that blocks transactions is versioned separately as a policy parameter owned by the fraud-strategy unit.
Anchors the trained-artifact position in the documented boundary dissensus; the institution's own validation function applies the wider supervisory definition to the same tools, producing recurring inventory disputes.
Danylo O. Hanchuk et al. (2025). Implementing MLOps practices for effective machine learning model deployment: A meta synthesis. Unknown Journal
Among many working creatives, a model is understood first as an aggregation of other people's labor: a system whose fluent output exists because bodies of illustration, prose, photography, and performance were ingested, mostly without consent, credit, or payment. On this reading, engaging with a model is engaging with the market position of everyone whose work it absorbed — so the operational questions are whose styles it can imitate, whether its training was licensed, and what using it does to the rates and livelihoods of the people it learned from. Competence includes knowing when refusing a model is the professionally defensible act.
Assess a model's training provenance and licensing posture before use, weigh its impact on the creators it learned from, and invoke collective agreements governing AI use where they apply.
The 2023 WGA and SAG-AFTRA agreements won contractual limits on training and use of models involving writers' scripts and performers' likenesses, codifying this reading of models as appropriated labor.
Creative end-users split between treating models as legitimate instruments once outputs are substantially reworked and treating any use of unlicensed-corpus models as complicity; professional bodies and individual practitioners draw different lines.
In patient-safety work on clinical decision support, the model that governs care is the one in the clinician's head: every user of a risk score forms a mental model of what the tool measures and when it fails, and harm concentrates where that mental model diverges from the statistical one — typically on understaffed shifts where automation bias is strongest, and for patients unlike the development population, who are often already the least served. Clinicians operationalize the concept by calibrating their own reliance: knowing the score predicts billing-coded sepsis rather than bedside sepsis, refusing to let a low score rule out concern in groups the model was never validated for, and teaching juniors what the number does not see.
Articulate what the model actually predicts and for whom it was validated, monitor your own reliance for automation bias, and correct trainees' misreadings of model scores.
e.g., a resident treats a low early-warning score as ruling out deterioration in a patient population the model was never validated for, illustrating the mental-model gap this operationalization targets.
Art. 14(4)(b) (automation-bias awareness in human oversight)
For newsroom and studio engineering teams that consume hosted models, a model is a service dependency: an API endpoint with a version string, a rate limit, terms of service, and a deprecation calendar, whose weights they will never see. Building with it means engineering around someone else's artifact — pinning versions where the provider allows, regression-testing prompts on every upstream model update, logging model identifiers with every published output for later accountability, and maintaining fallbacks for endpoint retirement. The operative properties of a model here are contractual and operational — availability, versioning discipline, data-handling terms — rather than architectural.
Pin and log the exact hosted model version behind every output, regression-test integrations on provider updates, and maintain contractual and technical fallbacks for model deprecation.
e.g., a newsroom's summarization pipeline silently changes tone after a provider's model update, traceable only because the team logged model version identifiers with each generated draft.
Within creative-sector engineering, teams running open weights operationalize a model as an inspectable local artifact while API-consuming teams operationalize it as a contractual service; the two produce different testing and accountability practices.
For supreme audit institutions, ombudsmen, and courts reviewing administrative decisions, a model is the operative decision rule of the administration in executable form, and the audit question is whether that rule can be reconstructed and tested against the legal standard it implements. Review practice operationalizes the concept through reconstructability: obtain the specification, the factors and weights, the data flows; determine whether like cases were treated alike; and establish whether affected persons could learn the grounds of decisions. A model whose reasoning cannot be reproduced for review defeats the duty to give reasons and is itself a finding.
Obtain and reconstruct the model's decision logic, test whether it applies the legal standard consistently across cases, and report irreproducible decision-making as an accountability failure.
In the UK's 2020 Ofqual grading controversy, review bodies dissected the awarding model's steps — small-cohort exceptions, historical school-performance weighting — because grades were administrative decisions requiring defensible grounds.
In agri-environmental practice, a model is a specified transformation from weather, soil, and sensor inputs to agronomic or ecological outputs: process-based crop-growth simulators, machine-learned crop-type classifiers on satellite time series, nitrate-leaching and hydrological models used in regulation. What counts is a stated validity domain — the regions, soil types, seasons, and varieties for which it was calibrated — documented forcing data, and known behaviour outside that domain, because models are routinely pushed across regions and into extreme seasons they were never calibrated for.
State a model's validity domain — regions, soils, seasons, varieties — check every application against it, and recalibrate or refuse use when conditions fall outside the calibrated range.
e.g., a nitrate-leaching model calibrated on sandy northern soils is applied to karst terrain in a fertilizer regulation; its validity-domain statement is what makes the misapplication visible and contestable.
NIST AI 100-3, The Language of Trustworthy AI: An In-Depth Glossary of Terms
model entry (EU-U.S. TTC taxonomy): input-to-output transformation performing a core computational task
For defense engineering and operations-research staff, a model is the computational core that turns inputs into mission-relevant outputs: a physics-based simulation of sensor performance, an attrition model in a wargame, or a learned classifier inside an automatic target recognition chain. Doctrine inherited from modeling-and-simulation practice insists that a model is only meaningful together with its stated domain of validity, that is, the scenarios, environments, and threat behaviors for which it has been verified, validated, and accredited. Outside that envelope its outputs are treated as unaccredited conjecture, whatever their apparent precision.
State a model's accredited domain of validity alongside its outputs, and refuse to carry results from simulation or classifier into planning outside that envelope.
E.g., an attrition model accredited for open-terrain force-on-force engagements is not used to predict outcomes of urban operations without fresh validation, however convenient its numbers.
entry: model (EU-U.S. TTC Joint Roadmap Taxonomy)
In educational measurement and learning analytics, a model is a formal machine for turning learner evidence into estimates and predictions: item-response models that place students and test items on a common ability scale, growth models that estimate progress, and machine-learned classifiers that predict dropout or mastery from clickstream and assessment data. Practitioners operationalize a model by its inputs, its fitted parameters, and the inferences it licenses — and by the standing reminder that it estimates a latent construct like 'ability' or 'engagement' that no gradebook directly contains, so the choice of model quietly decides what counts as learning.
Specify what learner evidence a model consumes and what construct it claims to estimate, check model fit before trusting scores, and state the inferences the model does not license.
e.g., an item-response-theory model behind an adaptive placement test: two students with different answer patterns receive the same estimated ability, and the placement decision inherits the model's assumptions.
NIST AI 100-3, The Language of Trustworthy AI glossary (term snippets extract)
model — input-to-output transformation performing a core computational task (EU-U.S. TTC taxonomy extract)
In engineering practice, a model is a representation you interrogate instead of the physical thing: a CAD geometry, a finite-element mesh, a control-loop transfer function, a discrete-event simulation of the line, or, increasingly, a network trained on process data. The physics traditions expect a model to carry stated assumptions, boundary conditions, and a validation report against physical test; a learned model arrives instead with training-set lineage and held-out metrics. Digital-twin programs force the two cultures into one artifact, and what counts as a 'validated model' depends on which tradition signs the release.
State any model's assumptions, valid operating envelope, and acceptance evidence — physical-test correlation or held-out performance — before its outputs are used for design release or process decisions.
e.g., a thermal FEA model of a battery pack is trusted only after correlation against rig tests, while the plant's ML scrap predictor ships on cross-validation alone — two release standards under one word.
What varies is the acceptance basis: simulation engineers require correlation against instrumented physical tests with documented assumptions, while data-science teams accept held-out-set performance; digital-twin projects expose the gap when one artifact needs both sign-offs.
In litigation-technology and expert practice, a model is a formal input-to-output procedure whose conclusions must survive adversarial scrutiny: a TAR classifier ranking documents for responsiveness, a regression underlying a damages opinion, a scoring tool an agency applied to the client. Counsel operationalize it through the properties an opponent will attack — training inputs, assumptions, known error rate, validation method — the same factors courts weigh for expert methodology under Daubert and FRE 702. A model whose error rate and validation cannot be stated is treated as an inadmissibility and sanctions risk, whatever its benchmark performance elsewhere.
Before relying on a model's output in a proceeding, obtain and record its assumptions, training inputs, error rates, and validation evidence, and prepare to defend each under cross-examination.
In Da Silva Moore v. Publicis Groupe (S.D.N.Y. 2012), the court approved predictive coding for document review on condition of a transparent protocol — accepting the model as methodology precisely because its process and validation were disclosed.
For transport data teams, a model is any fitted input-to-output component producing operational predictions: arrival times from telematics and traffic features, demand by lane and day, dwell time at a dock, no-show probability for a booking. In daily use the word stretches to cover the route-optimization solver and its cost parameters, although that is a specified procedure rather than a learned function. Which artifact the word names matters when accuracy is disputed, because a bad ETA can come from the predictor, the solver's assumptions, or stale input feeds.
Identify which component, learned predictor, optimization solver, or business rule, produced a given output before debugging accuracy, assigning ownership, or promising performance to a customer.
e.g., a carrier blaming the ETA model for missed delivery windows when the predictor was accurate and the error came from the solver's fixed fifteen-minute stop-time assumption.
Data-science teams reserve 'model' for learned predictors, while operations-research planners and dispatchers apply it to optimization solvers and rule sets as well; the disagreement surfaces when accountability for a bad output must be assigned.
model (EU-U.S. TTC Joint Roadmap Taxonomy): component characterizing an input-to-output transformation to perform a core computational task
For the engineers and operations teams behind hospitality and gig platforms, a model is the fitted machinery that turns operational exhaust into decisions: a demand forecaster that sets Friday-night staffing, a surge-pricing function, a dispatch scorer matching couriers to orders, a churn model flagging hosts likely to leave, a fraud model flagging suspicious reviews. Each maps input features — location, time, ratings history, acceptance rate — to a score or prediction, and each quietly encodes assumptions about what a good worker, guest, or booking looks like.
Specify what each production model predicts, which worker and guest features it consumes, and how its scores feed scheduling, pricing, and deactivation decisions.
Uber's surge pricing multiplies fares when predicted demand outstrips available drivers — a forecasting-and-pricing model whose output reallocates both work and cost within minutes.
For marketing data science, a model is any fitted mapping used to spend or allocate money: propensity and churn scorers, customer-lifetime-value predictors, uplift models deciding who gets the discount, marketing-mix regressions carving credit across channels, and the bid-optimization learners inside ad platforms. What counts is the artifact's decision role — it moves budget or selects customers — together with the retraining cadence and holdout performance that keep it defensible. The term stretches from a nightly-retrained gradient-boosted scorer to a quarterly econometric mix model, and routinely includes platform-side black boxes marketers can neither inspect nor retrain.
Inventory every scoring and allocation model that touches budget or customer treatment, record its owner, inputs, retraining cadence, and holdout metrics, and flag platform-side models you cannot inspect.
e.g., a grocery chain's uplift model assigns coupons only to customers whose purchase probability the discount actually changes, replacing a propensity scorer that rewarded already-loyal shoppers.
glossary: model (EU-U.S. TTC taxonomy: component making inferences from inputs to produce outputs)
In research, a model is an explicit representation of a data-generating process or a target function, stated precisely enough that its assumptions can be attacked. Which commitments count varies by tradition: a statistical model is specified by its likelihood, error structure, and identification assumptions and is judged on whether those assumptions are defensible; a machine-learned model is a fitted input-to-output map judged mainly on out-of-sample performance; a simulation model is judged on whether its mechanisms reproduce known behaviour. Researchers therefore ask what a model is for, whether estimation, prediction, or explanation, before asking whether it is any good.
State a model's assumptions, purpose, and the evidence that would falsify it, and judge its fit against that purpose rather than importing a metric from another modelling tradition.
e.g., a random forest with excellent held-out AUC that cannot answer the paper's question about a policy's effect, because nothing in its fitting procedure identifies a causal quantity.
Statistical and machine-learning traditions draw the concept's boundary differently, as an assumption-driven representation of a data-generating process versus a fitted predictive function. 'Is the model good?' therefore means assumption defensibility to one group and held-out performance to the other.
NIST AI 100-3, The Language of Trustworthy AI: An In-Depth Glossary of Terms, entry 'model' (attributing the EU-U.S. TTC Joint Roadmap taxonomy)
entry: model (input-to-output transformation performing a core computational task of an AI system)
Adel Daoud et al. (2020). Statistical modeling: the three cultures. ArXiv
In MLOps practice, a model is a versioned, deployable artifact: learned parameters plus the code, configuration, and feature processing needed to reproduce its input-to-output transformation. It lives in a registry with lineage to its training data and evaluation results, moves through staging gates like any other release, and is monitored as a service once deployed. Builders keep model distinct from system - the model is one component behind an endpoint, wrapped in guardrails, retrieval, and business logic - a distinction that matters when other sectors say the model and mean the whole product.
Register every trained model with version, training-data lineage, and evaluation results; promote it through the same staged release gates as code, and monitor it as a running service.
e.g., a churn model is promoted from staging after its registry entry shows passing offline evals and a clean shadow run; rollback means re-pointing the endpoint to the previous registered version.
NIST AI 100-3, The Language of Trustworthy AI glossary
model (EU-U.S. TTC taxonomy entry: core component performing the input-to-output transformation of an AI system)