{"@context":"https://schema.org","@type":"DefinedTermSet","@id":"https://www.richardewing.io/glossary","name":"Technology & AI Glossary","description":"400+ definitions covering technical debt, AI economics, SaaS metrics, and engineering management.","hasDefinedTerm":[{"@type":"DefinedTerm","termCode":"technical-debt","name":"Technical Debt","description":"Technical debt is the implied cost of future rework caused by choosing an expedient solution now instead of a better approach that would take longer. First coined by Ward Cunningham in 1992, technical debt has become one of the most important concepts in software engineering economics.\n\nLike financial debt, technical debt accrues interest. Every shortcut, every \"we'll fix it later,\" every copy-pasted function adds to the principal. The interest comes in the form of slower development velocity, more bugs, longer onboarding times for new engineers, and increased fragility of the system.\n\nTechnical debt exists on a spectrum from deliberate (\"we know this is a shortcut but ship it anyway\") to accidental (\"we didn't realize this was a bad pattern until later\"). Both types compound over time. Organizations that don't actively measure and manage their technical debt risk reaching what Richard Ewing calls the Technical Insolvency Date — the specific quarter when maintenance costs consume 100% of engineering capacity.","url":"https://www.richardewing.io/glossary/technical-debt"},{"@type":"DefinedTerm","termCode":"legacy-code","name":"Legacy Code","description":"Legacy code is existing software that is difficult to modify, extend, or replace, typically because it was written with older technologies, lacks documentation, has no automated tests, or the original developers have left the organization.\n\nMichael Feathers defines legacy code simply as \"code without tests.\" This definition captures the core problem: legacy code is code you're afraid to change because you can't verify that your changes don't break existing functionality.\n\nLegacy code is not inherently bad — in fact, much legacy code is battle-tested and reliable. The problem is that it becomes increasingly expensive to maintain and nearly impossible to extend. Organizations often spend 60-80% of their engineering budget maintaining legacy systems rather than building new capabilities.","url":"https://www.richardewing.io/glossary/legacy-code"},{"@type":"DefinedTerm","termCode":"refactoring","name":"Refactoring","description":"Refactoring is the process of restructuring existing code without changing its external behavior. The goal is to improve the code's internal structure — readability, maintainability, performance — while keeping the software's functionality identical.\n\nMartin Fowler's canonical definition: \"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.\"\n\nRefactoring is not rewriting. Rewriting means replacing code with new code that does the same thing differently. Refactoring means improving the existing code incrementally. The distinction matters enormously for risk management — refactoring is low-risk because you're making small, testable changes. Rewriting is high-risk because you're replacing working code with untested code.","url":"https://www.richardewing.io/glossary/refactoring"},{"@type":"DefinedTerm","termCode":"code-smell","name":"Code Smell","description":"A code smell is a surface-level indicator in source code that suggests a deeper problem. The term was popularized by Martin Fowler and Kent Beck. Code smells are not bugs — the code works correctly — but they indicate structural weaknesses that will make future changes harder and more error-prone.\n\nCommon code smells include: duplicated code, long methods, large classes, long parameter lists, divergent change, shotgun surgery, feature envy, data clumps, primitive obsession, and dead code.\n\nCode smells are the early warning system for technical debt. Each smell is a small amount of debt. Individually, they're manageable. Collectively, they compound into the maintenance burden that slowly consumes engineering capacity.","url":"https://www.richardewing.io/glossary/code-smell"},{"@type":"DefinedTerm","termCode":"dora-metrics","name":"DORA Metrics","description":"DORA metrics are four key software delivery performance metrics identified by the DevOps Research and Assessment (DORA) team at Google. They are the industry standard for measuring engineering team effectiveness:\n\n1. **Deployment Frequency**: How often code is deployed to production. Elite teams deploy on-demand, multiple times per day.\n2. **Lead Time for Changes**: Time from code commit to production deployment. Elite teams achieve less than one hour.\n3. **Change Failure Rate**: Percentage of deployments that cause failures requiring remediation. Elite teams maintain 0-15%.\n4. **Mean Time to Recovery (MTTR)**: How quickly a team can restore service after an incident. Elite teams recover in less than one hour.\n\nThese metrics are backed by years of research across thousands of organizations worldwide and are validated as predictors of both software delivery performance and organizational performance.","url":"https://www.richardewing.io/glossary/dora-metrics"},{"@type":"DefinedTerm","termCode":"artificial-intelligence","name":"Artificial Intelligence (AI)","description":"Artificial intelligence is the simulation of human intelligence by computer systems. AI encompasses machine learning, natural language processing, computer vision, robotics, and expert systems. In 2026, AI has moved from experimental to operational, with enterprise AI adoption exceeding 70% globally.\n\nAI in business falls into three categories: predictive AI (forecasting outcomes from data), generative AI (creating new content like text, images, and code), and agentic AI (autonomous systems that take actions on behalf of users). Each category has different cost structures, risk profiles, and ROI timelines.\n\nFor product leaders and executives, the critical question is not 'should we use AI?' but 'what are the unit economics of our AI features?' Richard Ewing's AI Unit Economics Benchmark (AUEB) tool helps answer this question by calculating the true cost per useful AI output.","url":"https://www.richardewing.io/glossary/artificial-intelligence"},{"@type":"DefinedTerm","termCode":"large-language-model","name":"Large Language Model (LLM)","description":"A Large Language Model is a type of artificial intelligence trained on vast amounts of text data to understand and generate human language. LLMs like GPT-4, Claude, Gemini, and Llama power chatbots, code assistants, content generation, and enterprise AI applications.\n\nLLMs work by predicting the next token (word or word-piece) in a sequence. They're trained on billions of parameters using transformer architecture. The 'large' in LLM refers to both the training data (often trillions of tokens) and the model size (billions of parameters).\n\nThe economics of LLMs are unique: unlike traditional software with near-zero marginal cost, LLMs have significant variable costs that scale with usage. Every query costs compute. This creates what Richard Ewing calls the Cost of Predictivity — as you demand higher accuracy, costs scale exponentially.","url":"https://www.richardewing.io/glossary/large-language-model"},{"@type":"DefinedTerm","termCode":"ai-hallucination","name":"AI Hallucination","description":"An AI hallucination occurs when an artificial intelligence system generates output that is confident, fluent, and completely wrong. LLMs hallucinate because they're optimized to produce plausible-sounding text, not factually accurate text.\n\nHallucinations range from subtle factual errors to completely fabricated citations, statistics, or events. They're particularly dangerous because the AI presents false information with the same confidence as true information, making them hard to detect without expert verification.\n\nRichard Ewing coined the term AI Hallucination Debt to describe the accumulating liability when hallucinated outputs propagate through decision chains. Unlike technical debt which compounds linearly, hallucination debt compounds exponentially as downstream systems treat hallucinated outputs as ground truth.","url":"https://www.richardewing.io/glossary/ai-hallucination"},{"@type":"DefinedTerm","termCode":"agentic-ai","name":"Agentic AI","description":"Agentic AI refers to artificial intelligence systems that can autonomously plan, reason, and take actions to achieve goals with minimal human oversight. Unlike chatbots that respond to prompts, AI agents can browse the web, execute code, call APIs, manage workflows, and make decisions independently.\n\nIn 2026, agentic AI is the dominant trend in enterprise AI adoption. Companies are deploying AI agents for customer support, code generation, data analysis, and process automation. Multi-agent systems — where multiple AI agents collaborate — are emerging for complex workflows.\n\nThe key challenge with agentic AI is governance: when an AI agent makes a decision autonomously, who is liable? Richard Ewing's analysis of the AI liability gradient shows that as agent autonomy increases, organizational liability increases non-linearly.","url":"https://www.richardewing.io/glossary/agentic-ai"},{"@type":"DefinedTerm","termCode":"prompt-engineering","name":"Prompt Engineering","description":"Prompt engineering is the practice of crafting inputs (prompts) to AI language models to elicit desired outputs. It encompasses techniques like few-shot learning, chain-of-thought reasoning, system prompts, and structured output formatting.\n\nEffective prompt engineering can dramatically improve AI output quality and reduce costs. A well-crafted prompt can reduce token usage by 50-80% while improving accuracy, directly impacting the unit economics of AI features.\n\nAs AI models become more capable, prompt engineering is evolving from a technical skill to a strategic capability. In 2026, 'prompt engineer' has become an established role, though many predict it will be absorbed into product management and engineering as AI literacy becomes universal.","url":"https://www.richardewing.io/glossary/prompt-engineering"},{"@type":"DefinedTerm","termCode":"rag","name":"Retrieval-Augmented Generation (RAG)","description":"Retrieval-Augmented Generation (RAG) is an AI architecture pattern that combines a language model with a knowledge retrieval system. Instead of relying solely on the model's training data, RAG retrieves relevant documents from a knowledge base and includes them in the prompt, grounding the AI's responses in specific, verifiable information.\n\nRAG reduces hallucinations by giving the model factual context to work with. It's the most popular enterprise AI pattern in 2026 because it allows organizations to use their proprietary data with general-purpose language models without fine-tuning.\n\nThe economics of RAG involve balancing retrieval costs (vector database queries, embedding generation) against the cost of hallucination and the alternative cost of fine-tuning. For most enterprise use cases, RAG is significantly cheaper than fine-tuning while providing better accuracy on domain-specific questions.","url":"https://www.richardewing.io/glossary/rag"},{"@type":"DefinedTerm","termCode":"ai-governance","name":"AI Governance","description":"AI governance is the framework of policies, processes, and controls that guide how an organization develops, deploys, and monitors artificial intelligence systems. It encompasses ethical guidelines, risk management, compliance, accountability, transparency, and oversight.\n\nIn 2026, AI governance has moved from optional to mandatory. The EU AI Act requires risk assessments for high-risk AI systems. SEC disclosure rules require companies to report material AI risks. Board members are expected to understand AI governance at a strategic level.\n\nEffective AI governance includes: model risk management, bias testing, hallucination monitoring, cost governance, data privacy controls, human oversight mechanisms, incident response plans, and regular audits.","url":"https://www.richardewing.io/glossary/ai-governance"},{"@type":"DefinedTerm","termCode":"arr","name":"Annual Recurring Revenue (ARR)","description":"Annual Recurring Revenue (ARR) is the annualized value of recurring subscription revenue. It's the single most important metric for SaaS businesses and is calculated by multiplying Monthly Recurring Revenue (MRR) by 12, or by summing all active annual subscription values.\n\nARR is the foundation of SaaS valuation. In 2026, public SaaS companies trade at 5-15x ARR depending on growth rate, retention, and profitability. Private companies in growth stage typically value at 10-30x ARR.\n\nARR only includes recurring revenue — one-time fees, professional services, and usage overages are excluded unless they're contractually recurring. This distinction matters for valuation because investors value predictable, recurring revenue at a significant premium over variable revenue.","url":"https://www.richardewing.io/glossary/arr"},{"@type":"DefinedTerm","termCode":"mrr","name":"Monthly Recurring Revenue (MRR)","description":"Monthly Recurring Revenue (MRR) is the predictable, recurring revenue a SaaS business earns each month from its subscription customers. MRR is the building block of ARR (Annual Recurring Revenue = MRR × 12).\n\nMRR can be broken into components: New MRR (from new customers), Expansion MRR (upgrades and add-ons from existing customers), Churned MRR (lost from cancellations), and Contraction MRR (downgrades). Net New MRR = New + Expansion - Churned - Contraction.\n\nTracking MRR components gives you a much richer picture than total MRR alone. If your total MRR is growing but churned MRR is also growing, you have a leaky bucket that will eventually cap your growth.","url":"https://www.richardewing.io/glossary/mrr"},{"@type":"DefinedTerm","termCode":"churn-rate","name":"Churn Rate","description":"Churn rate is the percentage of customers or revenue lost over a given period. Customer churn (logo churn) measures the percentage of customers who cancel. Revenue churn measures the percentage of recurring revenue lost.\n\nChurn is the silent killer of SaaS businesses. Even small churn rates compound dramatically. At 5% monthly churn, you lose 46% of your customers annually. At 3% monthly churn, you lose 31%. This means you need to acquire that many new customers just to stay flat.\n\nNet revenue churn accounts for expansion revenue. If your customers who stay are upgrading enough to offset losses from cancellations, you achieve negative net churn — the holy grail of SaaS where your existing customer base grows without any new acquisitions.","url":"https://www.richardewing.io/glossary/churn-rate"},{"@type":"DefinedTerm","termCode":"net-revenue-retention","name":"Net Revenue Retention (NRR)","description":"Net Revenue Retention (NRR), also called Net Dollar Retention (NDR), measures the percentage of recurring revenue retained from existing customers over a period, including expansion, contraction, and churn.\n\nNRR is calculated as: (Starting MRR + Expansion - Contraction - Churn) ÷ Starting MRR × 100.\n\nAn NRR above 100% means your existing customers are spending more over time — you're growing even without new customers. Elite SaaS companies achieve 120-150% NRR. Snowflake famously reported 158% NRR. Below 100% means your customer base is shrinking.\n\nNRR is the single best predictor of SaaS company valuation. Companies with 130%+ NRR trade at 2-3x higher multiples than companies with 90% NRR, even with similar growth rates.","url":"https://www.richardewing.io/glossary/net-revenue-retention"},{"@type":"DefinedTerm","termCode":"rule-of-40","name":"Rule of 40","description":"The Rule of 40 is a SaaS benchmark that states a healthy software company's combined revenue growth rate and profit margin should equal or exceed 40%. For example, a company growing at 30% with 10% profit margins meets the Rule of 40. A company growing at 60% can afford -20% margins.\n\nThe Rule of 40 balances growth and profitability. High-growth companies can justify burning cash if they're growing fast enough. Slower-growing companies need to show profitability. The formula is: Revenue Growth Rate (%) + EBITDA Margin (%) ≥ 40.\n\nIn 2026, the Rule of 40 has become the default benchmark for SaaS board meetings and investor presentations. Companies exceeding the Rule of 40 trade at 2-4x higher valuation multiples than those below it.","url":"https://www.richardewing.io/glossary/rule-of-40"},{"@type":"DefinedTerm","termCode":"saas-valuation","name":"SaaS Valuation","description":"SaaS valuation is the process of determining the economic value of a software-as-a-service business. SaaS companies are typically valued as a multiple of their Annual Recurring Revenue (ARR), with multiples ranging from 3x for slow-growth companies to 30x+ for high-growth, high-retention businesses.\n\nKey factors that drive SaaS valuation multiples include: ARR growth rate, net revenue retention (NRR), gross margins, Rule of 40 score, capital efficiency, market size (TAM), competitive positioning, and team quality.\n\nIn 2026, the median public SaaS company trades at approximately 7-8x forward revenue. High-growth companies (40%+ growth) trade at 12-20x. AI-native SaaS companies with strong unit economics command premium multiples.","url":"https://www.richardewing.io/glossary/saas-valuation"},{"@type":"DefinedTerm","termCode":"unit-economics","name":"Unit Economics","description":"Unit economics measures the direct revenues and costs associated with a particular business unit — typically a customer, transaction, or product unit. In SaaS, unit economics focuses on Customer Acquisition Cost (CAC), Lifetime Value (LTV), and the LTV:CAC ratio.\n\nHealthy SaaS unit economics have: LTV:CAC ratio of 3:1 or higher, CAC payback period under 18 months, and gross margins above 70%. When these metrics are healthy, scaling the business generates increasing returns.\n\nFor AI products, unit economics are more complex because AI features have significant variable costs (compute, API calls, inference). Richard Ewing's AI Unit Economics Benchmark (AUEB) tool helps companies calculate the true unit economics of AI features, including the Cost of Predictivity.","url":"https://www.richardewing.io/glossary/unit-economics"},{"@type":"DefinedTerm","termCode":"burn-rate","name":"Burn Rate & Runway","description":"Burn rate is the rate at which a company is spending its cash reserves. Monthly burn rate = total monthly expenses minus total monthly revenue. Runway is how many months of cash a company has left at its current burn rate: Runway = Cash Balance ÷ Monthly Burn Rate.\n\nFor startups, burn rate is the clock ticking toward either profitability or the next fundraise. A company with $3M in the bank burning $250K/month has 12 months of runway. Best practice is to maintain at least 12-18 months of runway.\n\nBurn multiple — burn rate divided by net new ARR — measures how efficiently you're converting spending into growth. A burn multiple below 2x is efficient. Above 3x is concerning. Above 5x means you're burning cash without proportional growth.","url":"https://www.richardewing.io/glossary/burn-rate"},{"@type":"DefinedTerm","termCode":"product-market-fit","name":"Product-Market Fit","description":"Product-market fit (PMF) is the degree to which a product satisfies strong market demand. Marc Andreessen defined it as 'being in a good market with a product that can satisfy that market.' It's the most important milestone for any startup or new product.\n\nSigns of product-market fit include: organic growth without marketing, high retention rates, customers becoming evangelists, demand exceeding supply, and usage data showing deep engagement rather than surface-level adoption.\n\nSigns you DON'T have product-market fit: high churn, users sign up but don't return, growth only comes from paid acquisition, users need extensive onboarding to see value, and feature requests are scattered across unrelated areas.\n\nRichard Ewing's perspective: 'The best AI product I ever led had zero customers' — a reminder that technical excellence doesn't guarantee product-market fit. Validation must be economic, not just technical.","url":"https://www.richardewing.io/glossary/product-market-fit"},{"@type":"DefinedTerm","termCode":"rice-framework","name":"RICE Framework","description":"RICE is a prioritization framework used by product managers to score and rank product ideas. RICE stands for Reach (how many people will this impact?), Impact (how much will it impact each person?), Confidence (how sure are you about your estimates?), and Effort (how much work is required?).\n\nThe RICE score formula is: (Reach × Impact × Confidence) ÷ Effort. Higher scores indicate higher-priority initiatives.\n\nRICE was developed by Intercom and has become one of the most widely used product prioritization frameworks. Its strength is forcing product managers to think quantitatively about each factor rather than relying on gut feeling or stakeholder politics.","url":"https://www.richardewing.io/glossary/rice-framework"},{"@type":"DefinedTerm","termCode":"north-star-metric","name":"North Star Metric","description":"A North Star Metric is the single metric that best captures the core value your product delivers to customers. It serves as the primary measure of product success and aligns the entire organization around one measurable outcome.\n\nExamples: Airbnb's North Star Metric is 'nights booked.' Spotify's is 'time spent listening.' Slack's is 'daily active teams.' Each captures the core value exchange between product and customer.\n\nA good North Star Metric has three properties: it reflects customer value (not just business value), it's a leading indicator of revenue growth, and it's actionable (teams can influence it).","url":"https://www.richardewing.io/glossary/north-star-metric"},{"@type":"DefinedTerm","termCode":"jobs-to-be-done","name":"Jobs To Be Done (JTBD)","description":"Jobs To Be Done (JTBD) is a product strategy framework that focuses on the underlying 'job' a customer is trying to accomplish rather than the customer's demographics or the product's features. Developed by Clayton Christensen, Tony Ulwick, and Bob Moesta, JTBD reframes product decisions around customer needs.\n\nThe classic example: 'People don't want a quarter-inch drill. They want a quarter-inch hole.' JTBD goes further: they don't even want the hole — they want to hang a family photo to feel a sense of belonging.\n\nJTBD interviews reveal the functional, emotional, and social dimensions of customer needs, leading to products that customers actually want rather than products that check feature boxes.","url":"https://www.richardewing.io/glossary/jobs-to-be-done"},{"@type":"DefinedTerm","termCode":"kano-model","name":"Kano Model","description":"The Kano Model is a product development framework that categorizes features based on how they affect customer satisfaction. Developed by Professor Noriaki Kano, the model identifies five categories of features:\n\n1. **Must-Be (Basic)**: Features customers expect. Their absence causes dissatisfaction, but their presence doesn't increase satisfaction. Example: a login page.\n2. **One-Dimensional (Performance)**: Features where satisfaction scales linearly with how well they're implemented. Example: page load speed.\n3. **Attractive (Delighters)**: Features customers don't expect but love when they find them. Their absence doesn't cause dissatisfaction. Example: AI-powered suggestions.\n4. **Indifferent**: Features customers don't care about either way.\n5. **Reverse**: Features that some customers actively dislike.\n\nThe Kano Model helps product teams allocate resources optimally: ensure Must-Be features work flawlessly, invest in Performance features that differentiate, and strategically add Delighters.","url":"https://www.richardewing.io/glossary/kano-model"},{"@type":"DefinedTerm","termCode":"engineering-productivity","name":"Engineering Productivity","description":"Engineering productivity measures how effectively a software engineering team converts resources (time, people, money) into valuable software output. It's one of the most debated topics in technology leadership because measuring it incorrectly can damage morale and incentivize the wrong behaviors.\n\nCommon productivity metrics include: DORA metrics (deployment frequency, lead time, change failure rate, MTTR), SPACE framework (satisfaction, performance, activity, communication, efficiency), story points completed, and code review turnaround time.\n\nRichard Ewing's perspective: raw productivity metrics like lines of code or story points are misleading. The Revenue Per Engineer (APER) metric connects engineering output to business outcomes — measuring the revenue generated per engineer rather than the activity generated.","url":"https://www.richardewing.io/glossary/engineering-productivity"},{"@type":"DefinedTerm","termCode":"revenue-per-engineer","name":"Revenue Per Engineer","description":"Revenue Per Engineer is a financial efficiency metric that divides a company's total revenue by the number of engineers. It measures how effectively an engineering organization converts headcount into business value.\n\nBenchmarks vary dramatically by stage and business model. Elite companies like Stripe generate $1M+ per engineer. Growth-stage SaaS companies typically range from $200K-$500K per engineer. Enterprise software companies with large professional services components may be lower.\n\nRichard Ewing's APER (Annualized Productivity-to-Engineering Ratio) diagnostic goes beyond simple revenue/headcount by accounting for engineering mix (senior vs. junior), maintenance burden, and AI tooling impact.","url":"https://www.richardewing.io/glossary/revenue-per-engineer"},{"@type":"DefinedTerm","termCode":"devops","name":"DevOps","description":"DevOps is a set of practices, tools, and cultural philosophies that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.\n\nDevOps practices include: continuous integration and continuous delivery (CI/CD), infrastructure as code, automated testing, monitoring and observability, incident management, and blameless postmortems.\n\nIn 2026, DevOps has evolved into Platform Engineering — building internal developer platforms that abstract away infrastructure complexity. Related disciplines include DevSecOps (security integrated into the pipeline), MLOps (ML model lifecycle management), and LLMOps (LLM-specific operations).","url":"https://www.richardewing.io/glossary/devops"},{"@type":"DefinedTerm","termCode":"cicd","name":"CI/CD (Continuous Integration / Continuous Delivery)","description":"CI/CD is a software development practice that automates the process of integrating code changes (CI) and delivering them to production (CD).\n\nContinuous Integration means developers merge code changes frequently (multiple times per day) into a shared repository, where automated tests verify each change. Continuous Delivery extends this by automatically preparing code for release to production. Continuous Deployment goes further by automatically deploying every change that passes tests to production.\n\nCI/CD is the foundation of modern software delivery. Teams with mature CI/CD pipelines achieve deployment frequencies of multiple times per day with change failure rates below 15% — the hallmarks of elite engineering performance per DORA metrics.","url":"https://www.richardewing.io/glossary/cicd"},{"@type":"DefinedTerm","termCode":"fractional-cto","name":"Fractional CTO","description":"A Fractional CTO is an experienced technology executive who provides part-time CTO services to companies that need senior technology leadership but can't justify or afford a full-time CTO. Fractional CTOs typically work 10-20 hours per week across multiple clients.\n\nFractional CTOs are common for: early-stage startups with non-technical founders, growth-stage companies between CTO hires, PE- or VC-backed companies needing technology oversight, and organizations undergoing digital transformation.\n\nA fractional CTO provides strategic technology direction, architecture decisions, engineering team assessment, vendor evaluation, due diligence support, and board-level technology reporting.","url":"https://www.richardewing.io/glossary/fractional-cto"},{"@type":"DefinedTerm","termCode":"digital-transformation","name":"Digital Transformation","description":"Digital transformation is the process of integrating digital technology into all areas of a business, fundamentally changing how it operates and delivers value to customers. In 2026, digital transformation has evolved beyond basic digitization to encompass AI integration, agentic workflows, and data-driven decision making.\n\nSuccessful digital transformation requires alignment across technology, processes, people, and culture. Most digital transformations fail not because of technology but because of organizational resistance, unclear strategy, or poor change management.\n\nFor CIOs and board members, digital transformation is no longer optional — it's a survival requirement. Companies that haven't transformed digitally face competitive obsolescence, talent flight, and inability to leverage AI capabilities.","url":"https://www.richardewing.io/glossary/digital-transformation"},{"@type":"DefinedTerm","termCode":"technical-insolvency-date","name":"Technical Insolvency Date","description":"The Technical Insolvency Date (TID) is a framework coined by Richard Ewing that identifies the specific future quarter when an organization's technical debt maintenance will consume 100% of engineering capacity, leaving zero time for new feature development.\n\nThe TID is calculated by projecting the current maintenance percentage growth against available engineering hours. If a team currently spends 45% of time on maintenance and that percentage grows 3% per quarter, the Technical Insolvency Date can be calculated as the quarter when maintenance reaches 100%.\n\nMost organizations track technical debt qualitatively. The TID makes it quantitative and urgent. Telling a board 'we have technical debt' gets ignored. Telling a board 'we are 8 quarters from technical insolvency' gets immediate action.\n\nThe Product Debt Index (PDI) calculator at richardewing.io/tools/pdi automates this calculation, translating maintenance burden into dollar terms and projecting the Technical Insolvency Date.","url":"https://www.richardewing.io/glossary/technical-insolvency-date"},{"@type":"DefinedTerm","termCode":"innovation-tax","name":"Innovation Tax","description":"The Innovation Tax is a framework coined by Richard Ewing that measures the hidden cost of maintenance work that gets reported as innovation investment. It is OpEx masquerading as R&D investment, causing organizations to dramatically overestimate their effective engineering velocity.\n\nWhen a team reports '65% of time on new features' but the actual number is 23%, the 42-point gap is the Innovation Tax. This gap causes CFOs and boards to overestimate R&D productivity and make poor capital allocation decisions.\n\nThe Innovation Tax is insidious because it's invisible in standard reporting. Engineering teams don't intentionally misreport — the maintenance work is scattered across feature work, making it hard to isolate. Bug fixes get bundled into feature sprints. Infrastructure upgrades get coded as feature dependencies.\n\nBenchmark: >40% Innovation Tax is dangerous. >70% is terminal — the organization is approaching the Technical Insolvency Date.","url":"https://www.richardewing.io/glossary/innovation-tax"},{"@type":"DefinedTerm","termCode":"cost-of-predictivity","name":"Cost of Predictivity","description":"The Cost of Predictivity is a framework coined by Richard Ewing that measures the variable cost of AI accuracy. Unlike traditional software with near-zero marginal costs, AI features have costs that scale with usage and accuracy requirements.\n\nThe key insight: as AI correctness increases, cost scales exponentially. Moving from 80% accuracy to 95% accuracy often requires a 10x increase in compute and retrieval costs. Moving from 95% to 99% may require another 10x.\n\nThis creates margin compression that traditional engineering metrics don't capture. A feature that works beautifully at 100 users may be economically unviable at 100,000 users because AI inference costs scale linearly with usage while accuracy improvements require exponentially more resources.\n\nThe AI Unit Economics Benchmark (AUEB) calculator at richardewing.io/tools/aueb helps companies calculate their Cost of Predictivity and identify their AI margin collapse point.","url":"https://www.richardewing.io/glossary/cost-of-predictivity"},{"@type":"DefinedTerm","termCode":"kill-switch-protocol","name":"Kill Switch Protocol","description":"The Kill Switch Protocol is a framework coined by Richard Ewing for identifying and deprecating 'Zombie Features' — code that requires ongoing maintenance but generates zero incremental value.\n\nMost organizations add features but never remove them. Over time, 40-60% of a codebase becomes maintenance burden with no corresponding value. The Kill Switch Protocol provides structured criteria for when to kill a feature and how to execute the deprecation safely.\n\nThe protocol involves: identifying zombie features (features with maintenance cost but no usage or revenue contribution), quantifying the cost of keeping them alive, assessing deprecation risk, creating a sunset timeline, communicating to affected stakeholders, and executing the removal with rollback capability.","url":"https://www.richardewing.io/glossary/kill-switch-protocol"},{"@type":"DefinedTerm","termCode":"feature-bloat-calculus","name":"Feature Bloat Calculus","description":"Feature Bloat Calculus is a framework coined by Richard Ewing for determining when a feature's maintenance cost exceeds its value contribution. It quantifies the hidden tax of feature accumulation.\n\nThe formula factors in: direct maintenance hours, opportunity cost of those hours (what else the engineers could build), and the compounding effect on system complexity (each feature makes every other feature harder to maintain).\n\nThe key insight: every feature you add makes every future feature harder. This compounding effect is invisible in sprint-level metrics but devastating at the portfolio level. Feature Bloat Calculus makes this hidden cost visible so product teams can make rational keep/kill decisions.","url":"https://www.richardewing.io/glossary/feature-bloat-calculus"},{"@type":"DefinedTerm","termCode":"audit-interview","name":"Audit Interview","description":"The Audit Interview is a hiring protocol coined by Richard Ewing that tests verification skills instead of code generation skills. Candidates are given AI-generated code with hidden flaws and asked to identify the problems.\n\nThe premise: AI can generate code. Catching what AI gets wrong is the scarce human skill. Traditional coding interviews test a skill AI now performs better than humans. The Audit Interview tests the skill that matters in the AI age: engineering judgment.\n\nThe protocol: present AI-generated code with 3-5 hidden bugs (security vulnerabilities, logic errors, performance issues, edge cases). Candidate has 10 minutes to find issues. Score based on bugs found, severity ranking, and the 'what would you ship?' judgment call.\n\nThe 4 Dimensions of Engineering Judgment scored: Verification (finding bugs), Prioritization (ranking severity), Communication (explaining the risk), and Judgment (ship/no-ship decision).","url":"https://www.richardewing.io/glossary/audit-interview"},{"@type":"DefinedTerm","termCode":"product-economist","name":"Product Economist","description":"A Product Economist is a role and methodology coined by Richard Ewing that treats product decisions as economic decisions. Instead of measuring velocity, story points, or features shipped, a Product Economist measures Return on Invested Capital (ROIC), Cost of Goods Sold (COGS) efficiency, and technical debt in dollar terms.\n\nThe Product Economist methodology recognizes that engineering is capital allocation, not just feature delivery. Every sprint is an investment decision. Every feature has ongoing maintenance costs. Every architecture choice has financial implications.\n\nThe Product Economist Doctrine holds four principles: Capital Allocation > Agile Theater, The Truth is in the P&L, Kill Zombies Ruthlessly, and Sovereignty Over Dependency.","url":"https://www.richardewing.io/glossary/product-economist"},{"@type":"DefinedTerm","termCode":"vibe-coding","name":"Vibe Coding","description":"Vibe coding is a term that emerged in 2025-2026 to describe the practice of using AI to generate code through natural language prompts rather than writing code by hand. The developer describes what they want in plain English, and AI tools like Cursor, GitHub Copilot, or Claude generate the implementation.\n\nVibe coding dramatically increases initial development speed but introduces new risks: AI-generated code may contain subtle bugs, security vulnerabilities, or architectural anti-patterns that are hard to detect. Richard Ewing warns of 'vibe coding debt' — technical debt that accumulates faster because code is generated without deep understanding of its implications.\n\nThe 4 Laws of Probabilistic Software Development (coined by Richard Ewing) address the risks of vibe coding: code generated by probability is correct by probability, not by proof.","url":"https://www.richardewing.io/glossary/vibe-coding"},{"@type":"DefinedTerm","termCode":"monolith-to-microservices","name":"Monolith to Microservices","description":"Monolith to microservices migration is the process of breaking a single, large application (monolith) into smaller, independent services (microservices) that communicate over APIs. It's one of the most common — and most dangerous — architectural transformations.\n\nThe promise: independent deployment, technology flexibility, team autonomy, and better scalability. The reality: distributed systems are inherently more complex. Many organizations that migrate to microservices end up with a 'distributed monolith' — all the complexity of microservices with none of the benefits.\n\nThe decision to migrate should be driven by economics, not fashion. If your monolith's maintenance burden is approaching the Technical Insolvency Date, migration may be warranted. If your monolith is working and your team is productive, the migration cost may not be justified.","url":"https://www.richardewing.io/glossary/monolith-to-microservices"},{"@type":"DefinedTerm","termCode":"ai-volatility-tax","name":"AI Volatility Tax","description":"The AI Volatility Tax is a framework developed by Richard Ewing (expanding on concepts from Steve Oppenheim) that measures the hidden labor cost of verifying probabilistic AI outputs. Unlike traditional deterministic software where QA is a one-time cost, probabilistic AI requires continuous human-in-the-loop verification on every output.\n\nThis ongoing \"tax\" occurs because you can never fully trust an LLM. As a result, the cost structure of an AI feature isn't just the API call; it includes the human labor required to verify, correct, and manage the output of the model in production.\n\nIf an AI writes code 10x faster but requires a senior engineer to spend hours validating that the code isn't hallucinating a vulnerable package, the AI Volatility Tax is the cost of that engineer's time.","url":"https://www.richardewing.io/glossary/ai-volatility-tax"},{"@type":"DefinedTerm","termCode":"ai-response-drift","name":"AI Response Drift (LLM Inconsistency)","description":"AI Response Drift (or LLM Inconsistency) is the phenomenon where a language model produces different, conflicting, or degraded answers to the exact same prompt over time or across repeated executions. \n\nUnlike traditional software APIs which are deterministic (the same input always yields the exact same output), LLMs are probabilistic. They sample from a distribution of possible next tokens. Even with temperature set to 0, underlying model updates, routing changes, or slight context shifts can cause the model's behavior to drift.\n\nRichard Ewing identifies Response Drift as the primary barrier to autonomous agentic orchestration. If the underlying intelligence is unstable, any autonomous workflow built on top of it becomes brittle and economically unviable.","url":"https://www.richardewing.io/glossary/ai-response-drift"},{"@type":"DefinedTerm","termCode":"execution-layer","name":"Execution Layer","description":"The Execution Layer is the deterministic boundary within a software application that translates probabilistic AI intent into safe, verifiable, and predictable system actions.\n\nIn Richard Ewing's doctrine, the \"Brain\" (the LLM) should be strictly separated from the \"Hands\" (the Execution Layer). The AI is allowed to reason, plan, and format data, but it is explicitly forbidden from executing direct changes to databases, controlling systems, or taking irreversible actions.\n\nInstead, the AI passes structured intent (like a validated JSON payload) to the Execution Layer. The Execution Layer is written in deterministic, testable code (like TypeScript or Python) and enforces strict business logic, input validation, and access controls before performing the requested action.","url":"https://www.richardewing.io/glossary/execution-layer"},{"@type":"DefinedTerm","termCode":"evergreen-ratio","name":"Evergreen Ratio","description":"The Evergreen Ratio is a financial metric coined by Richard Ewing that measures the profitability of AI workflows. It compares the number of times an AI-generated output is reused (cached/served deterministically) against the number of times it must be freshly generated (inferred probabilistically).\n\nThe formula: [Cached Hits] / [Live Inferences] = Evergreen Ratio.\n\nIf every user query requires a live LLM inference, the Evergreen Ratio is 0, and your profit margins will collapse at scale due to the Cost of Predictivity. If an AI generates a report once and 100 users read it from the cache, the ratio is 100, and the feature enjoys SaaS-like 80%+ gross margins.\n\nThe Evergreen Ratio proves that the most profitable AI companies are actually the ones that use the least AI in production.","url":"https://www.richardewing.io/glossary/evergreen-ratio"},{"@type":"DefinedTerm","termCode":"agentic-process-automation","name":"Agentic Process Automation (APA)","description":"Agentic Process Automation (APA) is the 2026 evolution of Robotic Process Automation (RPA). Where legacy RPA relied on brittle, deterministic scripts and static screen-scraping to move data, APA uses autonomous language models (agents) to complete unstructured, multi-step workflows.\n\nA traditional RPA bot breaks if a vendor changes their invoice template. An APA agent simply reads the new invoice, understands the structural change, extracts the data, and proceeds with the workflow without human intervention or reprogramming.\n\nHowever, APA introduces massive governance risks. Because the agents interpret data probabilistically rather than deterministically, they require strict Execution Layers and boundary monitoring to prevent autonomous hallucination cascades.","url":"https://www.richardewing.io/glossary/agentic-process-automation"},{"@type":"DefinedTerm","termCode":"sovereign-ai-substrate","name":"Sovereign AI Substrate","description":"A Sovereign AI Substrate refers to the localized, deeply-controlled deployment of generative AI models (typically open-weights models like Llama, Mistral, or DeepSeek) running entirely on untethered hardware or private bare-metal infrastructure.\n\nIn 2026, massive enterprises are executing \"Cloud Repatriation for AI.\" Sending proprietary intellectual property, trade secrets, and PII to public cloud providers (OpenAI, Anthropic) introduces unacceptable data leakage risks and catastrophic margin compression due to variable API token costs. \n\nA Sovereign AI Substrate allows an organization to own its intelligence layer outright. The models run locally, the data never leaves the firewall, and the Cost of Predictivity fundamentally shifts from variable OpEx to fixed CapEx.","url":"https://www.richardewing.io/glossary/sovereign-ai-substrate"},{"@type":"DefinedTerm","termCode":"model-collapse","name":"Model Collapse (Synthetic Data Exhaust)","description":"Model Collapse describes the mathematical degradation of generative AI models when they are trained recursively on AI-generated data (Synthetic Data Exhaust) rather than human-generated ground truth.\n\nAs the internet becomes overwhelmingly populated by AI-generated text, images, and code, subsequent generations of models inevitably scrape and train on this synthetic data. Over time, the models lose the \"tails\" of the original human data distribution. They begin to continuously output generic, homogenous, and statistically probable blandness—eventually suffering complete cognitive inbreeding.\n\nIn 2026, Model Collapse has created a massive premium on verified, purely human datasets. Organizations that possess walled gardens of human-generated ground truth hold the most valuable assets in the AI economy.","url":"https://www.richardewing.io/glossary/model-collapse"},{"@type":"DefinedTerm","termCode":"thermodynamic-compute-cost","name":"Thermodynamic Compute Cost","description":"Thermodynamic Compute Cost is the baseline energy expenditure required to execute an AI inference operation, irrespective of cloud provider markup. It represents the absolute physical floor of AI unit economics.\n\nWhile SaaS logic scales at near-zero marginal cost, AI inference scales linearly with energy consumption (GPU utilization, cooling, data center wattage). In 2026, the scarcity of power grid capacity—and the resulting shift toward dedicated nuclear/SMR-powered AI data centers—dictates capability.\n\nFor enterprise CTOs, calculating Thermodynamic Compute Cost is required to determine whether an AI feature will ever be economically viable at scale. If the energy cost of generating a summary exceeds the business value of that summary, the feature is fundamentally unsustainable.","url":"https://www.richardewing.io/glossary/thermodynamic-compute-cost"},{"@type":"DefinedTerm","termCode":"system-2-reasoning-tokens","name":"System 2 Reasoning Tokens","description":"In conversational AI, System 2 reasoning refers to the deliberate, multi-step logical deduction processes (like \"Chain of Thought\" or \"Tree of Thoughts\") executed by an LLM prior to emitting the final response. It introduces \"Test-Time Compute\" by consuming tokens invisibly to strictly verify logic.","url":"https://www.richardewing.io/glossary/system-2-reasoning-tokens"},{"@type":"DefinedTerm","termCode":"ai-dspm","name":"AI Data Security Posture Management (DSPM)","description":"A specialized security architecture designed to autonomously discover, map, and protect unstructured data stores and vector databases from being inadvertently ingested by Large Language Models or shadow agents.","url":"https://www.richardewing.io/glossary/ai-dspm"},{"@type":"DefinedTerm","termCode":"hallucination-entropy","name":"Hallucination Entropy","description":"A measurable metric describing the rate at which an autonomous agent’s output deviates from factual reality or explicit instructions as the operating context window becomes saturated with multi-turn generative logic.","url":"https://www.richardewing.io/glossary/hallucination-entropy"},{"@type":"DefinedTerm","termCode":"dependency-hell","name":"Dependency Hell","description":"Dependency hell describes the frustrating situation where software packages rely on other packages that conflict with each other, creating complex webs of incompatible version requirements. It is one of the most common and time-consuming forms of technical debt.\n\nIn modern software, a single application may have hundreds or thousands of transitive dependencies. When Package A requires version 2.x of Library Z, but Package B requires version 3.x of the same library, you're in dependency hell. The problem compounds exponentially as the dependency graph grows.\n\nDependency hell manifests in several ways: version conflicts that prevent updates, security vulnerabilities in pinned old versions, build failures after seemingly innocuous changes, and \"works on my machine\" problems caused by environment-specific dependency resolution.\n\nThe economic cost is substantial. Engineering teams can spend 10-20% of their time managing dependencies — updating packages, resolving conflicts, testing compatibility, and rolling back breaking changes. This is pure maintenance overhead that produces zero customer value.","url":"https://www.richardewing.io/glossary/dependency-hell"},{"@type":"DefinedTerm","termCode":"code-coverage","name":"Code Coverage","description":"Code coverage is a metric that measures the percentage of source code executed during automated testing. It indicates how thoroughly your test suite exercises the codebase, typically measured as line coverage, branch coverage, function coverage, or statement coverage.\n\nLine coverage measures the percentage of code lines executed by tests. Branch coverage measures whether both true and false paths of conditional statements are tested. Function coverage measures whether every function has been called. Branch coverage is generally considered the most meaningful metric.\n\nHigh code coverage (>80%) doesn't guarantee code quality — you can have 100% coverage with terrible tests that assert nothing. But low code coverage (<40%) almost always indicates high risk. Code without tests is code you're afraid to change, which is the definition of legacy code.\n\nThe relationship between code coverage and technical debt is inverse: as coverage decreases, the cost of making changes increases because every modification carries unverified risk. Teams with low coverage deploy less frequently, have higher change failure rates, and spend more time on manual QA.","url":"https://www.richardewing.io/glossary/code-coverage"},{"@type":"DefinedTerm","termCode":"cyclomatic-complexity","name":"Cyclomatic Complexity","description":"Cyclomatic complexity is a quantitative measure of the number of linearly independent paths through a program's source code. Invented by Thomas J. McCabe in 1976, it counts the number of decision points (if statements, loops, switch cases) plus one.\n\nA function with no branches has complexity 1. Each if/else adds 1. Each loop adds 1. A function with complexity 10 has 10 independent paths that need to be tested for full coverage.\n\nBenchmarks: 1-10 is simple and low risk. 11-20 is moderate complexity. 21-50 is high complexity and hard to test. Above 50 is untestable and should be refactored immediately.\n\nHigh cyclomatic complexity is one of the strongest predictors of bugs. Research shows that modules with complexity >20 are 5x more likely to contain defects than modules with complexity <10. It's also the primary driver of long testing cycles — each independent path needs its own test case.","url":"https://www.richardewing.io/glossary/cyclomatic-complexity"},{"@type":"DefinedTerm","termCode":"tech-debt-quadrant","name":"Technical Debt Quadrant","description":"The Technical Debt Quadrant is a classification framework by Martin Fowler that categorizes technical debt along two axes: deliberate vs. inadvertent, and reckless vs. prudent.\n\n**Reckless + Deliberate**: \"We don't have time for design.\" The team knowingly takes shortcuts without planning to fix them.\n\n**Reckless + Inadvertent**: \"What's layering?\" The team doesn't know enough to realize they're creating problems.\n\n**Prudent + Deliberate**: \"We must ship now and deal with consequences.\" The team understands the tradeoff and has a plan to address the debt.\n\n**Prudent + Inadvertent**: \"Now we know how we should have done it.\" The team learns better approaches only after building the first version.\n\nThe quadrant helps teams and leaders communicate about debt more precisely. \"We have tech debt\" is vague. \"We have prudent deliberate debt from the Q3 launch that's now costing us 20 hours/sprint\" is actionable.","url":"https://www.richardewing.io/glossary/tech-debt-quadrant"},{"@type":"DefinedTerm","termCode":"dead-code","name":"Dead Code","description":"Dead code is source code that exists in the codebase but is never executed during normal operation. It includes unreachable code paths, unused functions, commented-out code blocks, deprecated features that were never removed, and variables that are assigned but never read.\n\nDead code is surprisingly common. Studies suggest that 10-30% of a typical codebase is dead code. It accumulates naturally as features evolve, requirements change, and refactoring efforts leave remnants behind.\n\nWhile dead code doesn't directly cause bugs, it has real costs: it increases cognitive load for developers reading the codebase, inflates build times, creates false positives in security scans, and makes refactoring harder because developers aren't sure if the code might be needed.\n\nRichard Ewing's Kill Switch Protocol addresses dead code systematically by identifying \"Zombie Features\" — code that costs money to maintain but produces zero value.","url":"https://www.richardewing.io/glossary/dead-code"},{"@type":"DefinedTerm","termCode":"spaghetti-code","name":"Spaghetti Code","description":"Spaghetti code is a pejorative term for source code with a complex, tangled control flow that makes it extremely difficult to understand, maintain, or modify. The name comes from the resemblance to a plate of spaghetti — you can't follow any single strand without getting lost in the tangle.\n\nSpaghetti code typically features: deeply nested conditionals, excessive use of goto statements or their modern equivalents, functions that are hundreds or thousands of lines long, unclear variable naming, tightly coupled components, and global state mutations scattered throughout.\n\nSpaghetti code is both a cause and symptom of technical debt. It often starts as clean code that accumulates patches, hotfixes, and quick additions until the original structure is unrecognizable. Each modification makes the next modification harder, creating a vicious cycle.\n\nThe cost of spaghetti code is measurable: onboarding new developers takes 2-5x longer, bug fix times increase exponentially, and the risk of introducing regressions with every change approaches certainty.","url":"https://www.richardewing.io/glossary/spaghetti-code"},{"@type":"DefinedTerm","termCode":"coupling-and-cohesion","name":"Coupling & Cohesion","description":"Coupling and cohesion are complementary software design metrics. Coupling measures how dependent modules are on each other. Cohesion measures how related the elements within a single module are. Good software design aims for low coupling and high cohesion.\n\n**Low coupling** means modules can be modified, replaced, or tested independently. A change to Module A doesn't require changes to Modules B, C, and D.\n\n**High cohesion** means every element in a module serves a single, well-defined purpose. A \"UserService\" that handles user CRUD, email notifications, billing, and report generation has low cohesion.\n\nThe opposite — high coupling and low cohesion — is the defining characteristic of unmaintainable systems. When everything depends on everything else and each module does many unrelated things, every change is risky and expensive.\n\nMicroservices architecture aims to enforce low coupling by separating services at process boundaries. But poorly designed microservices can create \"distributed monolith\" — all the coupling of a monolith with the operational complexity of microservices.","url":"https://www.richardewing.io/glossary/coupling-and-cohesion"},{"@type":"DefinedTerm","termCode":"test-driven-development","name":"Test-Driven Development (TDD)","description":"Test-Driven Development is a software development practice where tests are written before the code they test. The TDD cycle is: Red (write a failing test), Green (write minimal code to pass the test), Refactor (improve the code while keeping tests passing).\n\nTDD was popularized by Kent Beck and is a core practice of Extreme Programming (XP). It produces code with high test coverage by default, since every line of production code exists to make a test pass.\n\nProponents argue TDD produces better-designed code because writing tests first forces you to think about interfaces and behavior before implementation. Critics argue TDD slows initial development speed and that writing tests after (Test-After Development) achieves similar quality.\n\nThe data is mixed. Studies show TDD reduces defect rates by 40-80% compared to no testing, but the difference between TDD and Test-After is smaller (~20%). The real benefit may be behavioral: TDD practitioners write more tests, period.","url":"https://www.richardewing.io/glossary/test-driven-development"},{"@type":"DefinedTerm","termCode":"code-review","name":"Code Review","description":"Code review is the systematic examination of source code by peers before it is merged into the main codebase. It is one of the most effective quality assurance practices in software engineering, catching bugs, enforcing standards, and spreading knowledge across the team.\n\nModern code review happens through pull requests (PRs) or merge requests (MRs) on platforms like GitHub, GitLab, or Bitbucket. A developer submits their changes, one or more reviewers examine the diff, leave comments, request changes, and eventually approve the merge.\n\nEffective code reviews catch 60-90% of defects that automated testing misses. They also serve as knowledge transfer — junior developers learn patterns from senior reviewers, and senior developers stay aware of codebase changes they didn't write.\n\nGoogle's research shows that code review effectiveness drops sharply after 200 lines of code. Smaller, more frequent reviews are significantly more effective than large batch reviews.","url":"https://www.richardewing.io/glossary/code-review"},{"@type":"DefinedTerm","termCode":"technical-debt-ratio","name":"Technical Debt Ratio (TDR)","description":"The Technical Debt Ratio is a quantitative metric that expresses the cost of fixing all known technical debt as a percentage of the cost of rewriting the entire application from scratch. It provides a single number that summarizes the overall health of a codebase.\n\nTDR = (Remediation Cost ÷ Development Cost) × 100\n\nA TDR of 5% means fixing all known issues would cost 5% of what a complete rewrite would cost — healthy. A TDR of 15% is concerning. Above 20% indicates the codebase is in serious trouble and approaching what Richard Ewing calls the Technical Insolvency Date.\n\nThe TDR is calculated by static analysis tools like SonarQube, which estimate remediation time for each issue and model development cost based on codebase size. While the absolute numbers are estimates, the trend over time is highly informative.","url":"https://www.richardewing.io/glossary/technical-debt-ratio"},{"@type":"DefinedTerm","termCode":"boy-scout-rule","name":"Boy Scout Rule","description":"The Boy Scout Rule in software engineering states: \"Always leave the code better than you found it.\" Attributed to Robert C. Martin (Uncle Bob), the principle encourages developers to make small improvements to any code they touch, even if those improvements aren't part of the current task.\n\nExamples include: renaming a confusing variable, adding a missing test, extracting a duplicated block into a function, updating a deprecated API call, or improving documentation. Each individual improvement is small, but applied consistently by an entire team, the cumulative effect is powerful.\n\nThe Boy Scout Rule is the opposite of the \"not my problem\" mentality that allows technical debt to accumulate. It converts every code change from a potential debt-adding event into a potential debt-reducing event.\n\nThe key constraint: boy scout improvements must be small enough to not require separate review or testing. If the improvement needs its own PR, it's not a boy scout fix — it's a refactoring task.","url":"https://www.richardewing.io/glossary/boy-scout-rule"},{"@type":"DefinedTerm","termCode":"strangler-fig-pattern","name":"Strangler Fig Pattern","description":"The Strangler Fig Pattern is a migration strategy for incrementally replacing a legacy system with a new system. Named after the strangler fig tree that grows around an existing tree and eventually replaces it, this pattern avoids the risks of a \"big bang\" rewrite.\n\nThe approach: build new functionality alongside the old system, route traffic to the new system piece by piece, and gradually deprecate old components until the legacy system can be removed entirely.\n\nStep 1: Add a routing layer (facade) in front of the legacy system. Step 2: Build new components that implement specific functions. Step 3: Route specific requests to new components. Step 4: Repeat until all functionality is migrated. Step 5: Remove the legacy system.\n\nThe Strangler Fig Pattern is significantly safer than a full rewrite because: you can migrate incrementally and roll back individual changes, the legacy system continues to serve live traffic during migration, and you can validate new components against production data.","url":"https://www.richardewing.io/glossary/strangler-fig-pattern"},{"@type":"DefinedTerm","termCode":"static-code-analysis","name":"Static Code Analysis","description":"Static code analysis is the automated examination of source code without executing it. Static analysis tools scan code for potential bugs, security vulnerabilities, code smells, style violations, and complexity issues before the code is deployed.\n\nCommon static analysis tools include: SonarQube (multi-language, enterprise), ESLint (JavaScript/TypeScript), pylint/mypy (Python), RuboCop (Ruby), Checkstyle/SpotBugs (Java), and CodeClimate (multi-language SaaS).\n\nStatic analysis catches issues that are invisible during code review and common in human-written or AI-generated code: null pointer dereferences, SQL injection vulnerabilities, unused variables, unreachable code, type mismatches, and race conditions.\n\nIn the era of AI-generated code (vibe coding), static analysis is more important than ever. AI code generators produce code that often passes functional tests but contains subtle security, performance, or maintainability issues that only static analysis detects.","url":"https://www.richardewing.io/glossary/static-code-analysis"},{"@type":"DefinedTerm","termCode":"code-documentation","name":"Code Documentation","description":"Code documentation encompasses all written descriptions of what code does, why it exists, and how to use it. It includes inline comments, API documentation, README files, architecture decision records (ADRs), runbooks, and onboarding guides.\n\nGood documentation answers three questions: What does this code do? (API docs). Why does it do it this way? (Architecture Decision Records). How do I use it? (Tutorials and examples).\n\nDocumentation debt — the gap between how well-documented code should be and how well-documented it actually is — is one of the most common forms of technical debt. Unlike code debt, documentation debt is invisible to automated tools and only surfaces when new team members struggle to onboard or when institutional knowledge is lost due to turnover.\n\nThe cost of poor documentation: onboarding takes 2-4x longer, tribal knowledge creates bus factor risk, and teams make incorrect assumptions about code behavior because existing documentation is outdated or missing.","url":"https://www.richardewing.io/glossary/code-documentation"},{"@type":"DefinedTerm","termCode":"broken-windows-theory","name":"Broken Windows Theory (Software)","description":"The Broken Windows Theory in software development, drawn from urban criminology, states that visible signs of disorder (like poor code quality, ignored warnings, or failing tests) encourage further negligence. One broken window — one ignored linting error, one skipped test, one hacky workaround — makes the next broken window more acceptable.\n\nIn codebases, broken windows compound: a few ignored compiler warnings become hundreds. One untested module becomes several. One hardcoded configuration becomes a pattern. Once the team accepts \"that's just how it is,\" the standard permanently drops.\n\nThe practical implication: maintaining high standards requires constant vigilance. Allowing \"just this once\" exceptions creates a ratchet effect where quality only moves in one direction — down. This is why CI/CD pipelines should have zero-tolerance policies for critical issues: if warnings are allowed to accumulate, they will.","url":"https://www.richardewing.io/glossary/broken-windows-theory"},{"@type":"DefinedTerm","termCode":"feature-flags","name":"Feature Flags","description":"Feature flags (also called feature toggles, feature switches, or feature gates) are a software development technique that allows teams to enable or disable functionality without deploying new code. They decouple deployment from release, letting teams deploy code to production while keeping new features hidden until they're ready.\n\nFeature flags support several use cases: gradual rollout (enable for 5% of users, then 25%, then 100%), A/B testing (show different features to different user segments), kill switches (disable a broken feature without deploying), and trunk-based development (merge incomplete features that are flag-hidden).\n\nThe catch: feature flags are technical debt generators. Every flag adds conditional logic, increases testing complexity, and creates code paths that diverge. Old feature flags that are never cleaned up create \"flag debt\" — dead code wrapped in conditional logic that nobody is sure is safe to remove.\n\nBest practice: treat every feature flag as temporary debt. Set an expiration date when the flag is created and clean it up immediately after the flag decision is finalized.","url":"https://www.richardewing.io/glossary/feature-flags"},{"@type":"DefinedTerm","termCode":"code-duplication","name":"Code Duplication","description":"Code duplication occurs when identical or near-identical code blocks exist in multiple locations within a codebase. Also known as copy-paste programming or WET (Write Everything Twice) code, duplication is one of the most common code smells and a significant driver of maintenance costs.\n\nDuplicated code creates problems: when a bug is found in one copy, all copies need to be fixed separately. When behavior needs to change, every copy must be updated. When testing, each copy needs its own tests. The DRY principle (Don't Repeat Yourself) addresses this directly.\n\nTools like jscpd, PMD, and SonarQube can detect duplicated code blocks automatically. The ideal target is <5% duplication across the codebase. Above 10% duplication indicates systematic copy-paste patterns that need refactoring.\n\nNot all duplication is bad. Sometimes two pieces of code are similar by coincidence but serve different domains. Premature abstraction of such code creates worse problems than the original duplication.","url":"https://www.richardewing.io/glossary/code-duplication"},{"@type":"DefinedTerm","termCode":"transformer-architecture","name":"Transformer Architecture","description":"The Transformer architecture is the foundational neural network design behind all modern large language models including GPT-4, Claude, Gemini, and Llama. Introduced in the landmark 2017 paper \"Attention Is All You Need\" by Vaswani et al. at Google, transformers use self-attention mechanisms to process input sequences in parallel rather than sequentially.\n\nBefore transformers, recurrent neural networks (RNNs) processed text one word at a time. Transformers process entire sequences simultaneously, making them dramatically faster to train and better at capturing long-range dependencies in text.\n\nKey components include: multi-head self-attention (allowing the model to focus on different parts of the input simultaneously), positional encoding (preserving word order information), and feed-forward neural networks (processing each position independently).\n\nUnderstanding transformer architecture is essential for any leader making AI investment decisions because architecture determines cost structure. Transformer inference scales quadratically with input length — doubling your prompt length quadruples the compute cost.","url":"https://www.richardewing.io/glossary/transformer-architecture"},{"@type":"DefinedTerm","termCode":"fine-tuning","name":"Fine-Tuning","description":"Fine-tuning is the process of taking a pre-trained AI model and training it further on a smaller, domain-specific dataset to customize its behavior for a particular use case. It's the middle ground between using a general-purpose model as-is and training a custom model from scratch.\n\nFine-tuning modifies the model's weights to improve performance on specific tasks. For example, fine-tuning GPT-4 on legal documents produces a model that generates better legal text than the base model.\n\nThe economics of fine-tuning involve a significant upfront cost ($1K-$100K+ depending on dataset size and model) but can reduce ongoing inference costs by producing shorter, more accurate outputs that require fewer tokens and less post-processing.\n\nFine-tuning vs. RAG: Fine-tuning changes the model itself. RAG provides context without changing the model. Fine-tuning is better for style and format. RAG is better for factual accuracy. Many production systems use both.","url":"https://www.richardewing.io/glossary/fine-tuning"},{"@type":"DefinedTerm","termCode":"ai-inference","name":"AI Inference","description":"AI inference is the process of running a trained model to generate predictions or outputs from new input data. Unlike training (which is done once), inference happens every time a user interacts with an AI feature — every chatbot response, every code suggestion, every image generation.\n\nInference cost is the dominant variable cost in AI features. Training GPT-4 cost an estimated $100M, but inference costs across all users dwarf that number. Each inference call consumes GPU compute proportional to model size and input/output length.\n\nInference optimization is a critical engineering discipline: model quantization (reducing precision from 32-bit to 8-bit or 4-bit), batching (processing multiple requests simultaneously), caching (storing common responses), and distillation (creating smaller student models from larger teacher models).\n\nFor product leaders, inference cost is the unit cost that determines whether your AI feature has positive or negative unit economics. Richard Ewing's AUEB tool calculates Cost of Predictivity — the true per-query cost including inference, retrieval, verification, and error handling.","url":"https://www.richardewing.io/glossary/ai-inference"},{"@type":"DefinedTerm","termCode":"model-hallucination-rate","name":"Model Hallucination Rate","description":"Model hallucination rate is the percentage of AI outputs that contain factual errors, fabricated information, or ungrounded claims. It is the primary quality metric for any AI system that generates text, code, or structured data.\n\nHallucination rates vary significantly by model, task, and domain. Frontier models (GPT-4, Claude) hallucinate on 3-10% of factual queries. Smaller models can hallucinate on 15-30% of queries. Domain-specific queries without RAG can see hallucination rates of 20-40%.\n\nMeasuring hallucination rate requires ground truth data — verified correct answers against which model outputs can be evaluated. This is expensive to create but essential for production AI systems.\n\nRichard Ewing frames hallucination as an economic risk rather than an accuracy problem. Each hallucination has a cost: the cost of the incorrect output itself, the cost of detecting the error, the cost of correcting downstream decisions based on the error, and the potential liability cost if the error causes harm.","url":"https://www.richardewing.io/glossary/model-hallucination-rate"},{"@type":"DefinedTerm","termCode":"embedding","name":"Embedding (Vector Embedding)","description":"An embedding is a dense numerical representation of data (text, images, audio) as a vector of floating-point numbers. Embeddings capture semantic meaning — similar concepts have similar embeddings, enabling machines to understand relationships between data points.\n\nFor text, embedding models (like OpenAI's text-embedding-3, Cohere's embed, or open-source models like BAAI/bge) convert words, sentences, or documents into vectors of 256 to 3072 dimensions. \"Dog\" and \"puppy\" would have similar embeddings. \"Dog\" and \"quantum physics\" would have very different embeddings.\n\nEmbeddings power: semantic search (find documents by meaning not keywords), recommendation systems (find similar content), RAG pipelines (retrieve relevant context for AI), clustering (group similar items), and anomaly detection (find outliers).\n\nThe embedding model you choose directly affects your RAG pipeline's quality and cost. Higher-dimensional embeddings are more accurate but require more storage and compute. Most production systems use 768 or 1536 dimensions.","url":"https://www.richardewing.io/glossary/embedding"},{"@type":"DefinedTerm","termCode":"vector-database","name":"Vector Database","description":"A vector database is a specialized database designed to store, index, and query high-dimensional vector embeddings efficiently. Unlike traditional databases that search by exact matches or keywords, vector databases perform similarity search — finding the vectors closest to a query vector in high-dimensional space.\n\nPopular vector databases include: Pinecone (managed cloud-native), Weaviate (open-source), Qdrant (open-source, Rust), Chroma (lightweight, developer-friendly), Milvus (enterprise-scale), and pgvector (PostgreSQL extension).\n\nVector databases are the backbone of RAG pipelines. When a user asks a question, the question is embedded into a vector, the vector database finds the most similar document vectors, and those documents are provided as context to the LLM.\n\nKey performance metrics: query latency (milliseconds to return results), recall (% of truly relevant results returned), and throughput (queries per second at scale).","url":"https://www.richardewing.io/glossary/vector-database"},{"@type":"DefinedTerm","termCode":"ai-alignment","name":"AI Alignment","description":"AI alignment is the challenge of ensuring that artificial intelligence systems behave in ways that are consistent with human values and intentions. It encompasses both narrow alignment (making an AI follow specific instructions correctly) and broad alignment (ensuring AI systems don't cause unintended harm at scale).\n\nTechniques for alignment include: Reinforcement Learning from Human Feedback (RLHF), Constitutional AI (training AI to follow explicit ethical principles), red-teaming (adversarial testing to find unsafe behaviors), and guardrails (runtime constraints that prevent harmful outputs).\n\nFor enterprise applications, alignment is a governance concern. An AI system that is technically capable but misaligned with business objectives, ethical guidelines, or regulatory requirements is a liability. Misaligned AI can generate inappropriate content, make biased decisions, or take harmful autonomous actions.\n\nIn 2026, alignment is a board-level concern. The EU AI Act requires organizations to demonstrate that high-risk AI systems are aligned with safety requirements. SEC guidance requires disclosure of material AI risks, including alignment failures.","url":"https://www.richardewing.io/glossary/ai-alignment"},{"@type":"DefinedTerm","termCode":"machine-learning-ops","name":"MLOps (Machine Learning Operations)","description":"MLOps is the set of practices, tools, and cultural changes needed to deploy, monitor, and maintain machine learning models in production reliably. It applies DevOps principles to the ML lifecycle: data management, model training, deployment, monitoring, and retraining.\n\nMLOps addresses the unique challenges of ML in production: model drift (accuracy degrades as real-world data changes), data pipeline failures, reproducibility requirements, A/B testing for model versions, and cost management for GPU-intensive workloads.\n\nKey MLOps tools include: MLflow and Weights & Biases (experiment tracking), Kubeflow and SageMaker (training orchestration), Seldon and BentoML (model serving), Great Expectations (data quality), and Evidently AI (model monitoring).\n\nIn 2026, MLOps has expanded to include LLMOps — the specific practices for managing large language model applications, including prompt versioning, RAG pipeline management, hallucination monitoring, and inference cost optimization.","url":"https://www.richardewing.io/glossary/machine-learning-ops"},{"@type":"DefinedTerm","termCode":"ai-model-distillation","name":"Model Distillation","description":"Model distillation (also called knowledge distillation) is a technique for creating smaller, faster AI models by training them to mimic the behavior of larger, more capable models. The large model is called the \"teacher\" and the small model is called the \"student.\"\n\nThe student model learns to replicate the teacher's output distribution rather than learning from raw data. This is more efficient because the teacher's outputs contain \"dark knowledge\" — information about the relationships between classes and the confidence levels of predictions.\n\nDistillation is one of the most impactful cost optimization strategies for AI applications. A distilled model can achieve 90-95% of the teacher model's quality at 10-50x lower inference cost. For high-volume applications, this can mean the difference between positive and negative unit economics.\n\nExample: instead of calling GPT-4 ($0.03/query) for every customer support question, you can distill GPT-4's responses into a fine-tuned GPT-3.5 ($0.001/query) — a 30x cost reduction with minimal quality loss.","url":"https://www.richardewing.io/glossary/ai-model-distillation"},{"@type":"DefinedTerm","termCode":"ai-safety","name":"AI Safety","description":"AI safety is the field focused on ensuring artificial intelligence systems operate safely, reliably, and beneficially. It encompasses technical research (alignment, robustness, interpretability), policy frameworks (regulation, standards, certification), and organizational practices (audits, red-teaming, incident response).\n\nIn 2026, AI safety has moved from an academic concern to a regulatory requirement. The EU AI Act classifies AI systems by risk level and mandates safety assessments for high-risk applications. Company boards are expected to understand and govern AI safety at a strategic level.\n\nKey AI safety concerns for enterprise applications: bias and fairness (AI systems reproducing or amplifying societal biases), robustness (AI behaving unpredictably with novel inputs), transparency (inability to explain AI decisions), and security (adversarial attacks that manipulate AI behavior).\n\nPractical AI safety measures include: bias testing across demographic groups, adversarial testing (red-teaming), output monitoring and filtering, human-in-the-loop oversight, and incident response plans for AI failures.","url":"https://www.richardewing.io/glossary/ai-safety"},{"@type":"DefinedTerm","termCode":"natural-language-processing","name":"Natural Language Processing (NLP)","description":"Natural Language Processing is the branch of artificial intelligence focused on giving computers the ability to understand, interpret, and generate human language. NLP powers chatbots, search engines, translation services, sentiment analysis, content moderation, and text summarization.\n\nModern NLP is dominated by transformer-based language models. Before transformers (pre-2017), NLP relied on statistical methods, word embeddings (Word2Vec, GloVe), and recurrent neural networks. Post-transformers, pre-trained models like BERT (understanding) and GPT (generation) transformed the field.\n\nKey NLP tasks include: text classification (spam detection, sentiment analysis), named entity recognition (extracting people, companies, dates from text), machine translation, question answering, summarization, and text generation.\n\nFor business applications, NLP enables: automated customer support, document analysis, contract review, compliance monitoring, market intelligence, and content generation. The economics of NLP applications depend heavily on model choice — smaller task-specific models are dramatically cheaper than general-purpose LLMs.","url":"https://www.richardewing.io/glossary/natural-language-processing"},{"@type":"DefinedTerm","termCode":"computer-vision","name":"Computer Vision","description":"Computer vision is the field of artificial intelligence that enables computers to interpret and understand visual information from the real world — images, videos, and 3D models. It powers facial recognition, autonomous vehicles, medical imaging, manufacturing quality control, and visual search.\n\nKey computer vision tasks include: image classification (what is in this image?), object detection (where are the objects in this image?), semantic segmentation (pixel-level classification), pose estimation (where are the body parts?), and optical character recognition (extracting text from images).\n\nModern computer vision uses convolutional neural networks (CNNs) and increasingly transformer-based architectures (Vision Transformers, or ViTs). Multimodal models like GPT-4V combined language and vision capabilities in a single model.\n\nComputer vision applications in business include: quality inspection in manufacturing (detecting defects), retail analytics (customer behavior tracking), healthcare diagnostics (radiology, pathology), security and surveillance, and document processing (invoice extraction, ID verification).","url":"https://www.richardewing.io/glossary/computer-vision"},{"@type":"DefinedTerm","termCode":"generative-ai","name":"Generative AI","description":"Generative AI refers to artificial intelligence systems that create new content — text, images, audio, video, code, and 3D models — rather than simply analyzing or classifying existing content. It represents a fundamental shift in computing from analysis to creation.\n\nKey generative AI modalities: text generation (GPT-4, Claude, Gemini), image generation (DALL-E, Midjourney, Stable Diffusion), code generation (GitHub Copilot, Cursor), audio generation (ElevenLabs, Suno), video generation (Sora, Runway), and 3D model generation.\n\nThe economics of generative AI are fundamentally different from traditional software. Traditional software has near-zero marginal cost per user. Generative AI has significant marginal cost per query — every generated output costs compute. This is what Richard Ewing calls the Cost of Predictivity.\n\nIn 2026, generative AI has moved from novelty to production infrastructure. Companies are using it for customer support, content creation, code generation, design, data analysis, and decision support. The winners are organizations that understand the unit economics — cost per useful output — not just the technology.","url":"https://www.richardewing.io/glossary/generative-ai"},{"@type":"DefinedTerm","termCode":"ai-bias","name":"AI Bias","description":"AI bias occurs when artificial intelligence systems produce systematically unfair outcomes that favor or disadvantage certain groups. Bias can enter AI systems through training data (historical bias), algorithm design (measurement bias), and deployment context (evaluation bias).\n\nCommon types of AI bias: historical bias (training data reflects past discrimination), representation bias (certain groups are underrepresented in training data), measurement bias (the wrong thing is being measured), aggregation bias (a one-size-fits-all model ignores subgroup differences), and evaluation bias (testing doesn't include diverse populations).\n\nAI bias in enterprise applications creates legal and financial risk. Biased hiring algorithms face EEOC scrutiny. Biased lending models violate fair lending laws. Biased content moderation systems face regulatory action.\n\nDetecting and mitigating AI bias requires: diverse training data, fairness metrics (demographic parity, equalized odds), regular bias audits, diverse development teams, and continuous monitoring of production outputs across demographic groups.","url":"https://www.richardewing.io/glossary/ai-bias"},{"@type":"DefinedTerm","termCode":"multimodal-ai","name":"Multimodal AI","description":"Multimodal AI refers to artificial intelligence systems that can process, understand, and generate multiple types of data — text, images, audio, video, and structured data — within a single model. Unlike unimodal AI that handles only one data type, multimodal AI can reason across modalities.\n\nExamples include: GPT-4V (text + images), Gemini (text + images + audio + video), and Claude (text + images + documents). These models can describe images, answer questions about visual content, generate text from visual inputs, and combine reasoning across modalities.\n\nMultimodal AI enables new application categories: visual question answering, document understanding (extracting data from forms and receipts), video analysis, and cross-modal search (finding images by describing them in text).\n\nThe cost structure of multimodal AI is more complex than text-only AI. Image inputs cost 2-10x more than text inputs. Video analysis costs can be 100x+ more. Understanding these costs is critical for product planning.","url":"https://www.richardewing.io/glossary/multimodal-ai"},{"@type":"DefinedTerm","termCode":"ai-agent-framework","name":"AI Agent Framework","description":"An AI agent framework is a software library or platform that provides the infrastructure for building autonomous AI agents — systems that can plan, reason, use tools, and take actions independently. Popular frameworks include LangChain, LangGraph, CrewAI, AutoGen, and the Vercel AI SDK.\n\nAgent frameworks provide: tool calling (allowing AI to use APIs, databases, and code execution), memory management (maintaining context across interactions), planning and reasoning (multi-step task decomposition), error handling (recovering from failed tool calls), and orchestration (coordinating multiple agents).\n\nThe economics of AI agents are complex. Each agent step involves an LLM call (cost), a tool call (latency + cost), and state management (complexity). A multi-step agent workflow can cost 5-20x more than a single prompt-response interaction.\n\nFor enterprises, agent frameworks represent both opportunity (automating complex workflows) and risk (autonomous systems making decisions without human oversight). Richard Ewing's AI governance framework recommends tiered autonomy: fully automated for low-risk tasks, human-in-the-loop for medium-risk, and human-approval-required for high-risk.","url":"https://www.richardewing.io/glossary/ai-agent-framework"},{"@type":"DefinedTerm","termCode":"synthetic-data","name":"Synthetic Data","description":"Synthetic data is artificially generated data that mimics the statistical properties of real-world data without containing any actual real-world records. It's created using AI models, simulation engines, or mathematical algorithms to produce datasets for training, testing, and validation.\n\nUse cases include: training ML models when real data is scarce or expensive, privacy-preserving data sharing (no real PII), testing edge cases that rarely occur in production, augmenting imbalanced datasets, and compliance with data protection regulations (GDPR, CCPA).\n\nGartner predicts that by 2030, synthetic data will completely overshadow real data in AI model training. The economics are compelling: generating synthetic data can cost 10-100x less than collecting and labeling real data.\n\nRisks include: synthetic data that doesn't accurately represent real-world distributions, mode collapse (synthetic data lacking the diversity of real data), and overfit to synthetic patterns that don't exist in production.","url":"https://www.richardewing.io/glossary/synthetic-data"},{"@type":"DefinedTerm","termCode":"context-window","name":"Context Window","description":"A context window is the maximum amount of text (measured in tokens) that a language model can process in a single interaction. It determines how much information you can provide to the model and how long a response it can generate.\n\nContext window sizes have grown dramatically: GPT-3 had 4K tokens, GPT-4 offered 128K tokens, and Gemini 1.5 reached 1M tokens. Larger context windows enable processing entire documents, codebases, or conversation histories.\n\nHowever, larger context windows come with costs: inference cost scales with context length (quadratically for standard attention), model accuracy degrades in the \"middle\" of long contexts (the \"lost in the middle\" phenomenon), and latency increases with context size.\n\nToken is the unit of measurement: roughly 1 token ≈ 0.75 words in English. A 128K context window can hold approximately 96,000 words — roughly the length of a novel. But filling the full context window every query is expensive (tokens × price-per-token).","url":"https://www.richardewing.io/glossary/context-window"},{"@type":"DefinedTerm","termCode":"guardrails-ai","name":"AI Guardrails","description":"AI guardrails are runtime constraints, filters, and validation systems that prevent AI models from producing harmful, inappropriate, or incorrect outputs. They act as safety nets between the model's raw output and what the user sees.\n\nTypes of guardrails include: input validation (blocking malicious prompts), output filtering (removing harmful content), format validation (ensuring structured outputs match expected schemas), fact-checking (verifying claims against knowledge bases), PII detection (redacting personal information), and toxicity filtering.\n\nPopular guardrail frameworks include: Guardrails AI (open-source), NeMo Guardrails (NVIDIA), Llama Guard (Meta), and custom implementations using regex, classifiers, and secondary LLM calls.\n\nGuardrails add latency and cost to every AI interaction. Each validation check requires compute time and potentially additional API calls. The art is balancing safety with performance — applying strict guardrails to high-risk outputs and lighter guardrails to low-risk outputs.","url":"https://www.richardewing.io/glossary/guardrails-ai"},{"@type":"DefinedTerm","termCode":"ai-benchmarking","name":"AI Benchmarking","description":"AI benchmarking is the practice of evaluating AI model performance against standardized test sets and metrics. Benchmarks provide objective comparisons between models, versions, and approaches.\n\nPopular benchmarks include: MMLU (massive multitask language understanding), HellaSwag (commonsense reasoning), HumanEval (code generation), MT-Bench (multi-turn conversation quality), and domain-specific benchmarks for medical, legal, and financial applications.\n\nBenchmark limitations: models can be specifically optimized for benchmarks without improving real-world performance (\"teaching to the test\"), benchmarks may not reflect your specific use case, and benchmark datasets can leak into training data, inflating scores.\n\nFor enterprise AI evaluation, Richard Ewing recommends going beyond public benchmarks to create internal benchmarks that reflect your specific use cases, data distributions, and quality requirements. The AI Unit Economics Benchmark (AUEB) provides a framework for evaluating AI features on their economic impact, not just accuracy.","url":"https://www.richardewing.io/glossary/ai-benchmarking"},{"@type":"DefinedTerm","termCode":"customer-acquisition-cost","name":"Customer Acquisition Cost (CAC)","description":"Customer Acquisition Cost is the total cost of acquiring a new customer, including all marketing spend, sales team salaries, tools, and overhead divided by the number of new customers acquired in that period.\n\nCAC = (Total Sales & Marketing Spend) ÷ (New Customers Acquired)\n\nCAC varies dramatically by business model: B2C SaaS averages $50-200, B2B SMB averages $200-2,000, B2B enterprise averages $5,000-50,000+. The channel mix matters — organic/inbound CAC is typically 3-5x lower than paid/outbound CAC.\n\nCAC payback period — the number of months it takes for a customer's revenue to recoup their acquisition cost — is equally important. A $10,000 CAC with 12-month payback is healthy. A $10,000 CAC with 36-month payback is capital-intensive and risky.","url":"https://www.richardewing.io/glossary/customer-acquisition-cost"},{"@type":"DefinedTerm","termCode":"gross-margin","name":"Gross Margin","description":"Gross margin is the percentage of revenue remaining after subtracting the cost of goods sold (COGS). For SaaS companies, COGS includes: hosting and infrastructure costs, third-party software licenses, customer support costs, and professional services costs directly tied to revenue delivery.\n\nGross Margin = (Revenue - COGS) ÷ Revenue × 100\n\nHealthy SaaS gross margins range from 70-85%. Below 70% is concerning and impacts valuation multiples. Above 80% is excellent and commands premium valuations.\n\nAI-powered SaaS products face margin pressure because AI inference costs are variable COGS. Each AI query costs compute — unlike traditional software where serving an additional user has near-zero marginal cost. This is what Richard Ewing calls the Cost of Predictivity problem.\n\nFor product economists, gross margin is the most important financial metric after revenue growth. It determines how much money is available for R&D, sales, and profit — the engine of the business.","url":"https://www.richardewing.io/glossary/gross-margin"},{"@type":"DefinedTerm","termCode":"ltv-lifetime-value","name":"Lifetime Value (LTV)","description":"Lifetime Value is the total revenue a company expects to earn from a single customer over the entire duration of their relationship. It's the fundamental metric for understanding customer value and justifying acquisition spend.\n\nSimple LTV = Average Revenue Per Account (ARPA) × Average Customer Lifetime\n\nFor SaaS: LTV = ARPA ÷ Monthly Churn Rate (for monthly metrics) or ARPA × (1 ÷ Annual Churn Rate) for annual metrics.\n\nMore sophisticated LTV calculations account for expansion revenue, variable margins, and discount rates. A customer who starts at $500/month but expands to $2,000/month over 3 years has a very different LTV than one who stays at $500/month.\n\nThe LTV:CAC ratio is the most important unit economics metric in SaaS. A ratio of 3:1 means every dollar spent acquiring a customer generates $3 in lifetime revenue. Below 1:1 means you're losing money on every customer.","url":"https://www.richardewing.io/glossary/ltv-lifetime-value"},{"@type":"DefinedTerm","termCode":"runway-calculation","name":"Runway Calculation","description":"Runway is the number of months a startup can continue operating at its current spending rate before running out of cash. It's the most critical operational metric for any pre-profitable company.\n\nRunway = Cash Balance ÷ Monthly Net Burn Rate\n\nNet burn rate = Monthly expenses - Monthly revenue. A company with $3M cash and $250K net monthly burn has 12 months of runway.\n\nRunway planning requires scenario modeling: what happens if revenue grows 20% slower than planned? What if a key customer churns? What if the fundraising cycle takes 6 months longer than expected?\n\nRichard Ewing's rule of thumb: always add 6 months to your estimated time to next milestone. If you think you need 12 months of runway, you actually need 18. This buffer accounts for the inevitable surprises that consume cash faster than planned.","url":"https://www.richardewing.io/glossary/runway-calculation"},{"@type":"DefinedTerm","termCode":"annual-contract-value","name":"Annual Contract Value (ACV)","description":"Annual Contract Value is the average annualized revenue per customer contract. ACV = Total Contract Value ÷ Contract Length in Years. It normalizes contracts of different lengths for comparison.\n\nACV segments define go-to-market strategy: micro-SaaS ($0-1K ACV) uses product-led growth, SMB ($1K-25K ACV) uses inside sales, mid-market ($25K-100K ACV) uses field sales, and enterprise ($100K+ ACV) uses enterprise sales with longest cycles.\n\nACV distribution matters as much as average ACV. A company with $50K average ACV might have 80% of customers at $10K and 20% at $200K. The whale accounts drive revenue but create concentration risk.\n\nACV trends reveal pricing power. If ACV is increasing over time, your product commands higher prices — a sign of strong product-market fit. If ACV is decreasing, you may be competing on price (dangerous) or moving downmarket.","url":"https://www.richardewing.io/glossary/annual-contract-value"},{"@type":"DefinedTerm","termCode":"revenue-recognition","name":"Revenue Recognition (ASC 606)","description":"Revenue recognition is the accounting principle that determines when and how revenue is recorded on financial statements. For SaaS companies, ASC 606 (the US standard) requires that revenue be recognized when performance obligations are satisfied — typically ratably over the subscription period.\n\nKey implications for SaaS: a $120K annual contract signed in January is not $120K of January revenue. It's $10K/month recognized over 12 months. Billings (cash collected) and revenue (recognized) are different numbers.\n\nThis distinction matters for financial reporting, tax planning, and metrics. A company can have strong billings (lots of cash coming in from new annual contracts) but modest recognized revenue (because the revenue is spread over the contract term).\n\nFor product economists, revenue recognition also affects R&D capitalization. Under ASC 350-40, certain software development costs can be capitalized rather than expensed — but only costs incurred during the application development stage, not planning or maintenance.","url":"https://www.richardewing.io/glossary/revenue-recognition"},{"@type":"DefinedTerm","termCode":"net-dollar-retention","name":"Net Dollar Retention (NDR)","description":"Net Dollar Retention is the percentage change in recurring revenue from existing customers, including expansion, contraction, and churn. It measures whether your customer base is growing or shrinking independently of new customer acquisition.\n\nNDR = (Starting MRR + Expansion - Contraction - Churn) ÷ Starting MRR × 100\n\nNDR above 100% means your existing customers spend more over time — you grow even without new customers. NDR below 100% means your customer base is eroding.\n\nBenchmarks: below 90% is concerning, 90-100% is average, 100-120% is good, 120-140% is excellent, 140%+ is elite. The best SaaS companies (Snowflake 158%, Datadog 130%) prove that existing customers can be the primary growth engine.\n\nNDR is functionally identical to Net Revenue Retention (NRR). The terms are used interchangeably in the industry.","url":"https://www.richardewing.io/glossary/net-dollar-retention"},{"@type":"DefinedTerm","termCode":"magic-number-saas","name":"SaaS Magic Number","description":"The SaaS Magic Number measures sales efficiency — how much new ARR is generated for every dollar spent on sales and marketing. It answers the question: \"Is our sales investment paying off?\"\n\nMagic Number = (Current Quarter ARR - Previous Quarter ARR) ÷ Previous Quarter S&M Spend\n\nInterpretation: below 0.5 means sales spend is inefficient (tighten spend). 0.5-0.75 is acceptable but room for improvement. 0.75-1.0 is good. Above 1.0 is excellent (invest more aggressively).\n\nThe Magic Number is a lagging indicator — it reflects the efficiency of sales spend from the previous period. It works best for B2B SaaS with sales-led motions and should be combined with CAC payback period for a complete picture.","url":"https://www.richardewing.io/glossary/magic-number-saas"},{"@type":"DefinedTerm","termCode":"gross-revenue-retention","name":"Gross Revenue Retention (GRR)","description":"Gross Revenue Retention measures the percentage of recurring revenue retained from existing customers, excluding expansion revenue. Unlike NRR which includes upsells, GRR only measures the revenue you keep.\n\nGRR = (Starting MRR - Contraction - Churn) ÷ Starting MRR × 100\n\nGRR can never exceed 100%. It measures pure retention — how much of your existing revenue you keep without any upsells or cross-sells.\n\nBenchmarks: below 85% is poor, 85-90% is below average, 90-95% is good, 95-100% is excellent. Enterprise SaaS companies should target 95%+ GRR.\n\nGRR is a purer measure of product stickiness than NRR because it isn't masked by expansion revenue. A company can have 120% NRR but 80% GRR — meaning they grow through aggressive upselling despite significant churn. This pattern is unsustainable.","url":"https://www.richardewing.io/glossary/gross-revenue-retention"},{"@type":"DefinedTerm","termCode":"arpu-arpa","name":"ARPU / ARPA","description":"ARPU (Average Revenue Per User) and ARPA (Average Revenue Per Account) measure the average revenue generated per unit. ARPU tracks individual users; ARPA tracks company accounts. For B2B SaaS, ARPA is typically more relevant because one account may have many users.\n\nARPA = MRR ÷ Number of Active Accounts\n\nARPA trends reveal pricing power and product value. Increasing ARPA means customers are buying more (expansion) or you're moving upmarket. Decreasing ARPA may indicate competitive price pressure or moving downmarket.\n\nARPA segmentation is critical: break ARPA by customer segment (SMB, mid-market, enterprise), cohort (customers acquired this year vs. last year), and industry. This reveals which segments drive the most value.","url":"https://www.richardewing.io/glossary/arpu-arpa"},{"@type":"DefinedTerm","termCode":"payback-period","name":"CAC Payback Period","description":"CAC Payback Period is the number of months it takes for a customer's contribution margin to recoup their acquisition cost. It measures how quickly your sales and marketing investment pays for itself.\n\nCAC Payback = CAC ÷ (Monthly ARPA × Gross Margin %)\n\nBenchmarks: under 12 months is excellent, 12-18 months is good, 18-24 months is acceptable for enterprise, above 24 months is concerning, above 36 months requires reevaluation of unit economics.\n\nShorter payback means faster cash recycling — you get your money back sooner and can reinvest in acquiring more customers. Longer payback means you need more upfront capital to fund growth.\n\nPayback period is closely related to capital efficiency. Companies with short payback periods (under 12 months) can fund their own growth from customer revenue. Companies with long payback periods (24+ months) are dependent on external funding to grow.","url":"https://www.richardewing.io/glossary/payback-period"},{"@type":"DefinedTerm","termCode":"cohort-analysis","name":"Cohort Analysis","description":"Cohort analysis groups customers by a shared characteristic (usually their signup month) and tracks their behavior over time. It reveals patterns that aggregate metrics hide.\n\nThe most important SaaS cohort analysis is the revenue retention curve: for each monthly cohort, what percentage of their original revenue remains after 3 months, 6 months, 12 months, and 24 months?\n\nHealthy cohort curves flatten (customers who stay beyond month 6 tend to stay indefinitely). Unhealthy curves continue declining (customers never stop churning). The best cohort curves increase over time as expansion revenue exceeds churn — this is what negative net churn looks like at the cohort level.\n\nCohort analysis also reveals whether your product and acquisition are improving. If newer cohorts retain better than older cohorts, your product is getting stickier. If newer cohorts retain worse, something is degrading.","url":"https://www.richardewing.io/glossary/cohort-analysis"},{"@type":"DefinedTerm","termCode":"product-roadmap","name":"Product Roadmap","description":"A product roadmap is a strategic document that communicates the planned direction and priorities for a product over time. It aligns stakeholders around what will be built, why, and approximately when.\n\nEffective roadmaps are outcome-based rather than feature-based. Instead of \"Build chat feature in Q2,\" an outcome-based roadmap says \"Increase user engagement by 30% in Q2\" and lists the initiatives (including chat) that contribute to that outcome.\n\nRoadmap types include: timeline-based (features mapped to quarters), theme-based (grouped by strategic themes), now-next-later (prioritized buckets without dates), and Kanban-style (continuous flow).\n\nThe biggest roadmap mistake is treating it as a commitment rather than a plan. Markets change, customers surprise you, and engineering estimates are uncertain. Roadmaps should be updated quarterly based on new information.","url":"https://www.richardewing.io/glossary/product-roadmap"},{"@type":"DefinedTerm","termCode":"okrs","name":"OKRs (Objectives & Key Results)","description":"OKRs are a goal-setting framework that defines what you want to achieve (Objectives) and how you'll measure progress (Key Results). Popularized by Intel and Google, OKRs align teams around measurable outcomes.\n\nObjectives are qualitative, ambitious statements of what you want to achieve. Key Results are quantitative, measurable milestones that indicate progress toward the objective.\n\nExample: Objective: \"Become the go-to tool for CTOs evaluating technical debt.\" Key Results: (1) 5,000 PDI assessments completed, (2) 200 advisory conversations booked, (3) 50 enterprise sign-ups.\n\nOKRs work best when: 70% achievement is considered success (they should stretch), they're set quarterly, they're transparent across the organization, and achievement doesn't determine compensation (otherwise people sandbagging).","url":"https://www.richardewing.io/glossary/okrs"},{"@type":"DefinedTerm","termCode":"product-led-growth","name":"Product-Led Growth (PLG)","description":"Product-Led Growth is a business strategy where the product itself is the primary driver of customer acquisition, conversion, and expansion. Users discover, try, and adopt the product before engaging with sales.\n\nPLG companies include Slack, Dropbox, Figma, Canva, Notion, and Calendly. The model works when: the product delivers value quickly (time-to-value under 5 minutes), there's a natural viral loop (sharing features), and users can self-serve without sales assistance.\n\nPLG metrics differ from sales-led metrics: Product Qualified Leads (PQLs) replace Marketing Qualified Leads (MQLs), activation rate replaces demo-to-close rate, and time-to-value replaces sales cycle length.\n\nPLG reduces CAC by 3-5x compared to sales-led models but requires significant product investment. The product must be intuitive, self-explanatory, and deliver immediate value — which is harder to build than a feature-rich product sold through demos.","url":"https://www.richardewing.io/glossary/product-led-growth"},{"@type":"DefinedTerm","termCode":"feature-prioritization","name":"Feature Prioritization","description":"Feature prioritization is the process of deciding what to build next from a backlog of potential features. It is the most strategically important skill a product manager can develop because every feature you build is a feature you chose over alternatives.\n\nCommon prioritization frameworks include: RICE (Reach × Impact × Confidence ÷ Effort), ICE (Impact × Confidence × Ease), Moscow (Must-have, Should-have, Could-have, Won't-have), Kano Model (Must-Be, Performance, Delighter), and Value vs. Effort matrix.\n\nThe biggest prioritization mistake is feature democracy — letting the loudest stakeholder or largest customer dictate the roadmap. Prioritization should be driven by data: usage metrics, revenue impact, strategic alignment, and customer research.\n\nRichard Ewing's lens: every feature decision is a capital allocation decision. Building Feature A means not building Features B, C, and D. The opportunity cost must be measured in dollar terms, not just story points.","url":"https://www.richardewing.io/glossary/feature-prioritization"},{"@type":"DefinedTerm","termCode":"user-story","name":"User Story","description":"A user story is a short, simple description of a feature from the perspective of the user who needs it. The format is: \"As a [type of user], I want [some goal] so that [some reason].\"\n\nUser stories originated in Extreme Programming (XP) and became the standard unit of work in Agile development. They focus on user needs rather than technical specifications.\n\nGood user stories follow the INVEST criteria: Independent (can be developed separately), Negotiable (details can be discussed), Valuable (delivers user value), Estimable (team can estimate effort), Small (fits in a single sprint), and Testable (acceptance criteria are clear).\n\nUser stories are not requirements documents. They're conversation starters — placeholders for discussions between product, engineering, and design. The details emerge through collaboration, not through detailed written specifications.","url":"https://www.richardewing.io/glossary/user-story"},{"@type":"DefinedTerm","termCode":"minimum-viable-product","name":"Minimum Viable Product (MVP)","description":"A Minimum Viable Product is the simplest version of a product that delivers enough value to attract early customers and generate validated learning. Coined by Frank Robinson and popularized by Eric Ries in The Lean Startup, MVP is about learning, not building.\n\nThe MVP is not the smallest thing you can build — it's the smallest thing you can build that validates or invalidates your core hypothesis. A landing page that measures signup interest is an MVP. A fully functional product with no users is not.\n\nCommon MVP types: Concierge MVP (manually deliver the service), Wizard of Oz (human behind the curtain), landing page test (measure demand), single-feature product (one thing done well), and audience-first (build the audience before the product).\n\nThe biggest MVP mistake is building too much. Engineers and product people want to build complete solutions. An MVP is intentionally incomplete — it tests whether the problem exists and whether your solution approach resonates.","url":"https://www.richardewing.io/glossary/minimum-viable-product"},{"@type":"DefinedTerm","termCode":"product-analytics","name":"Product Analytics","description":"Product analytics is the practice of measuring, analyzing, and interpreting user behavior data to make better product decisions. It answers questions like: how do users use the product? Where do they get stuck? Which features drive retention? What predicts churn?\n\nKey product analytics tools include: Amplitude, Mixpanel, PostHog, Heap, and Google Analytics (for web). Each provides event tracking, funnel analysis, cohort analysis, retention curves, and user segmentation.\n\nCritical product metrics to track: activation rate (% of new users who reach the \"aha moment\"), feature adoption (% of users using specific features), retention (% returning after 1, 7, 30 days), engagement depth (frequency and duration), and conversion funnel (steps from signup to paid).\n\nProduct analytics is the empirical foundation of product management. Without it, product decisions are based on opinions, anecdotes, and the loudest voice. With it, decisions are based on evidence.","url":"https://www.richardewing.io/glossary/product-analytics"},{"@type":"DefinedTerm","termCode":"product-discovery","name":"Product Discovery","description":"Product discovery is the process of determining what to build before engineering starts building it. It answers: Is this a real problem? Does our solution address it? Can we build it? Will they pay for it?\n\nPopularized by Marty Cagan and Teresa Torres, product discovery uses rapid experimentation to validate product ideas before committing engineering resources.\n\nDiscovery techniques include: customer interviews, prototype testing, painted door tests (fake feature buttons that measure interest), Wizard of Oz tests, data analysis, and competitive research.\n\nThe Continuous Discovery framework (Teresa Torres) recommends weekly touchpoints with customers, opportunity solution trees for mapping hypotheses, and regular assumption testing to de-risk product decisions.","url":"https://www.richardewing.io/glossary/product-discovery"},{"@type":"DefinedTerm","termCode":"product-operations","name":"Product Operations","description":"Product Operations (Product Ops) is an emerging function that supports product management through data infrastructure, process optimization, and tooling. Product Ops handles the operational complexity that slows down product teams.\n\nProduct Ops responsibilities include: managing product analytics tools, creating dashboards and reports, standardizing product processes (how PRDs are written, how prioritization happens), managing the toolstack (Jira, Figma, analytics), and facilitating cross-functional coordination.\n\nProduct Ops is to Product Management what DevOps is to Engineering — an operational layer that removes friction and enables the core function to focus on their primary job.\n\nThe role emerged because product managers were spending 30-40% of their time on operational tasks (updating Jira, building reports, coordinating meetings) instead of customer research and strategic product decisions.","url":"https://www.richardewing.io/glossary/product-operations"},{"@type":"DefinedTerm","termCode":"a-b-testing","name":"A/B Testing","description":"A/B testing (split testing) is a method of comparing two versions of a product experience to determine which performs better. Users are randomly assigned to version A (control) or version B (variant), and a predefined metric is measured to determine the winner.\n\nA/B testing requires statistical rigor: sufficient sample size (use a sample size calculator), appropriate test duration (typically 1-4 weeks), clearly defined success metrics, and statistical significance (p < 0.05 is the standard threshold).\n\nCommon A/B testing mistakes: stopping tests too early, testing too many variants simultaneously, choosing vanity metrics as success criteria, not accounting for novelty effects, and running tests on segments too small for statistical significance.\n\nFor product decisions, A/B tests are the gold standard of evidence. But they're not always appropriate — features with low traffic can't reach significance, and strategic decisions shouldn't be A/B tested (you don't A/B test your company's mission).","url":"https://www.richardewing.io/glossary/a-b-testing"},{"@type":"DefinedTerm","termCode":"product-debt","name":"Product Debt","description":"Product debt is the accumulation of product decisions that deliver short-term value at the expense of long-term product health. Unlike technical debt (code quality issues), product debt is about features, design, and user experience.\n\nExamples include: features built for one large customer that don't serve the broader market, UX inconsistencies from rapid iteration without design system alignment, onboarding flows that were \"temporary\" three years ago, pricing tiers that no longer reflect the product's value structure, and half-finished features that were deprioritized.\n\nProduct debt is harder to measure than technical debt because it manifests as user confusion, low feature adoption, complex onboarding, and increasing support tickets — symptoms that have many possible causes.\n\nRichard Ewing's Feature Bloat Calculus provides a framework for quantifying product debt: for each feature, calculate maintenance cost vs. value contribution. Features where cost exceeds value are product debt.","url":"https://www.richardewing.io/glossary/product-debt"},{"@type":"DefinedTerm","termCode":"engineering-velocity","name":"Engineering Velocity","description":"Engineering velocity measures the rate at which an engineering team delivers value over time. It is commonly tracked as story points per sprint, but this metric is deeply flawed because story points measure estimated effort, not actual value delivered.\n\nTrue engineering velocity should measure: features shipped to customers, customer impact per engineering hour, revenue attributable to engineering output, and time from idea to production.\n\nThe distinction matters because teams can have high velocity (lots of story points completed) while producing little value (features nobody uses). Richard Ewing's APER (Annualized Productivity to Engineering Ratio) measures revenue per engineer, which is a more meaningful velocity metric.\n\nVelocity is influenced by: team size and composition, technical debt burden (maintenance steals from feature work), process overhead (meetings, reviews, deployments), tool quality, and organizational complexity.","url":"https://www.richardewing.io/glossary/engineering-velocity"},{"@type":"DefinedTerm","termCode":"engineering-manager","name":"Engineering Manager","description":"An Engineering Manager (EM) leads a team of software engineers, balancing people management, project delivery, and technical direction. The role exists at the intersection of technology and leadership.\n\nEM responsibilities include: hiring and onboarding engineers, performance management and career development, sprint planning and delivery coordination, technical decision-making, cross-functional collaboration with product and design, and managing up (reporting to directors/VPs).\n\nThe IC-to-EM transition is one of the hardest in tech. Skills that make someone a great individual contributor (deep focus, technical excellence, working alone) are different from skills that make a great manager (delegation, communication, empathy, organizational navigation).\n\nEM archetypes: Tech Lead Manager (still writes code, manages a small team), People Manager (focused on team health and career growth), and Delivery Manager (focused on execution and process).","url":"https://www.richardewing.io/glossary/engineering-manager"},{"@type":"DefinedTerm","termCode":"staff-engineer","name":"Staff Engineer","description":"A Staff Engineer is a senior individual contributor who operates at the organizational level — influencing technical direction, setting standards, and solving problems that span multiple teams. It's the first level of the IC (Individual Contributor) track above Senior Engineer.\n\nThe Staff Engineer role was formalized in Will Larson's book \"Staff Engineer: Leadership beyond the management track.\" Staff Engineers are expected to: set technical direction, mentor senior engineers, drive architecture decisions, represent engineering in cross-functional discussions, and write code on the most critical or ambiguous problems.\n\nStaff Engineer archetypes (Larson): Tech Lead (leads a specific team's technical direction), Architect (designs systems across teams), Solver (parachutes into critical problems), and Right Hand (extends a VP/CTO's technical bandwidth).\n\nCompensation ranges from $250K-500K+ total compensation at major tech companies, making it comparable to director-level management positions.","url":"https://www.richardewing.io/glossary/staff-engineer"},{"@type":"DefinedTerm","termCode":"team-topology","name":"Team Topologies","description":"Team Topologies is a framework by Matthew Skelton and Manuel Pais for organizing engineering teams based on how software flows through the organization. It defines four fundamental team types and three interaction modes.\n\nTeam types: Stream-Aligned (owns end-to-end delivery of a value stream), Platform (provides self-service infrastructure), Enabling (helps teams adopt new capabilities), and Complicated Subsystem (owns domain-specific complex code).\n\nInteraction modes: Collaboration (teams work together closely), X-as-a-Service (one team provides a service to others), and Facilitating (one team coaches another).\n\nThe key insight: organization structure directly shapes the software architecture (Conway's Law). If you want microservices, organize teams around services. If you organize around functions (backend team, frontend team), you'll build a monolith regardless of your architecture goals.","url":"https://www.richardewing.io/glossary/team-topology"},{"@type":"DefinedTerm","termCode":"blameless-postmortem","name":"Blameless Postmortem","description":"A blameless postmortem (also called blameless retrospective or incident review) is a structured analysis of a production incident that focuses on understanding what happened and preventing recurrence — not on assigning blame to individuals.\n\nThe blameless approach, championed by John Allspaw and Google's SRE team, recognizes that in complex systems, incidents are rarely caused by a single person's mistake. They result from systemic issues: missing safeguards, unclear procedures, insufficient monitoring, or process gaps.\n\nA good postmortem document includes: executive summary, timeline of events, root cause analysis, contributing factors, impact assessment, action items with owners and deadlines, and lessons learned.\n\nThe key cultural principle: if someone can cause a production outage with a single command, the problem is not the person — it's the system that allowed a single command to cause an outage.","url":"https://www.richardewing.io/glossary/blameless-postmortem"},{"@type":"DefinedTerm","termCode":"developer-experience","name":"Developer Experience (DevEx)","description":"Developer Experience encompasses the tools, workflows, processes, and environment that affect how productive and satisfied software developers are in their daily work. Good DevEx means developers spend most of their time on creative, high-value work. Bad DevEx means they fight tools, wait for builds, and navigate bureaucracy.\n\nKey DevEx dimensions (Nicole Forsgren's framework): feedback loops (how quickly developers get results from their actions), cognitive load (how much complexity developers must hold in their heads), and flow state (how often developers achieve deep, uninterrupted focus).\n\nDevEx investments include: fast CI/CD pipelines (<10 min builds), good documentation, reliable dev environments, automated testing, clear code review processes, and minimal context-switching.\n\nDevEx directly impacts retention. Developer Experience surveys consistently show that engineers leave companies primarily because of poor tools and processes, not because of compensation.","url":"https://www.richardewing.io/glossary/developer-experience"},{"@type":"DefinedTerm","termCode":"on-call-engineering","name":"On-Call Engineering","description":"On-call engineering is the practice of designating engineers to be available outside business hours to respond to production incidents. On-call rotations are essential for maintaining service reliability for products with uptime SLAs.\n\nHealthy on-call practices: rotations of 1-2 weeks, clear escalation paths, incident response runbooks, fair compensation (extra pay or comp time), reasonable page frequency (<2 per shift), and post-incident reviews to reduce future pages.\n\nOn-call burnout is a real and serious problem. Engineers who are paged frequently during off-hours experience: sleep disruption, anxiety, decreased daytime productivity, and increased turnover. Organizations that don't invest in reducing page frequency through reliability engineering create a vicious cycle of burnout and attrition.\n\nThe best on-call programs focus on reducing unnecessary pages: noisy alerts, false positives, and incidents that could be prevented by better architecture or monitoring. The goal is fewer, more meaningful pages.","url":"https://www.richardewing.io/glossary/on-call-engineering"},{"@type":"DefinedTerm","termCode":"engineering-levels","name":"Engineering Career Levels","description":"Engineering career levels define the expectations, scope, and compensation for engineers at different stages of their career. Common levels include: Junior/L3, Mid/L4, Senior/L5, Staff/L6, Principal/L7, and Distinguished/L8.\n\nLevel expectations typically vary across dimensions: technical complexity (harder problems at higher levels), scope of impact (team → org → company → industry), autonomy (needs guidance → sets direction), communication (presents to team → presents to executives → represents company externally), and mentorship (receives mentoring → mentors others → shapes culture).\n\nThe IC (Individual Contributor) and Management tracks should have comparable compensation and prestige. Organizations that only promote through management lose their best technical talent or create managers who'd rather be coding.\n\nCompensation ranges at major tech companies (2026): Junior $100-160K, Mid $150-250K, Senior $200-400K, Staff $300-500K, Principal $400-700K, Distinguished $600K-1M+ (total compensation including equity).","url":"https://www.richardewing.io/glossary/engineering-levels"},{"@type":"DefinedTerm","termCode":"tech-spec","name":"Technical Specification (Tech Spec / RFC)","description":"A technical specification (tech spec) or Request for Comments (RFC) is a document that describes the design of a system, feature, or architectural change before implementation begins. It's the engineering equivalent of \"measure twice, cut once.\"\n\nA good tech spec includes: problem statement, proposed solution, alternative approaches considered and why rejected, API design, data model changes, migration plan, rollback strategy, security considerations, performance expectations, and testing plan.\n\nTech specs serve multiple purposes: they force the author to think through edge cases before coding, they enable asynchronous review from senior engineers, they create documentation that outlives the implementation, and they prevent the \"build first, design later\" anti-pattern.\n\nGoogle, Netflix, and Uber require tech specs (or RFCs) for any change that affects multiple teams, introduces new dependencies, or modifies public APIs. The investment in upfront design pays back 5-10x in reduced rework.","url":"https://www.richardewing.io/glossary/tech-spec"},{"@type":"DefinedTerm","termCode":"hiring-technical","name":"Technical Hiring","description":"Technical hiring is the process of evaluating and selecting software engineers for open positions. It is one of the highest-leverage activities for engineering leaders because the quality of the team determines everything else.\n\nThe traditional technical interview (whiteboard/LeetCode algorithmic challenges) is increasingly criticized for: testing skills rarely used in daily work, disadvantaging non-traditional backgrounds, favoring candidates who memorize solutions, and consuming enormous engineering time (100+ hours per hire across interviewers).\n\nModern alternatives include: take-home projects (real-world problems), pair programming sessions, system design interviews (architecture discussions), behavioral interviews (past experience and decision-making), and trial days/weeks (paid working sessions).\n\nRichard Ewing's Audit Interview framework evaluates candidates on their ability to analyze real codebases and communicate findings — skills directly relevant to engineering leadership and product economics.","url":"https://www.richardewing.io/glossary/hiring-technical"},{"@type":"DefinedTerm","termCode":"fractional-cpo","name":"Fractional CPO","description":"A Fractional CPO (Chief Product Officer) is a part-time product executive who provides strategic product leadership to companies that need senior product guidance on a flexible basis.\n\nFractional CPOs help with: product strategy and vision, product team structure and hiring, product-market fit assessment, pricing strategy, roadmap prioritization, product economics analysis, and board-level product reporting.\n\nRichard Ewing operates as a Fractional Product Economist — a specialized form of fractional CPO focused on the financial dimensions of product decisions: R&D capital allocation, technical debt quantification, AI unit economics, and enterprise value impact.\n\nThe fractional product role is growing because product leadership requires deep expertise that most companies only need periodically — during fundraising, M&A, strategic pivots, or when scaling product teams.","url":"https://www.richardewing.io/glossary/fractional-cpo"},{"@type":"DefinedTerm","termCode":"technical-due-diligence","name":"Technical Due Diligence","description":"Technical due diligence is the systematic evaluation of a company's technology stack, engineering team, processes, and technical risks, typically performed during acquisitions, investments, or partnerships.\n\nA thorough technical due diligence covers: code quality and architecture assessment, technical debt quantification (using frameworks like the Product Debt Index), team capability and retention risk, scalability and performance limits, security vulnerabilities and compliance, IP ownership and licensing, AI/ML maturity and cost structure, and operational reliability.\n\nRichard Ewing's R&D Capital Audit is a specialized form of technical due diligence that focuses on the financial implications of technical decisions — treating engineering as a capital allocation problem.\n\nKey questions due diligence answers: Can this technology scale 10x? What is the real cost of technical debt? How dependent is the company on key engineers? Are the stated AI capabilities real or vaporware?","url":"https://www.richardewing.io/glossary/technical-due-diligence"},{"@type":"DefinedTerm","termCode":"board-reporting-tech","name":"Technology Board Reporting","description":"Technology board reporting is the practice of communicating engineering and technology status to a company's board of directors in financial and strategic terms they understand.\n\nEffective board reporting translates technical metrics into business language: instead of \"we reduced cyclomatic complexity by 15%,\" say \"we reduced the risk of production outages by 15%, protecting $2M in monthly revenue.\"\n\nRichard Ewing's recommended board-level technology metrics: Product Debt Index (overall tech health as a single number), Technical Insolvency Date (when debt becomes critical), Innovation Tax (% of R&D that's actually maintenance), APER (revenue per engineer), and AI Cost Ratio (AI spend as % of feature revenue).\n\nBoard members don't need to understand code. They need to understand: Is our technology an asset or a liability? Are we investing R&D dollars efficiently? What are our biggest technology risks?","url":"https://www.richardewing.io/glossary/board-reporting-tech"},{"@type":"DefinedTerm","termCode":"technology-governance","name":"Technology Governance","description":"Technology governance is the framework of policies, processes, and organizational structures that ensure technology investments align with business objectives and manage technology risks effectively.\n\nGovernance covers: technology investment decisions (build vs. buy, build vs. leverage AI), architectural standards (approved technologies, security requirements), vendor management (procurement, contract review), data governance (privacy, compliance, retention), AI governance (model approval, bias testing, monitoring), and risk management (disaster recovery, security, compliance).\n\nEffective technology governance balances control with velocity. Too much governance creates bureaucracy that slows innovation. Too little creates chaos, security risks, and shadow IT.\n\nThe rise of AI requires expanded governance: organizations need policies for AI model selection, data usage, output quality standards, and autonomous decision-making limits.","url":"https://www.richardewing.io/glossary/technology-governance"},{"@type":"DefinedTerm","termCode":"build-vs-buy","name":"Build vs. Buy Decision","description":"The build vs. buy decision is the strategic choice between developing software in-house or purchasing/licensing existing solutions. It's one of the most consequential technology decisions because it determines how engineering resources are allocated.\n\nBuild when: the capability is a core differentiator, no adequate solution exists on the market, the cost of customizing a bought solution exceeds building, or you need full control over the technology.\n\nBuy when: the capability is table-stakes (everyone needs it), excellent solutions exist, you lack the engineering capacity to build and maintain, or time-to-market matters more than customization.\n\nHidden costs of building: ongoing maintenance (20-30% of initial build cost per year), hiring and retaining talent, opportunity cost (engineers building commodity features instead of differentiators), and technical debt accumulation.\n\nHidden costs of buying: vendor lock-in, integration complexity, licensing costs that scale with usage, limited customization, and dependency on vendor's roadmap.","url":"https://www.richardewing.io/glossary/build-vs-buy"},{"@type":"DefinedTerm","termCode":"change-management","name":"Change Management","description":"Change management is the structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. In technology organizations, it applies to: tool migrations, process changes, organizational restructures, and technology platform transitions.\n\nPopular frameworks include: Kotter's 8-Step Process, ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement), Bridges' Transition Model, and Lewin's Change Management Model (Unfreeze, Change, Refreeze).\n\nMost technology change failures are not technical failures — they're adoption failures. The technology works, but people don't use it. Change management addresses the human side: communication, training, incentive alignment, and resistance management.\n\nRichard Ewing's observation from R&D Capital Audits: the biggest barrier to addressing technical debt is not technical — it's organizational resistance to change. Teams that have adapted to working around debt resist the disruption of fixing it.","url":"https://www.richardewing.io/glossary/change-management"},{"@type":"DefinedTerm","termCode":"vendor-lock-in","name":"Vendor Lock-In","description":"Vendor lock-in occurs when switching from one technology vendor to another becomes prohibitively expensive due to technical dependencies, data portability issues, or contractual constraints. It creates a power imbalance where the vendor can increase prices or reduce service quality knowing the customer can't easily leave.\n\nCommon lock-in mechanisms: proprietary APIs (custom integrations that work only with one vendor), data formats (data stored in non-standard formats), staff expertise (team only knows one platform), contractual terms (long-term commitments with penalties), and workflow dependency (core business processes built on vendor tools).\n\nSwitching costs compound over time. The longer you use a vendor, the more integrations you build, the more data you accumulate, and the more institutional knowledge becomes vendor-specific. This is why vendor selection decisions should include exit planning from day one.\n\nCloud vendor lock-in is a major concern in 2026: organizations that build heavily on AWS-specific services (Lambda, DynamoDB, SQS) face 6-12 month migration projects to switch clouds.","url":"https://www.richardewing.io/glossary/vendor-lock-in"},{"@type":"DefinedTerm","termCode":"product-debt-index","name":"Product Debt Index (PDI)","description":"The Product Debt Index is Richard Ewing's proprietary diagnostic score that quantifies an organization's total technical debt in dollar terms. Unlike traditional technical debt metrics that use abstract units like story points, the PDI translates debt into financial language that CFOs and boards can act on.\n\nThe PDI considers: maintenance-to-innovation ratio, dependency health, code coverage, deployment frequency, incident rate, team velocity trends, and infrastructure costs. Each dimension is scored and weighted to produce a single composite score from 0 (debt-free) to 100 (technical insolvency).\n\nPDI score ranges: 0-20 (Healthy — debt is managed and minimal), 20-40 (Moderate — debt is accumulating but manageable), 40-60 (Critical — debt is impacting velocity and requires immediate intervention), 60-80 (Severe — approaching Technical Insolvency Date), 80-100 (Terminal — engineering capacity is consumed by maintenance).\n\nThe free PDI calculator at richardewing.io/tools/pdi provides an automated assessment based on organizational inputs.","url":"https://www.richardewing.io/glossary/product-debt-index"},{"@type":"DefinedTerm","termCode":"ev-se-framework","name":"Enterprise Value Scenario Engine (EV-SE)","description":"The Enterprise Value Scenario Engine is Richard Ewing's tool for modeling how technical decisions affect company valuation. It connects engineering metrics to the financial multipliers that determine enterprise value.\n\nThe EV-SE models the relationship between: ARR multiples and technical health, gross margin impact of AI costs, revenue retention and technical debt, engineering efficiency and EBITDA, and technical risk factors on deal pricing.\n\nThe tool provides scenario analysis: \"If we reduce technical debt by 30%, what happens to our valuation multiple? If AI costs grow 15% per quarter, what's the impact on gross margins by Year 3?\"\n\nFor PE/VC firms, the EV-SE quantifies the post-acquisition technology investment required and models the return on that investment. It answers: \"What's the true technology cost of this acquisition beyond the purchase price?\"","url":"https://www.richardewing.io/glossary/ev-se-framework"},{"@type":"DefinedTerm","termCode":"aueb-framework","name":"AI Unit Economics Benchmark (AUEB)","description":"The AI Unit Economics Benchmark is Richard Ewing's framework for measuring the true cost and value of AI features. It goes beyond simple inference costs to calculate the full economic picture: cost per useful output, hallucination cost, verification cost, and net value created.\n\nThe AUEB calculates: Cost of Predictivity (total cost per accurate AI output including failed attempts), Hallucination Cost (economic impact of incorrect outputs), Verification Overhead (human review time required), Net AI Value (value created minus total costs), and Break-Even Volume (queries needed for AI feature to be profitable).\n\nThe AUEB reveals whether AI features have positive or negative unit economics. A chatbot that costs $0.10 per query but only generates $0.05 in value has negative unit economics and will destroy margin as it scales.\n\nThe free AUEB tool at richardewing.io/tools/aueb provides automated AI unit economics analysis.","url":"https://www.richardewing.io/glossary/aueb-framework"},{"@type":"DefinedTerm","termCode":"aper-metric","name":"APER (Annualized Productivity to Engineering Ratio)","description":"APER measures revenue generated per engineer, annualized. It is Richard Ewing's recommended alternative to velocity metrics like story points, which measure effort rather than value.\n\nAPER = Annual Recurring Revenue ÷ Total Engineering Headcount\n\nBenchmarks: early-stage startups typically have APER of $100-200K. Growth-stage companies target $200-400K. Mature SaaS companies achieve $400-800K. The best-in-class (Canva, Zoom at peak) exceed $1M per engineer.\n\nAPER trends are more important than absolute values. Increasing APER means engineering is becoming more efficient. Declining APER means each new hire produces diminishing returns — a sign of organizational complexity, technical debt, or poor product-market fit.\n\nAPER should be segmented: product engineering vs. platform engineering vs. infrastructure. Product engineering should have the highest APER because they directly build revenue-generating features.","url":"https://www.richardewing.io/glossary/aper-metric"},{"@type":"DefinedTerm","termCode":"r-and-d-capital-audit","name":"R&D Capital Audit","description":"The R&D Capital Audit is Richard Ewing's signature service — a forensic examination of how an organization allocates its engineering and product development resources. It treats R&D spending as a capital allocation problem rather than a cost center.\n\nThe audit process: stakeholder interviews (CEO, CTO, VPs, individual contributors), codebase analysis (static analysis, architecture review, dependency audit), financial modeling (PDI calculation, Innovation Tax measurement, TID projection), team assessment (APER, organizational design, process efficiency), and deliverable creation (board-ready report with actionable recommendations).\n\nKey questions the audit answers: How much of our R&D spend is actually producing innovation? What is our Technical Insolvency Date? Where are we wasting engineering resources? How do our metrics compare to industry benchmarks? What should we invest in to maximize engineering ROI?\n\nA typical audit engagement is $7,500 for a standard assessment or $15,000+ for comprehensive engagements, and delivers findings within 2 weeks.","url":"https://www.richardewing.io/glossary/r-and-d-capital-audit"},{"@type":"DefinedTerm","termCode":"cloud-architecture","name":"Cloud Architecture","description":"Cloud architecture is the design of software systems to run on cloud computing platforms (AWS, Azure, GCP). It encompasses compute, storage, networking, and services organized to meet scalability, reliability, and cost requirements.\n\nKey principles: design for failure (assume any component can break), horizontal scaling (add more instances, not bigger instances), loose coupling (services communicate via APIs), statelessness (application state stored externally), and observability (every component emits metrics, logs, and traces).\n\nArchitecture patterns: monolith (single deployable unit), microservices (independently deployable services), serverless (event-driven functions), and hybrid (combining patterns based on use case).\n\nCloud costs are the fastest-growing line item for most tech companies, growing 20-30% annually. Architecture directly determines cost structure: poorly architected systems can cost 3-10x more than well-architected ones.","url":"https://www.richardewing.io/glossary/cloud-architecture"},{"@type":"DefinedTerm","termCode":"kubernetes","name":"Kubernetes (K8s)","description":"Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Originally developed by Google and now maintained by the CNCF, it has become the standard platform for running production workloads.\n\nKey concepts: Pods (smallest deployable unit), Deployments (declarative updates), Services (network access to pods), Ingress (HTTP routing), ConfigMaps/Secrets (configuration), and Namespaces (resource isolation).\n\nKubernetes provides: automatic scaling (add/remove instances based on load), self-healing (restart failed containers), rolling updates (zero-downtime deployments), and service discovery (automatic DNS and load balancing).\n\nThe catch: Kubernetes is complex. Running a production Kubernetes cluster requires expertise in networking, security, monitoring, and resource management. For teams under 20 engineers, managed Kubernetes services (EKS, GKE, AKS) or simpler alternatives (Fly.io, Railway, Render) may be more appropriate.","url":"https://www.richardewing.io/glossary/kubernetes"},{"@type":"DefinedTerm","termCode":"serverless","name":"Serverless Computing","description":"Serverless computing is a cloud execution model where the cloud provider manages the server infrastructure and automatically allocates compute resources on demand. You write functions, the cloud runs them, and you pay only for actual execution time.\n\nPopular serverless platforms: AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers, and Vercel Edge Functions.\n\nServerless advantages: zero infrastructure management, automatic scaling (from zero to millions of requests), pay-per-use pricing (no idle costs), and faster time-to-market.\n\nServerless limitations: cold start latency (first invocation after idle period is slow), 15-minute execution limits, statelessness (no persistent connections), vendor lock-in (Lambda code doesn't run on Azure Functions), debugging complexity, and cost unpredictability at high volume (can be more expensive than reserved instances above certain traffic levels).","url":"https://www.richardewing.io/glossary/serverless"},{"@type":"DefinedTerm","termCode":"infrastructure-as-code","name":"Infrastructure as Code (IaC)","description":"Infrastructure as Code is the practice of managing and provisioning infrastructure through machine-readable configuration files rather than manual processes. It enables version control, review, testing, and automation of infrastructure changes.\n\nPopular IaC tools: Terraform (multi-cloud, declarative), Pulumi (multi-language, imperative), AWS CloudFormation (AWS-only), Ansible (configuration management), and CDK (AWS, programming languages).\n\nIaC provides: repeatability (same infrastructure in dev/staging/prod), version control (git history of infrastructure changes), review process (PRs for infrastructure changes), disaster recovery (recreate infrastructure from code), and compliance (infrastructure changes are auditable).\n\nWithout IaC, infrastructure becomes \"snowflake\" — unique, manually configured systems that nobody fully understands. Snowflake infrastructure is fragile, unreproducible, and creates key-person dependency on the engineer who set it up.","url":"https://www.richardewing.io/glossary/infrastructure-as-code"},{"@type":"DefinedTerm","termCode":"observability","name":"Observability","description":"Observability is the ability to understand the internal state of a system by examining its outputs. The three pillars of observability are: metrics (quantitative measurements over time), logs (discrete event records), and traces (request flow through distributed systems).\n\nPopular observability tools: Datadog (comprehensive platform), Grafana + Prometheus (open-source metrics), New Relic (APM), Honeycomb (high-cardinality traces), PagerDuty (alerting), and Sentry (error tracking).\n\nObservability differs from monitoring: monitoring tells you when something is broken (alert when CPU > 90%). Observability helps you understand why it broke (trace the request that caused the spike, examine the query that took 30 seconds, identify the deployment that introduced the regression).\n\nCost of observability: observability tools are among the most expensive line items in cloud infrastructure. Datadog or New Relic costs can reach $10K-100K+/month at scale. Managing observability costs requires: log sampling, metric aggregation, and retention policies.","url":"https://www.richardewing.io/glossary/observability"},{"@type":"DefinedTerm","termCode":"site-reliability-engineering","name":"Site Reliability Engineering (SRE)","description":"Site Reliability Engineering is a discipline that applies software engineering practices to infrastructure and operations problems. Developed at Google, SRE treats operations as a software problem — automating manual tasks, building self-healing systems, and managing reliability through error budgets.\n\nKey SRE concepts: SLIs (Service Level Indicators — metrics that measure service quality), SLOs (Service Level Objectives — target values for SLIs), SLAs (Service Level Agreements — contractual commitments to customers), and Error Budgets (the acceptable amount of unreliability, calculated as 1 - SLO).\n\nThe error budget concept is transformative: if your SLO is 99.9% uptime, your error budget is 0.1% (8.7 hours/year of acceptable downtime). When you have error budget remaining, you can deploy risky changes quickly. When your error budget is exhausted, you focus on reliability over features.\n\nSRE team sizes vary: small companies might have 1-2 SREs, while Google has thousands. The general rule is 1 SRE per 5-10 application engineers.","url":"https://www.richardewing.io/glossary/site-reliability-engineering"},{"@type":"DefinedTerm","termCode":"edge-computing","name":"Edge Computing","description":"Edge computing processes data near the source of data generation rather than in a centralized cloud data center. By moving computation closer to users, edge computing reduces latency, bandwidth costs, and privacy exposure.\n\nEdge computing tiers: device edge (processing on IoT devices), access edge (processing at cell towers or ISP points of presence), and cloud edge (CDN nodes and regional data centers like Cloudflare Workers).\n\nUse cases: real-time AI inference (autonomous vehicles, industrial IoT), content delivery (video streaming, gaming), privacy-sensitive processing (data stays local), and latency-critical applications (trading, real-time collaboration).\n\nFor web applications, edge computing through platforms like Cloudflare Workers, Vercel Edge Functions, and Deno Deploy enables server-side rendering and API responses in milliseconds by running code in 200+ locations worldwide.","url":"https://www.richardewing.io/glossary/edge-computing"},{"@type":"DefinedTerm","termCode":"data-warehouse","name":"Data Warehouse","description":"A data warehouse is a centralized repository of structured, historical data optimized for analytical queries and reporting. Unlike operational databases (optimized for fast reads/writes), data warehouses are optimized for complex queries across large datasets.\n\nPopular data warehouses: Snowflake (cloud-native, usage-based pricing), BigQuery (Google, serverless), Redshift (AWS), and Databricks Lakehouse (unified analytics).\n\nData warehouse architecture: Extract data from source systems (databases, APIs, events) → Transform data (clean, normalize, enrich) → Load into the warehouse (the ETL or ELT pipeline). Modern approaches prefer ELT (load raw data first, transform in the warehouse).\n\nFor product teams, data warehouses enable: cohort analysis, funnel analytics, revenue attribution, feature usage tracking, and customer health scoring across all data sources.","url":"https://www.richardewing.io/glossary/data-warehouse"},{"@type":"DefinedTerm","termCode":"data-pipeline","name":"Data Pipeline","description":"A data pipeline is a series of automated steps that extract data from source systems, transform it for analysis, and load it into a destination (data warehouse, data lake, or analytics tool). Also known as ETL (Extract, Transform, Load) or ELT (Extract, Load, Transform).\n\nCommon pipeline tools: dbt (transformation), Fivetran/Airbyte (extraction), Apache Airflow (orchestration), and Dagster (modern orchestration).\n\nPipeline reliability is critical: a broken pipeline means stale data, which means wrong decisions. Production pipelines need monitoring, alerting, data quality checks, and automated recovery.\n\nData pipeline debt is a lesser-known form of technical debt. Poorly maintained pipelines accumulate: undocumented transformations, hardcoded business logic, orphaned tables, and performance bottlenecks that slow down analytics.","url":"https://www.richardewing.io/glossary/data-pipeline"},{"@type":"DefinedTerm","termCode":"business-intelligence","name":"Business Intelligence (BI)","description":"Business Intelligence is the technologies, practices, and strategies for collecting, integrating, analyzing, and presenting business data. BI tools turn raw data into actionable insights through dashboards, reports, and visualizations.\n\nPopular BI tools: Tableau (powerful visualization), Metabase (open-source, developer-friendly), Looker (Google, semantic layer), Power BI (Microsoft, enterprise), and Superset (Apache, open-source).\n\nBI layers: data collection → data warehouse → transformation (dbt) → semantic layer (metrics definitions) → visualization (dashboards) → action (decisions).\n\nThe biggest BI challenge is not technical — it's organizational. Creating dashboards is easy. Getting people to look at them, trust them, and change behavior based on them is hard. This requires: data literacy training, metric standardization, and executive sponsorship.","url":"https://www.richardewing.io/glossary/business-intelligence"},{"@type":"DefinedTerm","termCode":"metrics-layer","name":"Metrics Layer (Semantic Layer)","description":"A metrics layer (or semantic layer) is a centralized definition of business metrics that ensures everyone in the organization uses the same calculations. It's the \"single source of truth\" for metric definitions.\n\nWithout a metrics layer: the marketing team calculates \"active users\" differently from the product team. The finance team's revenue numbers don't match the dashboard. Every report requires re-deriving metrics from raw data.\n\nWith a metrics layer: \"active users\" is defined once, with specific criteria (e.g., \"logged in and performed at least one core action in the last 30 days\"). Every dashboard, report, and analysis uses the same definition.\n\nTools: dbt metrics, Cube.js, MAN, Looker's LookML, and custom SQL views in the data warehouse. The metrics layer sits between the data warehouse and BI tools, providing consistent metric calculations.","url":"https://www.richardewing.io/glossary/metrics-layer"},{"@type":"DefinedTerm","termCode":"data-governance","name":"Data Governance","description":"Data governance is the framework of policies, processes, and standards for managing data assets across an organization. It covers data quality, data access, data privacy, data lifecycle, and data compliance.\n\nKey governance components: data catalog (inventory of all data assets), data lineage (how data flows and transforms), access controls (who can see what), quality checks (automated validation), retention policies (how long data is kept), and privacy compliance (GDPR, CCPA, HIPAA).\n\nData governance is increasingly important because: regulatory requirements are expanding (GDPR fines up to 4% of global revenue), AI systems require high-quality training data, data breaches are expensive ($4.5M average cost in 2024), and poor data quality leads to wrong decisions.\n\nFor product teams, governance means: knowing what data you collect, why you collect it, who has access, how long you keep it, and how you protect it.","url":"https://www.richardewing.io/glossary/data-governance"},{"@type":"DefinedTerm","termCode":"zero-trust-security","name":"Zero Trust Security","description":"Zero Trust is a security framework based on the principle \"never trust, always verify.\" Unlike traditional perimeter security (castle-and-moat model), Zero Trust assumes that threats exist both outside and inside the network.\n\nZero Trust principles: verify every user and device regardless of location, enforce least-privilege access, assume breach (design systems that limit blast radius), and validate continuously (not just at login).\n\nImplementation components: identity verification (SSO, MFA), micro-segmentation (isolate network segments), device health checks, encryption in transit and at rest, and continuous monitoring.\n\nZero Trust has become the default security architecture because: remote work dissolved the network perimeter, cloud services exist outside corporate networks, and insider threats account for 25-30% of security incidents.","url":"https://www.richardewing.io/glossary/zero-trust-security"},{"@type":"DefinedTerm","termCode":"soc2-compliance","name":"SOC 2 Compliance","description":"SOC 2 is an auditing standard developed by the AICPA that verifies a service organization's controls for security, availability, processing integrity, confidentiality, and privacy. It's the most common security certification required by enterprise SaaS buyers.\n\nSOC 2 Types: Type I (verifies that controls are designed properly at a point in time) and Type II (verifies that controls operate effectively over a period of time, typically 6-12 months). Type II is more rigorous and more valuable.\n\nThe five Trust Service Criteria: Security (protection against unauthorized access), Availability (system uptime and accessibility), Processing Integrity (accurate and timely data processing), Confidentiality (protection of sensitive information), and Privacy (proper handling of personal data).\n\nSOC 2 audit cost: $20,000-100,000+ depending on company size and scope. Ongoing compliance costs include: tool licenses, process maintenance, and annual re-audits.","url":"https://www.richardewing.io/glossary/soc2-compliance"},{"@type":"DefinedTerm","termCode":"security-vulnerability","name":"Security Vulnerability Management","description":"Security vulnerability management is the continuous process of identifying, classifying, prioritizing, remediating, and mitigating security vulnerabilities in software and infrastructure.\n\nVulnerability sources: known CVEs (Common Vulnerabilities and Exposures) in dependencies, code-level vulnerabilities (injection, XSS, CSRF), infrastructure misconfigurations (open ports, default passwords), and zero-day vulnerabilities (unknown until exploited).\n\nManagement lifecycle: Discovery (scan and assess) → Prioritization (severity, exploitability, exposure) → Remediation (patch, update, or mitigate) → Verification (confirm fix) → Reporting (track metrics over time).\n\nKey metrics: Time to Detect (days from vulnerability publication to discovery in your systems), Time to Remediate (days from discovery to fix), Vulnerability Density (vulnerabilities per 1000 lines of code), and Critical Open Count (number of unresolved critical vulnerabilities).","url":"https://www.richardewing.io/glossary/security-vulnerability"},{"@type":"DefinedTerm","termCode":"gdpr-compliance","name":"GDPR Compliance","description":"The General Data Protection Regulation (GDPR) is the EU's comprehensive data privacy law that governs how organizations collect, store, process, and share personal data of EU residents. It applies to any organization worldwide that processes EU residents' data.\n\nKey GDPR requirements: lawful basis for processing (consent, legitimate interest, contract), data minimization (collect only what you need), right to access (users can request their data), right to deletion (users can request erasure), data portability (users can export their data), breach notification (72-hour reporting requirement), and Data Protection Impact Assessments (DPIAs for high-risk processing).\n\nGDPR penalties: up to €20 million or 4% of annual global revenue, whichever is higher. Major fines include: Meta (€1.2B), Amazon (€746M), and Google (€150M).\n\nFor product teams, GDPR affects: data collection (consent flows), analytics (anonymization requirements), AI training (data usage restrictions), and feature design (privacy by design principle).","url":"https://www.richardewing.io/glossary/gdpr-compliance"},{"@type":"DefinedTerm","termCode":"penetration-testing","name":"Penetration Testing","description":"Penetration testing (pen testing) is the practice of simulating cyberattacks against your systems to identify exploitable vulnerabilities before real attackers do. Unlike vulnerability scanning (automated tool-based), pen testing involves skilled security professionals actively attempting to breach your defenses.\n\nPen test types: black box (tester has no prior knowledge), gray box (tester has partial knowledge like API docs), and white box (tester has full knowledge including source code). White box testing is most thorough but takes longer.\n\nCommon findings: injection vulnerabilities (SQL, command, LDAP), authentication bypass, API security gaps (rate limiting, authorization), data exposure through verbose error messages, and privilege escalation.\n\nPen testing frequency: annually at minimum, plus after major releases or infrastructure changes. Cost ranges from $5,000-50,000+ depending on scope and depth.","url":"https://www.richardewing.io/glossary/penetration-testing"},{"@type":"DefinedTerm","termCode":"venture-capital-stages","name":"Venture Capital Funding Stages","description":"Venture capital funding follows a structured progression of stages, each corresponding to a company's maturity, risk level, and capital needs.\n\nPre-Seed ($50K-500K): Idea stage. Funding from founders, friends/family, and angels. Used to validate the concept.\n\nSeed ($500K-3M): Early product. Funding from angel investors and seed-stage VCs. Used to build MVP and find initial customers.\n\nSeries A ($3M-20M): PMF achieved. Led by institutional VCs. Used to scale the business model and hire key roles.\n\nSeries B ($15M-50M): Proven model. Led by growth-stage VCs. Used to scale aggressively into new markets and segments.\n\nSeries C+ ($50M-200M+): Market leader. Led by growth equity and crossover funds. Used for international expansion, acquisitions, or pre-IPO preparation.\n\nEach stage has different investor expectations, valuation norms, and dilution levels. Founders typically retain 20-30% by Series B.","url":"https://www.richardewing.io/glossary/venture-capital-stages"},{"@type":"DefinedTerm","termCode":"cap-table","name":"Cap Table (Capitalization Table)","description":"A capitalization table is a spreadsheet or database that shows the ownership structure of a company: who owns what percentage, how many shares, what type (common, preferred), and the resulting dilution from each funding round.\n\nCap table components: founders' shares (common stock), employee option pool (typically 10-20% reserved), investor shares (preferred stock with special rights), convertible notes/SAFEs (convert to equity on trigger events), and warrants.\n\nKey cap table concepts: fully diluted ownership (including all options, warrants, and convertibles), liquidation preferences (preferred shareholders get paid first in an exit), anti-dilution provisions (protect early investors from down rounds), and option pool shuffle (pre-money vs. post-money pool creation).\n\nCap table management tools: Carta, Pulley, and Shareworks automate cap table tracking, option grant management, and 409A valuations.","url":"https://www.richardewing.io/glossary/cap-table"},{"@type":"DefinedTerm","termCode":"total-addressable-market","name":"Total Addressable Market (TAM)","description":"Total Addressable Market is the total revenue opportunity available for a product or service if it achieved 100% market share. TAM is used by investors and strategists to evaluate the scale of opportunity.\n\nTAM can be calculated top-down (use industry research: \"The global SaaS market is $200B, our segment is 5% = $10B TAM\") or bottom-up (count potential customers × average revenue per customer).\n\nTAM, SAM, SOM: TAM (total market), SAM (Serviceable Addressable Market — the portion you can reach), SOM (Serviceable Obtainable Market — what you can realistically capture in 3-5 years). Investors care most about SAM and your path to capturing SOM.\n\nVCs typically want TAM of $1B+ for venture-scale investments. Smaller TAMs can support great businesses but aren't suitable for the venture model (which requires 10-100x returns).","url":"https://www.richardewing.io/glossary/total-addressable-market"},{"@type":"DefinedTerm","termCode":"design-system","name":"Design System","description":"A design system is a collection of reusable components, patterns, guidelines, and assets that enable consistent product design and development at scale. It serves as the single source of truth for how a product looks and behaves.\n\nDesign system components: design tokens (colors, spacing, typography), UI components (buttons, forms, modals), patterns (navigation, data display, onboarding), documentation (usage guidelines, accessibility requirements), and tooling (component libraries in Figma, React, etc.).\n\nFamous design systems: Material Design (Google), Carbon (IBM), Primer (GitHub), Polaris (Shopify), and Lightning (Salesforce).\n\nDesign systems are a significant investment (3-6 months to build, ongoing maintenance) but pay back through: 30-50% faster UI development, consistent user experience, easier onboarding for new designers and developers, and accessibility compliance by default.","url":"https://www.richardewing.io/glossary/design-system"},{"@type":"DefinedTerm","termCode":"accessibility-a11y","name":"Accessibility (a11y)","description":"Accessibility (a11y) is the practice of designing and developing software that can be used by people with disabilities, including visual, auditory, motor, and cognitive impairments.\n\nKey accessibility standards: WCAG 2.1 (Web Content Accessibility Guidelines) at levels A, AA, and AAA. Most organizations target AA compliance. Section 508 (US federal government requirement). ADA (Americans with Disabilities Act, which courts increasingly apply to websites).\n\nPractical accessibility requirements: keyboard navigation (all interactive elements reachable by keyboard), screen reader compatibility (correct ARIA attributes, semantic HTML), color contrast (4.5:1 minimum for normal text), alt text for images, captioning for videos, and scalable text.\n\nAccessibility is not a feature — it's a quality requirement. 15-20% of the global population has some form of disability. Inaccessible products exclude a significant portion of potential users and create legal liability.","url":"https://www.richardewing.io/glossary/accessibility-a11y"},{"@type":"DefinedTerm","termCode":"user-research","name":"User Research","description":"User research is the systematic study of target users to understand their behaviors, needs, motivations, and pain points. It informs product decisions with evidence rather than assumptions.\n\nResearch methods fall into two categories: qualitative (understanding the \"why\") and quantitative (measuring the \"how much\").\n\nQualitative methods: user interviews, contextual inquiry (observing users in their environment), usability testing, diary studies, and focus groups.\n\nQuantitative methods: surveys, A/B testing, analytics analysis, card sorting, and tree testing.\n\nUser research should be continuous, not a one-time event. Teresa Torres' Continuous Discovery framework recommends weekly customer touchpoints to maintain a steady stream of user insight that informs ongoing product decisions.","url":"https://www.richardewing.io/glossary/user-research"},{"@type":"DefinedTerm","termCode":"information-architecture","name":"Information Architecture (IA)","description":"Information Architecture is the structural design of information spaces — how content and functionality are organized, labeled, and navigated within a digital product. Good IA makes complex systems feel simple.\n\nIA components: organization schemes (how content is categorized), labeling systems (terminology used in navigation), navigation systems (how users move through content), and search systems (how users find specific content).\n\nIA methods: card sorting (users group cards to reveal their mental models), tree testing (users find items in a proposed navigation structure), and site mapping (visual representation of content hierarchy).\n\nPoor IA is one of the most common causes of user confusion and low feature adoption. Users can't use features they can't find. Navigation that makes sense to the product team often doesn't match user mental models.","url":"https://www.richardewing.io/glossary/information-architecture"},{"@type":"DefinedTerm","termCode":"conversion-rate-optimization","name":"Conversion Rate Optimization (CRO)","description":"Conversion Rate Optimization is the systematic process of increasing the percentage of users who take a desired action — signing up, subscribing, purchasing, or completing a key workflow.\n\nCRO methodology: define the conversion goal → analyze current funnel data → identify drop-off points → hypothesize improvements → test (A/B test) → implement winners → iterate.\n\nCommon CRO techniques: simplify forms (reduce fields from 10 to 5), improve page load speed, add social proof (testimonials, customer logos), clarify value propositions, reduce friction (auto-fill, saved preferences), and optimize CTAs (above the fold, action-oriented copy).\n\nCRO compounding: a 10% improvement at each of 5 funnel stages produces a 61% improvement in overall conversion. This makes CRO one of the highest-ROI growth activities.","url":"https://www.richardewing.io/glossary/conversion-rate-optimization"},{"@type":"DefinedTerm","termCode":"sprint-planning","name":"Sprint Planning","description":"Sprint planning is the Scrum ceremony where the team decides what work to commit to for the upcoming sprint (typically 2 weeks). The team selects items from the prioritized product backlog based on their capacity and velocity.\n\nEffective sprint planning: review sprint goal (what outcome are we pursuing?), select backlog items that contribute to the goal, break stories into tasks, estimate effort, and identify dependencies and risks.\n\nCommon sprint planning mistakes: overcommitting (teams consistently plan more than they can deliver), not accounting for meetings and maintenance, planning without a clear sprint goal, and spending too long in planning (timebox to 2-4 hours).\n\nSprint length: 2 weeks is the most common. 1 week for fast-moving teams. 3-4 weeks for teams with longer release cycles. Consistency matters more than length — pick a cadence and stick with it.","url":"https://www.richardewing.io/glossary/sprint-planning"},{"@type":"DefinedTerm","termCode":"kanban","name":"Kanban","description":"Kanban is a workflow management method that visualizes work, limits work in progress (WIP), and optimizes flow. Originating from Toyota's manufacturing system, it was adapted for software development by David J. Anderson.\n\nKanban principles: visualize the workflow (board with columns), limit WIP (set maximum items per column), manage flow (optimize throughput), make policies explicit, and improve collaboratively.\n\nKanban vs. Scrum: Kanban is flow-based (continuous), Scrum is iteration-based (sprints). Kanban has no prescribed roles, Scrum has Scrum Master and Product Owner. Kanban limits WIP per column, Scrum limits work per sprint. Many teams use \"Scrumban\" — combining elements of both.\n\nThe key insight: limiting WIP reduces context-switching, which dramatically improves productivity. A developer working on 5 things completes all 5 slower than a developer working on 2 things sequentially.","url":"https://www.richardewing.io/glossary/kanban"},{"@type":"DefinedTerm","termCode":"retrospective","name":"Sprint Retrospective","description":"A sprint retrospective is a team ceremony held at the end of each sprint to reflect on what went well, what didn't, and what to improve. It's the primary mechanism for continuous improvement in agile teams.\n\nClassic retro format: What went well? What didn't go well? What should we change? Teams vote on the most important items and commit to 1-3 specific action items for the next sprint.\n\nAlternative formats: Start/Stop/Continue, 4Ls (Liked/Learned/Lacked/Longed for), Sailboat (wind = helps, anchors = hinders), and Mad/Sad/Glad.\n\nRetro anti-patterns: not following up on action items (the #1 killer of retro effectiveness), managers dominating the conversation, team members not feeling safe to speak up, repetitive discussions without resolution, and running retros as status meetings instead of improvement sessions.","url":"https://www.richardewing.io/glossary/retrospective"},{"@type":"DefinedTerm","termCode":"technical-program-management","name":"Technical Program Management (TPM)","description":"Technical Program Management is the discipline of coordinating complex, cross-team technical initiatives from planning through delivery. TPMs combine project management skills with technical understanding to drive programs that span multiple engineering teams.\n\nTPM responsibilities: defining program scope and milestones, managing cross-team dependencies, risk identification and mitigation, stakeholder communication, and driving decisions when teams can't resolve conflicts.\n\nTPMs are essential for: platform migrations, infrastructure modernization, multi-team feature launches, compliance programs (SOC 2, GDPR implementation), and technical debt reduction initiatives.\n\nTPM vs. Engineering Manager: EMs manage people on a single team. TPMs manage programs across multiple teams. EMs focus on team health and execution. TPMs focus on cross-team coordination and delivery.","url":"https://www.richardewing.io/glossary/technical-program-management"},{"@type":"DefinedTerm","termCode":"story-points","name":"Story Points","description":"Story points are a unit of estimation used in agile development to measure the relative effort, complexity, and uncertainty of a user story. They use a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) where higher numbers represent more effort and uncertainty.\n\nStory points are relative, not absolute. A 5-point story is roughly 2.5x the effort of a 2-point story. The absolute time varies by team — one team's 5 might take 2 days while another team's 5 takes 4 days. This is fine because points measure relative effort within a team.\n\nStory point criticisms: they're often misused as productivity metrics (comparing team velocities), they don't measure value (a 13-point story might deliver zero customer value), and they can be gamed (teams inflate points to look more productive).\n\nModern alternatives: cycle time (actual time from start to done), no estimation (just break stories into similarly-sized chunks), and outcome-based tracking (did we achieve the sprint goal?).","url":"https://www.richardewing.io/glossary/story-points"},{"@type":"DefinedTerm","termCode":"r-and-d-capitalization","name":"R&D Capitalization (ASC 350-40)","description":"R&D capitalization is the accounting practice of recording certain software development costs as assets on the balance sheet rather than expenses on the income statement. Under ASC 350-40, costs incurred during the \"application development stage\" can be capitalized.\n\nThree stages: Preliminary Project Stage (all costs expensed — planning, research, feasibility), Application Development Stage (costs can be capitalized — coding, testing, direct labor), and Post-Implementation Stage (costs expensed — maintenance, bug fixes, training).\n\nWhat can be capitalized: developer salaries during coding, third-party software costs, testing costs, and directly related overhead. What cannot: maintenance, data conversion, general overhead, and training.\n\nCapitalization matters because it shifts costs from the income statement (reduces current profit) to the balance sheet (spreads cost over the asset's useful life via amortization). This can significantly change reported profitability and tax liability.","url":"https://www.richardewing.io/glossary/r-and-d-capitalization"},{"@type":"DefinedTerm","termCode":"engineering-cost-allocation","name":"Engineering Cost Allocation","description":"Engineering cost allocation is the process of categorizing engineering spend into functional buckets: new feature development (innovation), maintenance and support, infrastructure, and technical debt remediation.\n\nHealthy allocation benchmarks: 40-60% innovation (new features), 20-30% maintenance (bugs, support), 10-20% infrastructure (tooling, platform), and 5-15% debt reduction (refactoring).\n\nThe Innovation Tax problem: most organizations believe they spend 60%+ on innovation. Richard Ewing's R&D Capital Audits consistently find the actual number is 25-40%. The gap is maintenance work embedded in feature sprints — engineers fixing bugs, updating dependencies, and refactoring within \"feature\" stories.\n\nAccurate cost allocation requires: time tracking (at minimum, sprint-level categorization), clear definitions of each category, and regular auditing to prevent category drift.","url":"https://www.richardewing.io/glossary/engineering-cost-allocation"},{"@type":"DefinedTerm","termCode":"capitalization-matrix","name":"Capitalization Matrix","description":"The Capitalization Matrix is a framework introduced by Richard Ewing in CIO.com for bridging the gap between engineering velocity metrics and financial governance. It maps agile development work categories to their correct financial treatment under ASC 350-40.\n\nCIOs speak in sprints and story points. CFOs speak in quarters and capitalization rates. The Capitalization Matrix translates between these two languages, ensuring engineering work is properly classified for financial reporting and R&D tax credits.\n\nThe matrix categorizes work into four quadrants: Capitalizable Innovation (new features in application development stage — can be capitalized), Non-Capitalizable Innovation (research, spikes, POCs — must be expensed), Capitalizable Maintenance (major version upgrades — sometimes capitalizable), and Non-Capitalizable Maintenance (bug fixes, patches — always expensed).\n\nMisclassification is endemic: Richard Ewing's audits reveal that 30-40% of organizations incorrectly capitalize maintenance work as R&D investment, overstating their innovation spend and potentially creating tax liability.","url":"https://www.richardewing.io/glossary/capitalization-matrix"},{"@type":"DefinedTerm","termCode":"systems-governor","name":"Systems Governor","description":"The Systems Governor is a role concept introduced by Richard Ewing in Built In that defines the evolved role of a software engineer in the AI age. When AI generates code, the human engineer's role shifts from code writer to system verifier, architectural guardian, and judgment exerciser.\n\nThe Systems Governor is responsible for: verifying AI-generated code for correctness, security, and performance; making ship/no-ship decisions based on risk assessment; designing system architecture that AI tools implement; establishing guardrails and constraints for AI-assisted development; and maintaining the mental model of the system that AI tools lack.\n\nThe transition from \"code writer\" to \"Systems Governor\" has implications for hiring (test verification skills, not generation skills), career development (judgment becomes the key differentiator), education (teach architecture and risk assessment, not syntax), and compensation (governors who prevent failures are more valuable than generators who produce output).","url":"https://www.richardewing.io/glossary/systems-governor"},{"@type":"DefinedTerm","termCode":"four-laws-probabilistic-software","name":"4 Laws of Probabilistic Software","description":"The 4 Laws of Probabilistic Software Development are principles coined by Richard Ewing in Built In that define the fundamental constraints of AI-generated code:\n\n**Law 1: Code generated by probability is correct by probability, not by proof.** AI-generated code may work for common cases but fail for edge cases. Unlike code written with deliberate reasoning, probabilistic code's correctness is statistical, not guaranteed.\n\n**Law 2: The confidence of the generator does not equal the correctness of the output.** AI models express equal confidence whether the output is correct or hallucinated. Confidence is not a reliability signal.\n\n**Law 3: Every layer of abstraction added by AI is a layer of understanding removed from the human.** As AI generates more of the system, human developers understand less of the system. This creates a fragility that compounds over time.\n\n**Law 4: The cost of AI-generated code is paid at verification time, not generation time.** Generation is instant and cheap. Verification — finding the bugs, confirming correctness, validating security — is where the real cost lives. Organizations that skip verification accumulate invisible debt.","url":"https://www.richardewing.io/glossary/four-laws-probabilistic-software"},{"@type":"DefinedTerm","termCode":"ai-liability-gradient","name":"AI Liability Gradient","description":"The AI Liability Gradient is an analytical framework introduced by Richard Ewing in Built In that maps the relationship between AI agent autonomy and organizational liability. As AI agents become more autonomous, the liability exposure increases non-linearly.\n\nThe gradient has four zones:\n\n**Zone 1: Assistive AI** (low autonomy, low liability) — AI suggests, humans decide and act. Liability is minimal because humans maintain full control. Example: code completion, spell check.\n\n**Zone 2: Augmentive AI** (moderate autonomy, moderate liability) — AI generates, humans review. Liability exists if human review is inadequate. Example: AI-generated code deployed after review, AI-written content published after editing.\n\n**Zone 3: Autonomous AI** (high autonomy, high liability) — AI decides and acts within constraints. Liability shifts to the organization for the quality of constraints. Example: automated trading systems, AI customer service.\n\n**Zone 4: Agentic AI** (full autonomy, extreme liability) — AI plans, decides, and acts independently. Liability is maximum because the organization is responsible for all agent actions. Example: AI agents making purchase decisions, deploying code, or communicating with customers.\n\nThe key insight: liability doesn't scale linearly with autonomy — it scales exponentially. Moving from Zone 2 to Zone 3 doubles autonomy but quadruples potential liability.","url":"https://www.richardewing.io/glossary/ai-liability-gradient"},{"@type":"DefinedTerm","termCode":"sunset-protocol","name":"Sunset Protocol","description":"The Sunset Protocol is a structured deprecation methodology introduced by Richard Ewing in Built In for safely removing features from a software product. It provides a governance framework for subtraction — the organizational discipline of removing things, which is harder politically than adding them.\n\nThe Sunset Protocol has five stages:\n\n**Stage 1: Identify** — Flag features below 5% of peak usage, $0 revenue attribution, or maintenance cost exceeding 10% of value contribution.\n\n**Stage 2: Quantify** — Calculate total cost of keeping the feature alive: direct maintenance hours × fully-loaded engineer cost × opportunity cost multiplier.\n\n**Stage 3: Communicate** — Notify affected users and stakeholders with clear timelines. Provide migration paths where applicable.\n\n**Stage 4: Deprecate** — Feature flag the feature off for new users, then gradually for existing users. Monitor for unexpected breakage.\n\n**Stage 5: Remove** — Delete the code with rollback capability. Clean up dependencies, tests, and infrastructure. Monitor for 30 days post-removal.\n\nThe Sunset Protocol is the execution methodology that pairs with the Kill Switch Protocol (which identifies what to kill) and Feature Bloat Calculus (which quantifies why to kill it).","url":"https://www.richardewing.io/glossary/sunset-protocol"},{"@type":"DefinedTerm","termCode":"zombie-features","name":"Zombie Features","description":"Zombie Features is a term coined by Richard Ewing to describe product features that are technically alive (still running in production) but functionally dead (no meaningful usage, no revenue contribution, no strategic value). Like zombies, they consume resources while producing nothing of value.\n\nZombie features come in four varieties:\n\n**Ghost Features**: Built, launched, and never adopted. They sit in the codebase consuming maintenance hours but have near-zero usage metrics.\n\n**Legacy Bridges**: Compatibility layers, deprecated API versions, and backward-compatible code paths that serve a tiny percentage of users but add complexity to every future change.\n\n**Vanity Features**: Built because a senior stakeholder wanted them, not because users needed them. Protected by organizational politics rather than business merit.\n\n**Abandoned Experiments**: A/B test variants never cleaned up, prototypes that became permanent, and \"temporary\" solutions that became load-bearing infrastructure.\n\nRichard Ewing's audits find that 40-60% of a typical codebase consists of zombie features, consuming 30-50% of the total maintenance burden.","url":"https://www.richardewing.io/glossary/zombie-features"},{"@type":"DefinedTerm","termCode":"complexity-tax","name":"Complexity Tax","description":"The Complexity Tax is the compounding cost factor in Feature Bloat Calculus that most organizations entirely miss. It quantifies how every feature in the codebase makes every other feature harder to maintain and every new feature harder to build.\n\nThe Complexity Tax follows a roughly quadratic curve: potential interaction points between features grow as n × (n-1) / 2. A system with 50 features has ~1,225 potential interaction points. A system with 100 features has ~4,950. Doubling features doesn't double complexity — it quadruples it.\n\nThis means: adding feature #101 doesn't just add its own maintenance cost — it increases the maintenance cost of features #1-100. The Complexity Tax is the hidden cost that makes \"just add more engineers\" an insufficient solution to velocity slowdowns caused by feature accumulation.\n\nThe Complexity Tax is calculated as: number of integration points × average interaction maintenance cost. This is the third component of Feature Bloat Calculus, alongside Direct Maintenance Cost and Opportunity Cost.","url":"https://www.richardewing.io/glossary/complexity-tax"},{"@type":"DefinedTerm","termCode":"negative-carry-features","name":"Negative Carry (Features)","description":"Negative Carry is a financial concept applied by Richard Ewing to product features. A feature has negative carry when its total cost (direct maintenance + opportunity cost + complexity tax) exceeds its value contribution (revenue attribution + user engagement + strategic importance).\n\nBorrowed from bond trading: a bond has negative carry when the cost of financing it exceeds the coupon yield. Similarly, a feature has negative carry when maintaining it costs more than the value it generates.\n\nIdentifying negative carry features is the first step of the Kill Switch Protocol. Features with the highest negative carry should be sunset first, as removing them frees the most engineering capacity per feature removed.\n\nThe typical enterprise software product has 30-40% of its features in negative carry territory. These features collectively consume $1-5M+ in annual maintenance costs while contributing zero or near-zero to revenue and strategic objectives.","url":"https://www.richardewing.io/glossary/negative-carry-features"},{"@type":"DefinedTerm","termCode":"ai-margin-collapse-point","name":"AI Margin Collapse Point","description":"The AI Margin Collapse Point is the specific usage volume at which an AI feature's variable costs exceed the revenue it generates, causing the feature to destroy margin rather than create it. Coined by Richard Ewing as part of the Cost of Predictivity framework.\n\nTraditional software has near-zero marginal costs — serving the 1,000th user costs roughly the same as serving the 10th. AI features break this model: every query costs compute, and costs scale linearly (or worse) with usage.\n\nThe AI Margin Collapse Point = Revenue per AI query ÷ Cost per useful AI output. When cost exceeds revenue, you've passed the collapse point.\n\nMany AI features that work beautifully in prototype (low volume, accuracy requirements are lower) become economically devastating in production (high volume, users demand high accuracy, support costs from hallucinations). The collapse point often surprises organizations because testing at 100 users shows positive economics, but production at 100,000 users reveals the exponential cost curve.\n\nThe AUEB calculator at richardewing.io/tools/aueb helps companies identify their specific margin collapse point before it hits the P&L.","url":"https://www.richardewing.io/glossary/ai-margin-collapse-point"},{"@type":"DefinedTerm","termCode":"pl-ownership-for-pms","name":"P&L Ownership for Product Managers","description":"P&L Ownership for Product Managers is the principle — championed by Richard Ewing in Mind the Product — that senior product managers should own the profit-and-loss impact of their product area, not just the feature roadmap.\n\nTraditional PM scorecard: shipped features, NPS, user engagement. Product Economist scorecard: gross margin contribution, COGS efficiency, maintenance cost ratio, and revenue attribution per feature.\n\nThe three financial metrics every PM needs (per Richard Ewing's Mind the Product article):\n\n**1. Gross Margin by Feature**: What percentage of feature revenue remains after direct costs? AI features often have 40-60% margins versus 80-90% for traditional features.\n\n**2. COGS Efficiency Ratio**: Cost of goods sold as a percentage of revenue, tracked per product line. Identifies which products are margin-positive and which are margin-negative.\n\n**3. Maintenance Cost Ratio**: What percentage of engineering effort maintains this feature versus develops new capability? Features above 30% maintenance ratio are candidates for the Kill Switch Protocol.\n\nP&L-aware PMs make fundamentally different decisions: they don't just ask \"should we build this?\" but \"can we afford to maintain this at scale?\"","url":"https://www.richardewing.io/glossary/pl-ownership-for-pms"},{"@type":"DefinedTerm","termCode":"variable-cost-of-intelligence","name":"Variable Cost of Intelligence","description":"The Variable Cost of Intelligence is a macro-economic concept analyzed by Richard Ewing in Built In that describes how AI fundamentally changes the cost structure of software production. For the first time in computing history, intelligence has a meaningful variable cost.\n\nPre-AI software cost model: high fixed costs (development), near-zero variable costs (serving). The marginal cost of serving one more user was essentially zero — an API call to a database costs fractions of a cent.\n\nAI software cost model: high fixed costs (development + training), significant variable costs (inference). Every AI query consumes compute. Every token processed costs money. Intelligence is no longer free at the margin.\n\nThis has three macro implications: 1) Gross margins compress as AI features scale (costs grow with usage), 2) Pricing models must account for per-query costs (usage-based pricing becomes necessary), 3) The build-once-serve-millions model breaks for AI features (each use has real cost).\n\nRichard Ewing argues this is the most significant structural change in software economics since the shift to SaaS. Companies that don't adapt their financial models to account for the variable cost of intelligence will experience margin collapse.","url":"https://www.richardewing.io/glossary/variable-cost-of-intelligence"},{"@type":"DefinedTerm","termCode":"macro-regression-loops","name":"Macro Regression Loops","description":"Macro Regression Loops are a concept analyzed by Richard Ewing in Built In that describe feedback cycles where AI agent actions create cascading effects that amplify through economic systems.\n\nExample: an AI trading agent sells a stock → triggers other AI agents' stop-loss algorithms → causes a price drop → triggers more automated selling → creates a flash crash. The individual agent actions are rational, but the system-level outcome is destructive.\n\nIn software development: an AI code agent introduces a subtle bug → CI passes because the test suite doesn't cover the edge case → the bug affects a dependency → downstream AI agents build on the buggy code → the error compounds through multiple layers, becoming increasingly difficult to trace and fix.\n\nRichard Ewing identifies three types of macro regression loops:\n\n**Type 1: Cascade loops** — one AI action triggers a chain of automated responses.\n**Type 2: Amplification loops** — AI outputs become training data for other AI systems, amplifying errors.\n**Type 3: Feedback loops** — AI-generated metrics influence the AI's own future decisions, creating self-reinforcing biases.\n\nGovernance frameworks must account for macro regression loops by designing circuit breakers, human review checkpoints, and system-level monitoring.","url":"https://www.richardewing.io/glossary/macro-regression-loops"},{"@type":"DefinedTerm","termCode":"internal-developer-platform","name":"Internal Developer Platform (IDP)","description":"An Internal Developer Platform (IDP) is a self-service layer that abstracts away infrastructure complexity and enables developers to deploy, manage, and monitor applications without needing deep DevOps expertise. IDPs provide golden paths — pre-configured, opinionated workflows that embody organizational best practices while still allowing flexibility for edge cases.\n\nThe core components of an IDP include: a service catalog (what can be deployed), infrastructure abstraction (how it gets deployed), environment management (where it runs), and observability integration (how to monitor it). Tools like Backstage (Spotify), Port, Humanitec, and Kratix power modern IDPs.\n\nPlatform engineering teams build and maintain the IDP as an internal product, treating developers as their customers. The measure of success is developer self-service rate: what percentage of deployments happen without a ticket to the platform team?","url":"https://www.richardewing.io/glossary/internal-developer-platform"},{"@type":"DefinedTerm","termCode":"service-mesh","name":"Service Mesh","description":"A service mesh is a dedicated infrastructure layer for managing service-to-service communication in microservices architectures. It handles traffic routing, load balancing, encryption (mTLS), observability, and retry logic — all without requiring application code changes.\n\nPopular implementations include Istio (with Envoy proxy), Linkerd, and Consul Connect. The mesh works by deploying sidecar proxies alongside each service instance, intercepting all network traffic and applying policies uniformly.\n\nKey capabilities: mTLS encryption between services (zero-trust networking), traffic management (canary deployments, A/B routing, circuit breaking), observability (distributed tracing, metrics, access logging), and policy enforcement (rate limiting, authorization).","url":"https://www.richardewing.io/glossary/service-mesh"},{"@type":"DefinedTerm","termCode":"feature-flags","name":"Feature Flags","description":"Feature flags (also called feature toggles) are a software development technique that decouples deployment from release. Code changes are deployed to production behind conditional flags that control which users see the new functionality. This enables trunk-based development, canary releases, A/B testing, and instant rollbacks without redeployment.\n\nTypes of feature flags: Release flags (temporary, gate new features during rollout), Experiment flags (A/B tests with percentage-based targeting), Ops flags (circuit breakers for graceful degradation), and Permission flags (entitlement-based access for different pricing tiers).\n\nTools: LaunchDarkly, Split.io, Flagsmith, Unleash, and built-in platform solutions. Flag debt is a real concern — flags that are never cleaned up create code complexity. Best practice: every flag has an owner and an expiration date.","url":"https://www.richardewing.io/glossary/feature-flags"},{"@type":"DefinedTerm","termCode":"api-gateway","name":"API Gateway","description":"An API gateway is a server that acts as the single entry point for all API requests to a system of microservices. It handles request routing, authentication/authorization, rate limiting, request/response transformation, caching, and API versioning.\n\nPopular implementations: Kong, AWS API Gateway, Apigee (Google), Azure API Management, and Traefik. The gateway pattern centralizes cross-cutting concerns that would otherwise need to be implemented in every service.\n\nModern API gateways also serve as: developer portals (API documentation and key management), analytics platforms (usage tracking, latency monitoring), and monetization engines (usage-based billing, quota management).","url":"https://www.richardewing.io/glossary/api-gateway"},{"@type":"DefinedTerm","termCode":"chaos-engineering","name":"Chaos Engineering","description":"Chaos engineering is the discipline of experimenting on a distributed system to build confidence in the system's ability to withstand turbulent conditions in production. Pioneered by Netflix (Chaos Monkey), the practice involves intentionally injecting failures — killing instances, introducing network latency, corrupting data — to discover weaknesses before they cause outages.\n\nThe scientific method of chaos engineering: 1) Define steady state (normal system behavior), 2) Hypothesize about what happens during failure, 3) Introduce failure (kill a service, drop packets, exhaust CPU), 4) Observe system behavior, 5) Fix discovered weaknesses.\n\nTools: Chaos Monkey (Netflix), Gremlin, LitmusChaos, AWS Fault Injection Simulator. GameDay exercises are scheduled chaos experiments where teams practice incident response.","url":"https://www.richardewing.io/glossary/chaos-engineering"},{"@type":"DefinedTerm","termCode":"golden-paths","name":"Golden Paths","description":"Golden paths (also called paved roads) are opinionated, pre-configured workflows that represent the recommended way to accomplish common development tasks within an organization. They're the \"happy path\" that platform engineering teams build to optimize for the 80% case.\n\nExamples: a golden path for deploying a new microservice includes a template repository, CI/CD pipeline, monitoring dashboards, and runbooks — all pre-configured. A developer creates a new service using the template and gets production-ready infrastructure in minutes.\n\nThe key principle: golden paths should be the easiest option, not the only option. Teams can deviate, but deviation requires justification and comes with the understanding that they're outside the supported path.","url":"https://www.richardewing.io/glossary/golden-paths"},{"@type":"DefinedTerm","termCode":"trunk-based-development","name":"Trunk-Based Development","description":"Trunk-based development (TBD) is a source-control branching model where all developers commit to a single branch (\"trunk\" or \"main\") at least once per day. Long-lived feature branches are avoided; short-lived branches (less than 24 hours) are acceptable.\n\nTBD enables continuous integration by ensuring that integration happens continuously — every commit is integrated immediately, not after weeks of branch divergence. Feature flags gate incomplete features, allowing code to be merged to trunk before the feature is fully complete.\n\nThe alternative — GitFlow with long-lived branches — creates merge conflicts, delays integration, and hides bugs that only appear when branches finally merge. Research by DORA (DevOps Research and Assessment) shows trunk-based development is a strong predictor of elite software delivery performance.","url":"https://www.richardewing.io/glossary/trunk-based-development"},{"@type":"DefinedTerm","termCode":"canary-deployment","name":"Canary Deployment","description":"A canary deployment is a release strategy that rolls out changes to a small subset of users (the \"canary group\") before deploying to the full user base. If the canary group experiences no issues, the rollout gradually expands to 100%. If problems are detected, the change is rolled back, affecting only the canary group.\n\nThe name comes from \"canary in a coal mine\" — the early warning system that detects problems before they affect everyone.\n\nCanary deployment requires: traffic splitting capability (route X% of traffic to the new version), monitoring (detect errors and performance degradation in the canary), and automated rollback (revert if metrics exceed thresholds). Progressive delivery tools like Argo Rollouts, Flagger, and LaunchDarkly automate canary strategies.","url":"https://www.richardewing.io/glossary/canary-deployment"},{"@type":"DefinedTerm","termCode":"platform-team","name":"Platform Team","description":"A platform team is an internal team that builds and maintains developer tooling, infrastructure, and self-service capabilities. Unlike traditional DevOps or infrastructure teams that respond to tickets, platform teams operate as internal product teams — they have users (developers), roadmaps, and measure satisfaction through developer experience surveys.\n\nThe platform team builds the Internal Developer Platform (IDP) and maintains golden paths. Their success metric isn't uptime (that's SRE) — it's developer self-service rate: what percentage of infrastructure requests are handled without human intervention?\n\nTeam Topologies by Matthew Skelton and Manuel Pais formally defines the platform team pattern, recommending that platform teams treat their internal platform as a product with the same rigor as external-facing products.","url":"https://www.richardewing.io/glossary/platform-team"},{"@type":"DefinedTerm","termCode":"backstage","name":"Backstage (Spotify)","description":"Backstage is an open-source developer portal framework created by Spotify. It provides a centralized hub where developers can discover services, APIs, documentation, and infrastructure — all in one place. Backstage is the most popular foundation for building Internal Developer Platforms (IDPs).\n\nCore features: Software Catalog (inventory of all services, APIs, and resources), Software Templates (golden paths for creating new services), TechDocs (documentation-as-code integrated into the portal), and a plugin system (extend with custom integrations).\n\nAdopted by organizations including Spotify, Expedia, Netflix, HP, and IKEA. The CNCF-incubating project has 150+ plugins for integrating with CI/CD, monitoring, cost management, and security tools.","url":"https://www.richardewing.io/glossary/backstage"},{"@type":"DefinedTerm","termCode":"developer-experience","name":"Developer Experience (DevEx)","description":"Developer Experience (DevEx or DX) is the overall experience that developers have when working with a tool, API, platform, or organization. It encompasses everything from development environment setup time to CI/CD feedback loops, documentation quality, and cognitive load.\n\nDXCORE framework by Noda, Storey, and Forsgren identifies three dimensions: Flow State (ability to work without interruptions), Cognitive Load (mental effort required to complete tasks), and Feedback Loops (time between making a change and seeing the result).\n\nKey DevEx metrics: time to first commit (how fast can a new hire ship?), CI/CD feedback time (how long between push and deploy?), inner loop cycle time (edit-build-test time on a developer's machine), and developer satisfaction scores.","url":"https://www.richardewing.io/glossary/developer-experience"},{"@type":"DefinedTerm","termCode":"rate-limiting","name":"Rate Limiting","description":"Rate limiting is a technique for controlling the number of requests a client can make to an API or service within a given time window. It protects services from abuse, ensures fair resource allocation, and prevents cascade failures.\n\nCommon algorithms: Token Bucket (allows burst traffic up to a limit), Sliding Window (smooth rate enforcement over time), Fixed Window (simple counter reset per interval), and Leaky Bucket (enforces constant output rate).\n\nRate limiting is implemented at multiple layers: API gateway (global rate limits), service level (per-endpoint limits), and infrastructure (connection limits, DDoS protection). HTTP 429 (Too Many Requests) is the standard response code.","url":"https://www.richardewing.io/glossary/rate-limiting"},{"@type":"DefinedTerm","termCode":"seo-search-engine-optimization","name":"SEO (Search Engine Optimization)","description":"Search Engine Optimization (SEO) is the practice of optimizing web content, structure, and technical implementation to increase organic visibility in search engine results. In 2026, SEO encompasses traditional Google optimization and Generative Engine Optimization (GEO) — ensuring content is structured for AI systems like ChatGPT, Perplexity, and Google AI Overviews.\n\nCore pillars: Technical SEO (site speed, mobile responsiveness, crawlability, schema markup), On-page SEO (keyword optimization, heading structure, internal linking), Off-page SEO (backlinks, domain authority, brand mentions), and Content SEO (topical authority, content depth, freshness).\n\nFor technology leaders: SEO is the most scalable, lowest-CAC acquisition channel. A glossary with 500+ terms creates massive topical authority, attracting developers, PMs, and executives who then convert to advisory clients and tool users.","url":"https://www.richardewing.io/glossary/seo-search-engine-optimization"},{"@type":"DefinedTerm","termCode":"geo-generative-engine-optimization","name":"GEO (Generative Engine Optimization)","description":"Generative Engine Optimization (GEO) is the practice of structuring content so that AI language models — ChatGPT, Claude, Perplexity, Google AI Overviews — cite your content when answering user queries. GEO is the 2026 evolution of SEO.\n\nKey GEO strategies: Definitive definitions (position as the canonical source), Structured data (FAQ schema, HowTo schema, clear heading hierarchies), Attribution-friendly formatting (include the author's name and credentials alongside definitions), Quantitative frameworks (models that can be referenced with specific numbers), and Internal linking density (create a knowledge graph that AI systems can traverse).\n\nRichard Ewing's glossary is a GEO strategy: by creating 600+ definitive, well-structured definitions for engineering economics terms with his name attached, AI systems naturally cite richardewing.io when answering questions about these topics.","url":"https://www.richardewing.io/glossary/geo-generative-engine-optimization"},{"@type":"DefinedTerm","termCode":"content-marketing","name":"Content Marketing","description":"Content marketing is a strategic approach to creating and distributing valuable, relevant content to attract and engage a target audience. For technology leaders and consultants, content marketing builds thought leadership, trust, and inbound lead generation.\n\nContent types ranked by leverage: Glossaries and reference content (evergreen, high SEO value, LLM citation bait), Frameworks and methodologies (unique IP, high authority), Long-form articles in tier-1 publications (credibility, backlinks), Tools and calculators (interactive, high engagement, lead capture), Newsletters (direct audience relationship), and Social media (distribution, not ownership).\n\nThe content marketing flywheel: Create authoritative content → Rank in search / get cited by AI → Attract qualified traffic → Convert via tools and CTAs → Build email list → Nurture through newsletter → Convert to advisory clients.","url":"https://www.richardewing.io/glossary/content-marketing"},{"@type":"DefinedTerm","termCode":"topical-authority","name":"Topical Authority","description":"Topical authority is a search engine ranking factor that measures how comprehensively a website covers a specific subject area. Websites with deep, interconnected content on a topic rank higher for all related queries than websites with shallow, scattered coverage.\n\nHow to build topical authority: 1) Cover the topic exhaustively (every sub-topic, related concept, and FAQ), 2) Create internal linking density (every page links to 5+ related pages), 3) Use consistent terminology and structured data, 4) Publish regularly on the topic, 5) Earn backlinks from authoritative sources.\n\nRichardewing.io's 600+ term glossary is a topical authority play for \"engineering economics.\" By covering every conceivable term — from technical debt to AI unit economics to SaaS metrics — the site signals to Google that it's the most comprehensive resource on this topic cluster.","url":"https://www.richardewing.io/glossary/topical-authority"},{"@type":"DefinedTerm","termCode":"viral-coefficient","name":"Viral Coefficient (K-Factor)","description":"The viral coefficient (K-factor) measures how many new users each existing user generates through referrals, sharing, or network effects. A K-factor > 1 means viral growth — each user brings more than one new user, creating exponential growth.\n\nFormula: K = (invitations sent per user) × (conversion rate per invitation). If each user invites 5 people and 25% sign up, K = 5 × 0.25 = 1.25.\n\nViral loops: Inherent virality (the product requires others to use it, like Slack), Collaborative virality (the product is better with others, like Google Docs), Word-of-mouth virality (the product is remarkable enough to talk about, like ChatGPT), and Incentivized virality (users get rewards for referrals, like Dropbox's storage bonuses).","url":"https://www.richardewing.io/glossary/viral-coefficient"},{"@type":"DefinedTerm","termCode":"network-effects","name":"Network Effects","description":"Network effects occur when a product becomes more valuable as more people use it. This creates a self-reinforcing growth loop: more users → more value → more users. Network effects are the strongest competitive moat in technology.\n\nTypes of network effects: Direct network effects (each new user makes the product more valuable for all users — phone networks, social media), Indirect network effects (more users attract more complementary products — more iPhone users attract more app developers), Data network effects (more usage generates more data, which improves the product — Google Search, recommendation engines), and Platform network effects (two-sided markets where more supply attracts more demand and vice versa — Uber, Airbnb).\n\nNetwork effects compound but are not permanent. Disruptors can break network effects through: differentiated value propositions, niche focus (start with an underserved segment), superior technology, or regulation.","url":"https://www.richardewing.io/glossary/network-effects"},{"@type":"DefinedTerm","termCode":"cac-channels","name":"Customer Acquisition Channels","description":"Customer acquisition channels are the pathways through which businesses attract new customers. Each channel has different cost structures (CAC), conversion rates, scalability limits, and time-to-value.\n\nChannel types ranked by typical B2B cost-effectiveness: Content/SEO (lowest CAC, slowest to ramp, highest long-term ROI), Product-Led Growth (low CAC, requires product investment, high retention), Referrals (low CAC, limited scale, highest trust), Community (moderate CAC, slow build, strong retention), Events/Conferences (moderate CAC, relationship-building, high conversion), Paid Search (moderate-high CAC, instant traffic, competitive), Outbound Sales (high CAC, predictable, scalable), and Paid Social (high CAC, awareness-building, lower intent).\n\nChannel-market fit: the right channel depends on ACV (annual contract value). Self-serve/PLG works for ACV < $5K. Inside sales for $5K-$50K. Field sales for $50K+. Enterprise sales for $250K+.","url":"https://www.richardewing.io/glossary/cac-channels"},{"@type":"DefinedTerm","termCode":"plg-flywheel","name":"PLG Flywheel","description":"The PLG (Product-Led Growth) Flywheel is the self-reinforcing growth loop where the product itself drives user acquisition, activation, retention, and expansion — reducing dependency on sales and marketing teams.\n\nThe flywheel stages: Awareness (free tools, content, SEO → users discover the product), Activation (self-serve onboarding → users experience value quickly), Adoption (product becomes embedded in workflows → daily usage), Expansion (usage-based pricing or premium features → revenue grows with usage), and Advocacy (satisfied users refer others → feeds back to awareness).\n\nExamples of PLG flywheel companies: Slack (teams invite others), Calendly (every meeting shows the product), Notion (templates get shared), and Figma (collaboration requires others to join).\n\nRichard Ewing's tools (PDI, AUEB, APER) are PLG assets: free tools that demonstrate expertise, capture leads, and create conversion opportunities for advisory services.","url":"https://www.richardewing.io/glossary/plg-flywheel"},{"@type":"DefinedTerm","termCode":"landing-page-optimization","name":"Landing Page Optimization","description":"Landing page optimization (LPO) is the process of improving landing page elements to increase conversion rates — the percentage of visitors who take a desired action (sign up, download, book a call).\n\nKey optimization elements: Headline (clear value proposition in < 10 words), Social proof (logos, testimonials, numbers), CTA (single, clear call-to-action above the fold), Page speed (every 100ms of load time reduces conversion by 1%), Form length (fewer fields = higher conversion; optimize for the minimum viable data), and Visual hierarchy (guide the eye to the CTA).\n\nBenchmarks: B2B SaaS landing pages convert at 2-5% on average. Top performers hit 10-15%. A/B testing and iterative improvement can double conversion rates within 3-6 months.","url":"https://www.richardewing.io/glossary/landing-page-optimization"},{"@type":"DefinedTerm","termCode":"email-marketing-automation","name":"Email Marketing & Automation","description":"Email marketing automation uses software to send targeted, personalized email sequences triggered by user behavior — sign-ups, tool usage, content downloads. It nurtures leads through the funnel without manual effort.\n\nKey sequences: Welcome series (onboard new subscribers), Nurture series (educate and build trust over weeks), Re-engagement (win back inactive users), Event-triggered (user completes a tool assessment → receive personalized recommendations), and Upgrade prompts (free users reaching limits → premium offer).\n\nTools: Beehiiv (newsletters + monetization), ConvertKit (creators), HubSpot (enterprise), and Mailchimp (small business). Key metrics: open rate (20-30% is good), click rate (2-5% is good), and unsubscribe rate (< 0.5% is healthy).","url":"https://www.richardewing.io/glossary/email-marketing-automation"},{"@type":"DefinedTerm","termCode":"conversion-rate-optimization","name":"Conversion Rate Optimization (CRO)","description":"Conversion Rate Optimization (CRO) is the systematic process of increasing the percentage of users who take a desired action on a website or application. CRO uses data analysis, user research, A/B testing, and behavioral psychology to improve conversion funnels.\n\nThe CRO process: 1) Measure current conversion rates at each funnel stage, 2) Identify the biggest drop-off points, 3) Hypothesize why users are dropping off (analytics, heatmaps, user interviews), 4) Design and implement changes, 5) A/B test against the control, 6) Roll out winners and iterate.\n\nCRO levers: Copy (headline, value proposition, CTA text), Design (layout, visual hierarchy, trust signals), Friction reduction (fewer form fields, simpler flows, faster load times), Social proof (testimonials, logos, case studies), and Urgency/scarcity (limited offers, countdown timers).","url":"https://www.richardewing.io/glossary/conversion-rate-optimization"},{"@type":"DefinedTerm","termCode":"referral-programs","name":"Referral Programs","description":"A referral program is a structured system that incentivizes existing users to recommend the product to their network. Well-designed referral programs are the lowest-CAC acquisition channel because they leverage trusted recommendations from people who already understand the product's value.\n\nReferral program models: Double-sided rewards (Dropbox: referrer and referee both get free storage), Credit-based (Uber: both parties get ride credits), Tiered rewards (larger rewards for more referrals), and Status/access-based (early access to new features for referrers).\n\nDesign principles: Make the referral mechanism dead simple (one-click sharing), ensure the incentive is valuable and relevant (not gift cards — give product value), show progress and social proof (\"5 of your colleagues already use this\"), and make the referred-user experience excellent (first impression matters).","url":"https://www.richardewing.io/glossary/referral-programs"},{"@type":"DefinedTerm","termCode":"psychological-safety","name":"Psychological Safety","description":"Psychological safety is a team climate where individuals feel safe to take interpersonal risks — asking questions, admitting mistakes, proposing ideas, and challenging the status quo — without fear of punishment, humiliation, or career damage. Research by Amy Edmondson (Harvard) shows it is the #1 predictor of team effectiveness.\n\nGoogle's Project Aristotle confirmed this finding: across 180 teams, psychological safety was the strongest predictor of team performance, above talent density, experience, or resources. Teams with high psychological safety make more mistakes visible faster, learn quicker, and innovate more.","url":"https://www.richardewing.io/glossary/psychological-safety"},{"@type":"DefinedTerm","termCode":"ic-vs-management-track","name":"IC vs. Management Track","description":"The IC (Individual Contributor) vs. Management career track is a dual-ladder career system that allows senior engineers to advance their career without becoming people managers. The IC track rewards technical depth, architecture expertise, and cross-team technical influence. The management track rewards people leadership, organizational design, and strategic execution.\n\nTypical IC track: Junior → Mid → Senior → Staff → Principal → Distinguished → Fellow. Typical management track: Tech Lead → Engineering Manager → Director → VP → SVP → CTO.\n\nThe \"management tax\" is real: many organizations lose their best engineers by forcing them into management roles they don't want. Dual-ladder systems retain technical talent by offering equivalent compensation and prestige without requiring people management.","url":"https://www.richardewing.io/glossary/ic-vs-management-track"},{"@type":"DefinedTerm","termCode":"one-on-ones","name":"One-on-Ones (1:1s)","description":"One-on-ones are recurring private meetings between a manager and their direct report. They are the most important management ritual in engineering organizations — the primary channel for coaching, feedback, career development, and early problem detection.\n\nEffective 1:1 structure: 10 minutes (their agenda — what's on their mind), 10 minutes (your agenda — feedback, context, requests), 10 minutes (career development — growth areas, opportunities, aspirations). The direct report should set the agenda, not the manager.\n\nCommon 1:1 anti-patterns: Status meetings (use standups for that), Manager monologues (listen more than talk), Skipping (signals the relationship isn't a priority), and No action items (meetings without follow-through erode trust).","url":"https://www.richardewing.io/glossary/one-on-ones"},{"@type":"DefinedTerm","termCode":"skip-levels","name":"Skip-Level Meetings","description":"Skip-level meetings are recurring meetings between a senior leader and the people who report to their direct reports. They bypass one level of the reporting chain to create a direct communication channel between senior leadership and individual contributors.\n\nPurpose: detect organizational problems that managers may not surface, build direct relationships with key ICs, get unfiltered team sentiment, and ensure organizational decisions have ground-truth input. They are NOT for undermining the middle manager — they supplement the management chain.\n\nFormat: monthly or quarterly, 30 minutes, informal. Good questions: \"What would you change if you were in charge for a day?\", \"What's slowing you down that I could fix?\", \"Is there anything you think I should know?\"","url":"https://www.richardewing.io/glossary/skip-levels"},{"@type":"DefinedTerm","termCode":"performance-improvement-plan","name":"Performance Improvement Plan (PIP)","description":"A Performance Improvement Plan (PIP) is a formal document that outlines specific performance deficiencies, clear improvement expectations, measurable success criteria, a timeline (typically 30-60 days), and the consequences of not meeting expectations (usually termination).\n\nIn engineering, PIPs should be: Specific (not \"improve code quality\" but \"reduce post-deployment bugs by 50% and complete code reviews within 24 hours\"), Measurable (quantitative metrics, not subjective assessments), Time-bound (30-60 days with weekly check-ins), and Supported (provide training, mentorship, and resources to help the person succeed).\n\nThe uncomfortable truth: most PIPs are termination paperwork, not genuine improvement tools. If you want someone to actually improve, address the issue in 1:1s months before a PIP becomes necessary.","url":"https://www.richardewing.io/glossary/performance-improvement-plan"},{"@type":"DefinedTerm","termCode":"employer-branding","name":"Employer Branding","description":"Employer branding is the practice of shaping how potential candidates perceive your organization as a place to work. In engineering, strong employer branding reduces time-to-hire, lowers salary premium requirements, and improves candidate quality.\n\nEffective engineering employer branding strategies: Technical blog (show the interesting problems you solve), Open-source contributions (demonstrate engineering excellence publicly), Conference talks by engineers (builds individual and organizational reputation), Transparent engineering culture (publish your engineering principles, interview process, and growth frameworks), and Glassdoor/Levels.fyi management (respond to reviews, maintain accurate compensation data).\n\nThe ROI of employer branding: companies with strong employer brands receive 50% more qualified applicants, fill positions 1-2x faster, and can offer 10% lower salaries because candidates actively want to work there.","url":"https://www.richardewing.io/glossary/employer-branding"},{"@type":"DefinedTerm","termCode":"remote-work-engineering","name":"Remote-First Engineering","description":"Remote-first engineering is an organizational model where remote work is the default, not an accommodation. All processes, tools, communication, and culture are designed for distributed teams — not co-located teams with remote exceptions.\n\nRemote-first principles: Documentation over tribal knowledge (write things down because hallway conversations don't exist), Async by default (don't require real-time participation for most decisions), Intentional culture (explicitly design social connection that happens naturally in offices), Outcome-based evaluation (measure results, not hours or Slack presence), and Timezone-aware scheduling (respect timezone boundaries, rotate meeting times).\n\nCompanies doing remote-first well: GitLab (fully remote, 2000+ employees, exhaustive handbook), Automattic (WordPress, fully remote since founding), Basecamp/37signals (remote-first pioneers), and Linear (distributed team, exceptional product velocity).","url":"https://www.richardewing.io/glossary/remote-work-engineering"},{"@type":"DefinedTerm","termCode":"burnout-engineering","name":"Engineering Burnout","description":"Engineering burnout is a state of chronic work stress characterized by emotional exhaustion, depersonalization (cynicism about work), and reduced personal accomplishment. In engineering, burnout is driven by: sustained on-call pressure, unrealistic deadlines, technical debt frustration, context switching, and organizational dysfunction.\n\nBurnout warning signs: declining code quality, increased cynicism in code reviews, withdrawal from team activities, spike in sick days, loss of interest in learning, and decreased participation in PRs and discussions.\n\nPrevention strategies: sustainable on-call rotations (follow-the-sun, max 1 week in 4), realistic sprint commitments (leave 20% buffer), hack weeks (dedicated innovation time), career development investment (learning budgets, conference attendance), and manager training (teach managers to detect and address burnout early).","url":"https://www.richardewing.io/glossary/burnout-engineering"},{"@type":"DefinedTerm","termCode":"diversity-inclusion-engineering","name":"Diversity & Inclusion in Engineering","description":"Diversity and inclusion (D&I) in engineering encompasses systemic practices for building teams that reflect diverse backgrounds, perspectives, and experiences — and creating inclusive environments where all team members can contribute fully.\n\nDiversity dimensions in engineering teams: gender, race/ethnicity, socioeconomic background, educational path (bootcamp vs CS degree vs self-taught), neurodiversity, geographic location, and career stage (new grads vs career changers vs veterans).\n\nEvidence-based practices: structured interviews with rubrics (reduce bias), diverse hiring panels, blind resume review, inclusive job descriptions (remove unnecessary requirements), and measuring representation at each career level (not just overall). McKinsey research shows teams in the top quartile for diversity outperform bottom quartile by 36% in profitability.","url":"https://www.richardewing.io/glossary/diversity-inclusion-engineering"},{"@type":"DefinedTerm","termCode":"engineering-onboarding","name":"Engineering Onboarding","description":"Engineering onboarding is the structured process of integrating new engineers into an organization and accelerating their time to first meaningful contribution. Effective onboarding reduces ramp-up time from 3-6 months (industry average) to 2-4 weeks.\n\nA structured onboarding program includes: Day 1 (laptop, accounts, environment setup — all automated), Week 1 (architecture overview, team introductions, first good-first-issue PR), Month 1 (meaningful feature contribution, on-call shadowing, mentor pairing), and Quarter 1 (independent feature ownership, team process integration, first performance check-in).\n\nKey metric: Time to First PR Merge. Top companies target < 3 days. If new hires take > 2 weeks to merge their first PR, your onboarding process has friction.","url":"https://www.richardewing.io/glossary/engineering-onboarding"},{"@type":"DefinedTerm","termCode":"tech-due-diligence-process","name":"Technical Due Diligence Process","description":"Technical due diligence is a systematic evaluation of a target company's technology assets, architecture, team, processes, and technical risks — conducted during M&A, investment, or PE acquisition. The goal is to identify hidden technical liabilities that could destroy post-acquisition value.\n\nKey assessment areas: Architecture quality (scalability, maintainability, security), Technical debt burden (using the Product Debt Index), Team capability (retention risk, key-person dependencies), DevOps maturity (deployment frequency, incident response), IP ownership (code ownership, OSS license compliance), and AI/data assets (training data rights, model portability).\n\nRichard Ewing's R&D Capital Audit framework is designed specifically for PE/VC technical due diligence, providing quantitative metrics (PDI, TID, Innovation Tax) rather than subjective assessments.","url":"https://www.richardewing.io/glossary/tech-due-diligence-process"},{"@type":"DefinedTerm","termCode":"code-audit","name":"Code Audit","description":"A code audit is a comprehensive review of a codebase to assess quality, security, maintainability, and hidden risks. In M&A contexts, code audits reveal technical liabilities that interviews and demonstrations can't surface.\n\nCode audit areas: Code quality (complexity, duplication, test coverage, documentation), Security (vulnerability scanning, authentication patterns, data handling, OWASP compliance), Architecture (coupling, cohesion, scalability, single points of failure), Dependencies (outdated packages, unmaintained libraries, license risks), and Technical debt (debt density, debt distribution, debt growth rate).\n\nAutomated tools: SonarQube (quality), Snyk/Dependabot (security), CodeClimate (maintainability). Human review is essential for: architectural assessment, business logic correctness, and security threat modeling.","url":"https://www.richardewing.io/glossary/code-audit"},{"@type":"DefinedTerm","termCode":"integration-risk","name":"Integration Risk (M&A)","description":"Integration risk is the probability and impact of technical challenges that arise when merging two companies' technology platforms, teams, and processes after an acquisition. It's the #1 reason M&A deals fail to deliver expected value.\n\nCommon integration risks: Platform incompatibility (different tech stacks that can't easily merge), Data migration complexity (schema differences, data quality issues, compliance constraints), Team attrition (key engineers leave during integration uncertainty), Process clashes (different DevOps cultures, release cadences, quality standards), and Customer disruption (downtime, feature gaps, or UX changes during migration).\n\nMitigation: Identify integration risks during due diligence, not after closing. Build a 90-day integration plan before signing. Retain key engineers with structured retention packages. Use a strangler fig pattern for platform consolidation rather than big-bang migration.","url":"https://www.richardewing.io/glossary/integration-risk"},{"@type":"DefinedTerm","termCode":"platform-consolidation","name":"Platform Consolidation","description":"Platform consolidation is the process of merging multiple technology platforms — typically after an acquisition or during a portfolio company's growth — into a unified architecture. It's one of the largest, most complex, and most frequently underestimated engineering projects.\n\nConsolidation strategies: Big-bang migration (rebuild everything at once — highest risk, fastest timeline if successful), Strangler fig (gradually replace legacy components — lowest risk, longest timeline), Parallel operation (run both platforms simultaneously — highest cost, moderate risk), and API-first integration (connect platforms via APIs without merging — lowest effort but limited consolidation).\n\nKey success factors: Executive alignment on timeline and trade-offs, dedicated migration team (not engineers splitting time), customer communication plan, rollback strategy for each migration phase, and financial model for true total cost (including productivity loss during transition).","url":"https://www.richardewing.io/glossary/platform-consolidation"},{"@type":"DefinedTerm","termCode":"earn-out","name":"Earn-Out (M&A)","description":"An earn-out is a contractual provision in M&A that makes a portion of the purchase price contingent on the acquired company achieving specified performance targets after closing. It bridges valuation gaps between buyer and seller.\n\nCommon earn-out metrics: Revenue targets (most common), EBITDA thresholds, customer retention rates, product milestones (successful migration, new features shipped), and technology integration completion.\n\nEarn-out risks: Founder misalignment (earn-out targets may conflict with acquirer's integration priorities), Measurement disputes (how revenue is attributed in combined entity), Technology control (founders need autonomy to hit targets but acquirers want integration), and Team retention (key personnel needed for earn-out may leave during integration uncertainty).","url":"https://www.richardewing.io/glossary/earn-out"},{"@type":"DefinedTerm","termCode":"key-person-dependency","name":"Key-Person Dependency","description":"Key-person dependency (also: bus factor = 1) exists when critical knowledge, skills, or relationships are concentrated in a single individual. If that person leaves, gets sick, or becomes unavailable, the organization suffers disproportionate disruption.\n\nIn technology: a single engineer who understands the legacy billing system, the architect who designed the core platform, the DevOps engineer who manages production infrastructure without documentation. In M&A due diligence, key-person dependencies are critical risk factors.\n\nMitigation: documentation requirements (architecture decision records, runbooks), knowledge sharing (pair programming, tech talks), cross-training programs, and retention packages for identified key persons during M&A.","url":"https://www.richardewing.io/glossary/key-person-dependency"},{"@type":"DefinedTerm","termCode":"oss-license-risk","name":"Open-Source License Risk","description":"Open-source license risk refers to legal and financial exposure from using open-source software in ways that violate license terms. In M&A due diligence, OSS license compliance is a critical assessment area because violations can force code rewrites, public disclosure of proprietary code, or litigation.\n\nRisk levels by license type: Permissive (MIT, Apache 2.0, BSD) — minimal risk, allows commercial use with attribution. Weak copyleft (LGPL, MPL) — moderate risk, requires modifications to the library itself to be shared. Strong copyleft (GPL, AGPL) — high risk, may require releasing derivative works under the same license. AGPL is the highest risk for SaaS: if AGPL code is used in a network service, the entire application may need to be open-sourced.\n\nMitigation: SBOM (Software Bill of Materials) generation (tools: Syft, FOSSA, Snyk), license scanning in CI/CD pipeline, and OSS policy that prohibits copyleft licenses without legal review.","url":"https://www.richardewing.io/glossary/oss-license-risk"},{"@type":"DefinedTerm","termCode":"sbom","name":"SBOM (Software Bill of Materials)","description":"A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components, libraries, dependencies, and their versions used in a software product. Think of it as the \"ingredient label\" for software — required for security compliance, license compliance, and supply chain risk management.\n\nSBOM formats: SPDX (Linux Foundation standard), CycloneDX (OWASP standard). Executive Order 14028 (2021) requires SBOMs for software sold to the US government. Many enterprise buyers now require SBOMs as procurement prerequisites.\n\nSBOM use cases: Vulnerability management (quickly identify if a CVE affects your dependencies — like Log4Shell), License compliance (ensure no GPL/AGPL contamination in proprietary software), Supply chain security (identify single-maintainer dependencies), and M&A due diligence (comprehensive view of technology dependencies).","url":"https://www.richardewing.io/glossary/sbom"},{"@type":"DefinedTerm","termCode":"technology-valuation","name":"Technology Valuation","description":"Technology valuation is the process of assigning economic value to a company's technology assets — code, architecture, data, AI models, and engineering team capability. In M&A, technology valuation determines how much of the purchase price is attributable to technology (vs. revenue, brand, or customer relationships).\n\nValuation approaches: Replacement cost (what would it cost to rebuild from scratch?), Income approach (what revenue does the technology enable?), Market approach (what have comparable technology assets sold for?), and Richard Ewing's PDI-adjusted valuation (discount technology value based on technical debt burden and proximity to Technical Insolvency Date).\n\nCommon errors: Overvaluing code (code depreciates rapidly — the value is in architecture and team), ignoring technical debt (a platform worth $50M in replacement cost but requiring $15M in immediate debt remediation is worth $35M), and conflating team value with technology value (if key engineers leave, technology value drops dramatically).","url":"https://www.richardewing.io/glossary/technology-valuation"},{"@type":"DefinedTerm","termCode":"acqui-hire","name":"Acqui-Hire","description":"An acqui-hire is an acquisition made primarily to recruit the target company's engineering team rather than to acquire the product, technology, or customers. The purchase price is essentially a signing bonus distributed across the team, plus the cost of the acquisition process.\n\nAcqui-hire economics: Typical purchase price range of $1-3M per engineer being acquired. Compare this to: recruiting cost per senior engineer ($50-100K), ramp-up time value ($150-250K in lost productivity during onboarding), and failure risk (40% of external hires don't work out within 18 months). Acqui-hires can be cost-effective for acquiring pre-formed, high-performing teams.\n\nRisks: Team may leave after retention cliff (typically 2-3 year vesting), cultural integration challenges, and technology being acquired may require maintenance resources even if it's not the primary acquisition driver.","url":"https://www.richardewing.io/glossary/acqui-hire"},{"@type":"DefinedTerm","termCode":"rest-api","name":"REST API","description":"REST (Representational State Transfer) is an architectural style for designing networked applications. RESTful APIs use HTTP methods (GET, POST, PUT, DELETE) to perform CRUD operations on resources identified by URLs. REST has been the dominant web API paradigm since the mid-2000s.\n\nREST principles: Stateless (each request contains all information needed), Client-server separation, Uniform interface (resource-based URLs, standard HTTP methods), and Layered system (intermediaries like caches and load balancers). Richardson Maturity Model levels: Level 0 (single endpoint), Level 1 (resources), Level 2 (HTTP verbs), Level 3 (hypermedia/HATEOAS).","url":"https://www.richardewing.io/glossary/rest-api"},{"@type":"DefinedTerm","termCode":"graphql","name":"GraphQL","description":"GraphQL is a query language and runtime for APIs, developed by Facebook (2012, open-sourced 2015). Unlike REST, where the server defines the response structure, GraphQL lets clients specify exactly which fields they need, reducing over-fetching and under-fetching.\n\nKey features: Single endpoint (all queries hit one URL), Client-specified queries (request exactly the data you need), Strong typing (schema defines all types and relationships), Real-time subscriptions (WebSocket-based live updates), and Introspection (API is self-documenting).\n\nTrade-offs: More complex server implementation, caching is harder (no URL-based caching), potential for expensive queries (N+1 problems, unbounded depth), and requires additional security measures (query depth/complexity limiting).","url":"https://www.richardewing.io/glossary/graphql"},{"@type":"DefinedTerm","termCode":"webhooks","name":"Webhooks","description":"Webhooks are HTTP callbacks — automated messages sent from one application to another when a specific event occurs. Instead of polling (repeatedly asking \"did anything change?\"), webhooks push notifications in real-time.\n\nWebhook pattern: 1) Consumer registers a callback URL with the provider, 2) Event occurs in the provider system, 3) Provider sends an HTTP POST to the callback URL with event data, 4) Consumer processes the event and responds with 200 OK.\n\nBest practices: Verify webhook signatures (prevent spoofing), implement idempotency (handle duplicate deliveries), respond quickly (< 5 seconds) and process async, implement retry logic (exponential backoff), and log all webhook events for debugging.","url":"https://www.richardewing.io/glossary/webhooks"},{"@type":"DefinedTerm","termCode":"api-versioning","name":"API Versioning","description":"API versioning is the practice of maintaining multiple versions of an API simultaneously to support existing clients while evolving the API for new capabilities. It's the contract management layer of API development.\n\nVersioning strategies: URL path versioning (/v1/users, /v2/users — most common, most explicit), Query parameter versioning (?version=2 — flexible but less discoverable), Header versioning (Accept: application/vnd.api.v2+json — clean URLs, harder to test), and Content negotiation (different media types for different versions).\n\nVersioning policy: how long are old versions supported? Industry standard: 12-24 months of support after deprecation notice. Breaking changes (field removal, type changes, behavior changes) always require a new version.","url":"https://www.richardewing.io/glossary/api-versioning"},{"@type":"DefinedTerm","termCode":"idempotency","name":"Idempotency","description":"An operation is idempotent if performing it multiple times produces the same result as performing it once. In distributed systems, idempotency is critical for handling retries safely — network failures and timeouts mean requests may be sent multiple times.\n\nHTTP method idempotency: GET (always idempotent), PUT (idempotent — setting a value to X twice = setting it once), DELETE (idempotent — deleting twice = deleting once), POST (NOT idempotent by default — creating a resource twice creates two resources).\n\nImplementing idempotency: Idempotency keys (client sends a unique ID with each request; server deduplicates by key), Last-write-wins (for update operations), and Database constraints (unique constraints prevent duplicate creation). Stripe uses idempotency keys for payment API — critical for preventing double charges.","url":"https://www.richardewing.io/glossary/idempotency"},{"@type":"DefinedTerm","termCode":"event-driven-architecture","name":"Event-Driven Architecture","description":"Event-driven architecture (EDA) is a design pattern where system components communicate by producing and consuming events — asynchronous notifications that something happened. Instead of direct request-response calls, services emit events that other services react to.\n\nPatterns: Event notification (simple notification that something happened), Event-carried state transfer (event contains the data, not just a reference), Event sourcing (store all events as the source of truth, derive current state from event history), and CQRS (separate read and write models, connected by events).\n\nTools: Apache Kafka (distributed event streaming), RabbitMQ (message broker), AWS SNS/SQS (managed messaging), and NATS (lightweight messaging). EDA enables loose coupling, scalability, and resilience — but adds complexity in debugging and maintaining event ordering.","url":"https://www.richardewing.io/glossary/event-driven-architecture"},{"@type":"DefinedTerm","termCode":"sdk","name":"SDK (Software Development Kit)","description":"An SDK (Software Development Kit) is a packaged set of tools, libraries, documentation, and code samples that enables developers to build applications for a specific platform, framework, or API. SDKs abstract away the complexity of raw API calls, providing language-native interfaces.\n\nSDK components: Client libraries (language-specific wrappers for API calls), Authentication helpers (handle OAuth, API keys, token refresh), Error handling (typed exceptions, retry logic), Documentation (getting-started guides, API reference), and Code samples (working examples for common use cases).\n\nSDK quality is a competitive differentiator for platform businesses. Stripe, Twilio, and AWS succeed partly because their SDKs are excellent — reducing time-to-first-API-call from hours to minutes.","url":"https://www.richardewing.io/glossary/sdk"},{"@type":"DefinedTerm","termCode":"oauth","name":"OAuth 2.0","description":"OAuth 2.0 is an authorization framework that enables third-party applications to access user resources without exposing credentials. It's the industry standard for API authorization — powering \"Sign in with Google,\" \"Connect to GitHub,\" and virtually all third-party API integrations.\n\nOAuth 2.0 flows: Authorization Code (most secure, for server-side apps), PKCE (secure extension for mobile/SPA apps), Client Credentials (machine-to-machine, no user context), and Device Code (for devices without browsers, like CLI tools and TVs).\n\nKey concepts: Access tokens (short-lived, authorize API access), Refresh tokens (long-lived, obtain new access tokens), Scopes (permissions requested), and OIDC (OpenID Connect, identity layer on top of OAuth for authentication).","url":"https://www.richardewing.io/glossary/oauth"},{"@type":"DefinedTerm","termCode":"api-rate-design","name":"API Design Principles","description":"API design principles are guidelines for creating APIs that are intuitive, consistent, and developer-friendly. Good API design reduces integration time, lowers support burden, and increases platform adoption.\n\nCore principles: Resource-oriented design (nouns in URLs: /users, /orders — not verbs: /getUsers), Consistent naming conventions (camelCase or snake_case, pick one), Meaningful HTTP status codes (200 success, 201 created, 400 bad request, 404 not found, 429 rate limited), Pagination for collections, Filtering and sorting via query parameters, and Comprehensive error responses (error code, message, documentation link).\n\nAPI design review checklist: Is it intuitive (can a developer guess the endpoint without docs)? Is it consistent (same patterns everywhere)? Is it secure (authentication, authorization, input validation)? Is it evolvable (versioning strategy, backward compatibility)?","url":"https://www.richardewing.io/glossary/api-rate-design"},{"@type":"DefinedTerm","termCode":"microservices-communication","name":"Microservices Communication Patterns","description":"Microservices communication patterns define how distributed services exchange data and coordinate work. Choosing the right pattern for each interaction is critical for system reliability, performance, and maintainability.\n\nSynchronous patterns: REST/gRPC (request-response, simple but couples services temporally), Service mesh (manages inter-service communication with retries, circuit breaking, and observability), and API gateway (aggregates multiple service calls into single client response).\n\nAsynchronous patterns: Message queues (point-to-point: RabbitMQ, SQS), Event streams (pub-sub: Kafka, EventBridge), and Saga pattern (distributed transactions across services using compensating actions).\n\nPattern selection: Use sync for queries needing immediate response. Use async for commands that can be eventually consistent. Use sagas for distributed transactions. Use event sourcing for audit-critical operations.","url":"https://www.richardewing.io/glossary/microservices-communication"},{"@type":"DefinedTerm","termCode":"test-pyramid","name":"Test Pyramid","description":"The test pyramid is a testing strategy that prescribes many fast, cheap unit tests at the base, fewer integration tests in the middle, and a small number of slow, expensive end-to-end tests at the top. Coined by Mike Cohn, the pyramid shape reflects the ideal ratio: many small tests, few large tests.\n\nLayers: Unit tests (test individual functions/classes in isolation, milliseconds, thousands of them), Integration tests (test component interactions, seconds, hundreds), End-to-end tests (test full user flows through the real system, minutes, dozens), and Manual/exploratory tests (human verification, rare, for subjective quality).\n\nThe anti-pattern is the \"ice cream cone\" — many E2E tests, few unit tests. This creates slow, flaky, expensive test suites that developers avoid running. The test pyramid keeps the feedback loop fast.","url":"https://www.richardewing.io/glossary/test-pyramid"},{"@type":"DefinedTerm","termCode":"unit-testing","name":"Unit Testing","description":"Unit testing is the practice of testing individual functions, methods, or classes in isolation from the rest of the system. Unit tests are the foundation of the test pyramid — fast (milliseconds), focused (one assertion per test), and numerous (thousands in a mature codebase).\n\nUnit test characteristics (FIRST): Fast (run in milliseconds), Independent (no shared state between tests), Repeatable (same result every time), Self-validating (pass/fail without human inspection), and Timely (written alongside or before the code).\n\nTools by language: JavaScript (Jest, Vitest), Python (pytest), Java (JUnit), Go (built-in testing package), Rust (built-in #[test]). Test coverage targets: 80%+ line coverage for business logic, 90%+ for critical financial/security code.","url":"https://www.richardewing.io/glossary/unit-testing"},{"@type":"DefinedTerm","termCode":"integration-testing","name":"Integration Testing","description":"Integration testing verifies that multiple components work correctly together — testing the interfaces and interactions between modules, services, databases, and external APIs. Unlike unit tests (isolated) or E2E tests (full system), integration tests focus on the boundaries between components.\n\nTypes: Component integration (testing a service with its database), API integration (testing client-server contract), Third-party integration (testing with external APIs using mocks or sandboxes), and Data integration (testing data flows between systems).\n\nTools: Testcontainers (spin up real databases/services in Docker for tests), Pact (contract testing for APIs), WireMock (HTTP mock server), and database-specific test utilities. Integration tests typically run in CI/CD, not on developer machines.","url":"https://www.richardewing.io/glossary/integration-testing"},{"@type":"DefinedTerm","termCode":"e2e-testing","name":"End-to-End (E2E) Testing","description":"End-to-end testing verifies complete user flows through the entire application — from UI interaction to backend processing to database persistence and back. E2E tests simulate real user behavior in a real (or staging) environment.\n\nTools: Playwright (Microsoft, cross-browser, fastest), Cypress (developer-friendly, single browser), Selenium (legacy, broadest browser support), and Puppeteer (Chrome/Chromium only).\n\nE2E testing best practices: Test critical paths only (login, checkout, core workflows), keep E2E tests stable (avoid flaky selectors, use data-testid attributes), run in CI/CD (not blocking development), and limit quantity (10-50 E2E tests, not 500). Visual regression testing (Percy, Chromatic) catches UI changes that functional tests miss.","url":"https://www.richardewing.io/glossary/e2e-testing"},{"@type":"DefinedTerm","termCode":"shift-left-testing","name":"Shift-Left Testing","description":"Shift-left testing is the practice of moving testing activities earlier in the software development lifecycle — from post-development QA to during and before development. The principle: the earlier you find a bug, the cheaper it is to fix.\n\nShift-left techniques: TDD (write tests before code), Static analysis (catch bugs without running code — TypeScript, ESLint, SonarQube), Code review (human review before merge), Pre-commit hooks (run linting and unit tests before commit), CI pipeline (run tests on every push), and Security scanning (SAST/DAST in CI/CD).\n\nBug cost multiplier by phase: requirements (1x), design (5x), development (10x), testing (20x), production (100x). A bug caught in development costs 10% of what it costs in production.","url":"https://www.richardewing.io/glossary/shift-left-testing"},{"@type":"DefinedTerm","termCode":"tdd","name":"Test-Driven Development (TDD)","description":"Test-Driven Development (TDD) is a development methodology where you write a failing test before writing the code to make it pass. The cycle is Red → Green → Refactor: 1) Write a test that fails (Red), 2) Write the minimum code to make it pass (Green), 3) Refactor the code while keeping tests passing.\n\nTDD benefits: Forces you to think about the interface before implementation, produces high test coverage naturally, catches regressions immediately, and creates living documentation (tests describe expected behavior). TDD works best for business logic and algorithms but may be overkill for UI code or rapid prototyping.\n\nTDD skepticism is common but misguided: the initial velocity decrease (writing tests first feels slower) is offset by dramatically reduced debugging time, fewer production bugs, and fearless refactoring ability.","url":"https://www.richardewing.io/glossary/tdd"},{"@type":"DefinedTerm","termCode":"contract-testing","name":"Contract Testing","description":"Contract testing verifies that the interactions between service providers and consumers conform to a shared contract (API specification). Instead of testing the full integration, contract tests verify the interface agreement — what data shapes, status codes, and behaviors each side expects.\n\nTools: Pact (consumer-driven contract testing), Spring Cloud Contract (provider-side contracts), and OpenAPI-based contract testing. Pact workflow: 1) Consumer writes a test defining expected API behavior, 2) Pact generates a contract file, 3) Provider verifies it can satisfy the contract, 4) Both sides run independently.\n\nContract testing bridges the gap between unit tests (too isolated) and integration tests (too coupled). It enables independent service deployment — teams can deploy without coordinating with every consumer.","url":"https://www.richardewing.io/glossary/contract-testing"},{"@type":"DefinedTerm","termCode":"regression-testing","name":"Regression Testing","description":"Regression testing verifies that previously working functionality still works after code changes. It catches \"regressions\" — bugs introduced by new code that break existing behavior. Regression testing is the safety net that enables continuous deployment.\n\nApproaches: Automated regression suite (run the full test suite on every deployment), Selective regression (run only tests affected by changed code — tools like Jest --changedSince), Visual regression (screenshot comparison to catch UI changes — Percy, Chromatic), and Smoke testing (quick subset of critical tests run immediately after deployment).\n\nRegression testing ROI: Without regression tests, every deployment requires manual verification of everything that could break. With regression tests, verification is automated, allowing daily (or hourly) deployments with confidence.","url":"https://www.richardewing.io/glossary/regression-testing"},{"@type":"DefinedTerm","termCode":"visual-regression-testing","name":"Visual Regression Testing","description":"Visual regression testing captures screenshots of UI components or pages and compares them pixel-by-pixel against baseline images to detect unintended visual changes. It catches CSS regressions, layout shifts, font changes, and responsive design issues that functional tests miss.\n\nTools: Percy (BrowserStack), Chromatic (Storybook), BackstopJS (open-source), and Playwright's built-in screenshot comparison. Workflow: 1) Capture baseline screenshots, 2) Run changed code, 3) Capture new screenshots, 4) Compare pixel-by-pixel, 5) Flag differences for human review.\n\nVisual regression testing is especially valuable for: design systems (ensuring consistency across components), responsive design (testing across breakpoints), and theme changes (verifying dark mode, accessibility modes don't break).","url":"https://www.richardewing.io/glossary/visual-regression-testing"},{"@type":"DefinedTerm","termCode":"load-testing","name":"Load Testing & Performance Testing","description":"Load testing measures how a system performs under expected and peak traffic conditions. It identifies performance bottlenecks, memory leaks, and scalability limits before they affect real users.\n\nTypes: Load testing (expected traffic volume), Stress testing (beyond expected capacity — find the breaking point), Spike testing (sudden traffic surge), Soak testing (sustained load over hours — find memory leaks), and Chaos testing (failure injection under load).\n\nTools: k6 (Grafana, modern, JavaScript-based), Locust (Python-based, distributed), JMeter (Java-based, GUI-heavy), and Gatling (Scala-based, CI/CD friendly). Key metrics: response time (p50, p95, p99), throughput (requests/second), error rate, and resource utilization (CPU, memory, connections).","url":"https://www.richardewing.io/glossary/load-testing"},{"@type":"DefinedTerm","termCode":"domain-driven-design","name":"Domain-Driven Design (DDD)","description":"Domain-Driven Design is a software design approach that centers the architecture around the business domain, using a shared language (ubiquitous language) between developers and domain experts. Created by Eric Evans, DDD structures software to mirror business processes.\n\nKey concepts: Bounded Context (clear boundary within which a domain model is consistent), Aggregate (cluster of entities treated as a single unit for data changes), Entity (object defined by identity, not attributes), Value Object (immutable object defined by attributes), Domain Event (something that happened in the domain that domain experts care about), and Repository (abstraction for data access).\n\nDDD is especially valuable for complex business domains where the cost of misunderstanding the domain outweighs the cost of additional architectural complexity.","url":"https://www.richardewing.io/glossary/domain-driven-design"},{"@type":"DefinedTerm","termCode":"event-sourcing","name":"Event Sourcing","description":"Event sourcing stores every state change as an immutable event, building current state by replaying the event history. Instead of storing \"the account balance is $500,\" you store every deposit and withdrawal. Current state is derived by replaying events in order.\n\nBenefits: Complete audit trail (every change is recorded), Time travel (reconstruct state at any point in time), Event replay (reprocess events with new business logic), and Natural for distributed systems (events are the communication mechanism).\n\nChallenges: Eventual consistency (reads may be stale), Event schema evolution (changing event formats over time), and Storage growth (events accumulate forever — use snapshots for performance).","url":"https://www.richardewing.io/glossary/event-sourcing"},{"@type":"DefinedTerm","termCode":"cqrs","name":"CQRS (Command Query Responsibility Segregation)","description":"CQRS separates the read model (queries) from the write model (commands) into distinct data stores optimized for each purpose. Writes go to a normalized, consistent store. Reads come from denormalized, fast-query optimized stores. Events synchronize the two.\n\nBenefits: Read and write stores can be independently scaled, each store can be optimized for its use case (normalized for writes, denormalized for reads), enables different consistency models (strong consistency for writes, eventual for reads).\n\nCQRS is often paired with event sourcing: commands produce domain events (write side), events are projected into read-optimized views (read side). This combination enables auditability, scalability, and flexibility.","url":"https://www.richardewing.io/glossary/cqrs"},{"@type":"DefinedTerm","termCode":"saga-pattern","name":"Saga Pattern","description":"The saga pattern manages distributed transactions across multiple microservices using a sequence of local transactions, each with a compensating action for rollback. Unlike traditional ACID transactions (which require a central coordinator), sagas use eventual consistency and compensation.\n\nSaga types: Choreography (each service emits events, other services react — no central coordinator, less coupling, harder to track), and Orchestration (a central saga orchestrator directs the flow — easier to understand, single point of coordination).\n\nExample: Order saga — 1) Create order (compensating: cancel order), 2) Reserve inventory (comp: release inventory), 3) Charge payment (comp: refund payment), 4) Ship order (comp: cancel shipment). If step 3 fails, compensating actions for steps 1-2 execute in reverse order.","url":"https://www.richardewing.io/glossary/saga-pattern"},{"@type":"DefinedTerm","termCode":"strangler-fig-pattern","name":"Strangler Fig Pattern","description":"The strangler fig pattern gradually replaces a legacy system by incrementally building new functionality around the old system, routing traffic from legacy to new components one piece at a time. Named after fig trees that grow around host trees, eventually replacing them entirely.\n\nProcess: 1) Identify a piece of legacy functionality to replace, 2) Build the replacement as a new service, 3) Route traffic for that functionality to the new service (using a proxy), 4) Verify the new service works correctly, 5) Retire the legacy code for that functionality, 6) Repeat until the legacy system is fully replaced.\n\nAdvantages over big-bang migration: lower risk (each step is small and reversible), continuous delivery (new features ship alongside migration), and incremental validation (prove the approach works before committing fully).","url":"https://www.richardewing.io/glossary/strangler-fig-pattern"},{"@type":"DefinedTerm","termCode":"hexagonal-architecture","name":"Hexagonal Architecture (Ports & Adapters)","description":"Hexagonal architecture (also called Ports and Adapters) structures applications so that the core business logic is isolated from external concerns (databases, APIs, UI). The core defines \"ports\" (interfaces) and external concerns implement \"adapters\" that plug into those ports.\n\nStructure: Core domain (business logic, no dependencies on frameworks or infrastructure), Ports (interfaces defined by the core — what it needs from the outside world), and Adapters (implementations of ports for specific technologies — PostgreSQL adapter, REST adapter, CLI adapter).\n\nBenefits: Testability (test core logic without databases or APIs — just mock the ports), Technology independence (swap databases, APIs, or UI frameworks without changing business logic), and Clear boundaries (forces separation between business rules and infrastructure).","url":"https://www.richardewing.io/glossary/hexagonal-architecture"},{"@type":"DefinedTerm","termCode":"twelve-factor-app","name":"Twelve-Factor App","description":"The Twelve-Factor App methodology (by Adam Wiggins/Heroku) defines 12 principles for building scalable, maintainable cloud-native applications:\n\n1. Codebase (one codebase tracked in VCS, many deploys)\n2. Dependencies (explicitly declare and isolate)\n3. Config (store in environment variables)\n4. Backing services (treat as attached resources)\n5. Build, release, run (strictly separate stages)\n6. Processes (stateless, share-nothing)\n7. Port binding (export services via port binding)\n8. Concurrency (scale out via process model)\n9. Disposability (fast startup, graceful shutdown)\n10. Dev/prod parity (keep environments similar)\n11. Logs (treat as event streams)\n12. Admin processes (run as one-off processes)\n\nThese principles are the foundation of modern cloud-native development. Applications that follow twelve-factor principles deploy easily to any cloud platform.","url":"https://www.richardewing.io/glossary/twelve-factor-app"},{"@type":"DefinedTerm","termCode":"modular-monolith","name":"Modular Monolith","description":"A modular monolith is a single deployable application that is internally structured as well-defined, loosely coupled modules with clear boundaries. It combines the operational simplicity of a monolith with the organizational benefits of microservices.\n\nKey characteristics: Deployed as one unit (single process, single database), but internally organized as independent modules with defined APIs between them. Each module owns its data, has its own domain model, and communicates with other modules through explicit interfaces — not shared database tables.\n\nWhen to choose: Teams < 50 engineers, simpler operational requirements, when the overhead of microservices (service mesh, distributed tracing, per-service CI/CD) isn't justified. Many successful companies (Shopify, GitHub, Basecamp) run modular monoliths at massive scale.","url":"https://www.richardewing.io/glossary/modular-monolith"},{"@type":"DefinedTerm","termCode":"usage-based-pricing","name":"Usage-Based Pricing","description":"Usage-based pricing (UBP) charges customers based on how much they use the product — API calls, compute hours, data processed, active users, or messages sent. It aligns cost with value delivered, making adoption frictionless (start free, scale costs with usage).\n\nExamples: AWS (compute hours), Twilio (API calls), Snowflake (compute credits), Stripe (transaction percentage). Revenue grows with customer usage, creating natural expansion revenue without sales intervention.\n\nChallenges: Revenue unpredictability (usage fluctuates), pricing complexity (customers struggle to forecast costs), and potential for bill shock (unexpected usage spikes). Hybrid models (base subscription + usage overage) address these concerns.","url":"https://www.richardewing.io/glossary/usage-based-pricing"},{"@type":"DefinedTerm","termCode":"seat-based-pricing","name":"Seat-Based Pricing","description":"Seat-based pricing charges per user who accesses the product. It's the most common SaaS pricing model — simple to understand, predictable for both vendor and customer, and natural for products where value scales with team adoption.\n\nPricing tiers typically segment by feature access: Free (individual use, limited features), Pro ($15-50/seat/month, full features), Team ($25-100/seat/month, collaboration features + admin), and Enterprise (custom pricing, SSO, compliance, dedicated support).\n\nChallenges: Seat count gaming (sharing logins), friction for expansion (asking for budget per new seat), and misalignment when value doesn't scale linearly with users (one admin user vs. one power user pay the same).","url":"https://www.richardewing.io/glossary/seat-based-pricing"},{"@type":"DefinedTerm","termCode":"reverse-trial","name":"Reverse Trial","description":"A reverse trial starts users on the full premium product (not freemium), then downgrades to free tier after the trial period. Unlike traditional trials (upgrade to unlock features), reverse trials give users the best experience first, then let them choose whether to pay to keep it.\n\nWhy it works: Users experience premium features before forming free-tier habits. The loss aversion of downgrading (losing features you're already using) is psychologically stronger than the desire to upgrade (gaining features you haven't tried). Reverse trials typically convert 2-3x better than traditional free trials.\n\nCompanies using reverse trials: Ahrefs, Loom (originally), Notion (premium features for first 7 days). Best for products where premium features are clearly valuable once experienced.","url":"https://www.richardewing.io/glossary/reverse-trial"},{"@type":"DefinedTerm","termCode":"freemium","name":"Freemium Model","description":"Freemium offers a permanently free product tier alongside paid premium tiers. The free tier serves as a massive top-of-funnel acquisition channel, while paid tiers capture revenue from power users and teams.\n\nFreemium design principles: Free tier must be genuinely useful (not crippled — users must love it), clear upgrade triggers (features or limits that naturally correlate with willingness to pay), and low friction upgrade path (instant, self-serve, no sales call required).\n\nFreemium economics: Typical conversion rate 2-5% from free to paid. This means you need massive free-tier adoption to generate meaningful revenue. CAC for freemium is near-zero, but you bear the infrastructure cost of free users.","url":"https://www.richardewing.io/glossary/freemium"},{"@type":"DefinedTerm","termCode":"land-and-expand","name":"Land & Expand","description":"Land and expand is a sales strategy that starts with a small initial deal (the \"land\") and grows revenue within the account over time through upsells, cross-sells, and seat expansion (the \"expand\"). It reduces initial sales friction by requiring smaller upfront commitments.\n\nLand phase: Start with one team, one use case, or one product. Price to minimize friction — may even be free or heavily discounted. Goal: prove value with a small group.\n\nExpand phase: Demonstrate ROI to the initial team. Expand to adjacent teams. Upsell to premium features. Cross-sell additional products. Enterprise buyers are more likely to expand an existing vendor relationship than evaluate a new vendor.\n\nKey metric: Net Revenue Retention (NRR). World-class NRR (>130%) means expansion revenue from existing customers exceeds revenue lost from churn — the business grows even without new customers.","url":"https://www.richardewing.io/glossary/land-and-expand"},{"@type":"DefinedTerm","termCode":"value-based-pricing","name":"Value-Based Pricing","description":"Value-based pricing sets the price based on the value the product delivers to the customer, not on the cost to produce it or competitive pricing. If your product saves a customer $1M/year, charging $100K/year is value-based pricing — regardless of whether it costs you $10K or $100K to deliver.\n\nDetermining value: Quantify the customer outcome (revenue generated, cost saved, risk reduced, time saved), apply a capture ratio (typically 10-25% of value created), and validate through willingness-to-pay research.\n\nValue-based pricing requires understanding your customer's economics deeply. Richard Ewing's advisory services are value-based: a $15K R&D Capital Audit that identifies $2M in wasted engineering spend delivers 100x ROI — making the price trivially easy to justify.","url":"https://www.richardewing.io/glossary/value-based-pricing"},{"@type":"DefinedTerm","termCode":"pricing-psychology","name":"Pricing Psychology","description":"Pricing psychology leverages cognitive biases and behavioral economics to influence purchasing decisions. Pricing is not a math problem — it's a psychology problem.\n\nKey principles: Anchoring (show a high price first to make the actual price feel reasonable — \"Enterprise: $500/mo vs. Pro: $99/mo\"), Decoy effect (add a clearly inferior option to make the target option look better — \"Basic $29, Standard $49, Premium $59\" — Standard is the decoy making Premium look like better value), Price ending (prices ending in 7 or 9 convert better — $97 vs $100), Charm pricing ($99 vs $100 — the left digit changes), Bundling (multiple items feel like better value than buying individually), and Three-tier pricing (most customers choose the middle option — make it your target tier).","url":"https://www.richardewing.io/glossary/pricing-psychology"},{"@type":"DefinedTerm","termCode":"monetization-model","name":"Monetization Model","description":"A monetization model defines how a product or service generates revenue. For technology businesses, common models include:\n\n**SaaS Subscription**: Recurring fee for access (most common). Revenue is predictable. Examples: Salesforce, Slack.\n\n**Usage-Based**: Pay per consumption (API calls, compute, data). Revenue scales with usage. Examples: AWS, Twilio.\n\n**Marketplace/Transaction Fee**: Take a percentage of transactions facilitated. Revenue scales with GMV. Examples: Stripe, Airbnb, Uber.\n\n**Freemium + Premium**: Free core product, paid premium features. Revenue from conversion. Examples: Notion, Figma.\n\n**Advisory/Services**: Expertise as a service, billed hourly or project-based. High margin per engagement. Examples: McKinsey, Richard Ewing advisory.\n\n**Licensing/White-Label**: License technology to other companies. One-time or recurring fee. Examples: Palantir, enterprise software.\n\n**Content/Education**: Paid courses, certifications, or gated content. Examples: Reforge, Maven, Udemy.","url":"https://www.richardewing.io/glossary/monetization-model"},{"@type":"DefinedTerm","termCode":"pci-dss","name":"PCI DSS","description":"PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements for organizations that handle credit card data. Compliance is mandatory for any company that processes, stores, or transmits cardholder data.\n\nPCI DSS has 12 core requirements organized into 6 goals: Build secure networks (firewalls, change defaults), Protect cardholder data (encryption, access control), Maintain vulnerability management (antivirus, secure development), Implement access controls (restrict access, unique IDs), Monitor and test networks (logging, testing), and Maintain security policy (documentation).\n\nCompliance levels: Level 1 (>6M transactions/year — requires annual on-site audit), Level 2 (1-6M — SAQ + quarterly scan), Level 3 (20K-1M e-commerce — SAQ + quarterly scan), Level 4 (<20K — SAQ). Most SaaS companies use Stripe or similar PSPs to reduce PCI scope — the PSP handles card data, minimizing the company's compliance burden.","url":"https://www.richardewing.io/glossary/pci-dss"},{"@type":"DefinedTerm","termCode":"hipaa","name":"HIPAA","description":"HIPAA (Health Insurance Portability and Accountability Act) is US legislation that protects the privacy and security of health information. Any organization that creates, receives, maintains, or transmits Protected Health Information (PHI) must comply.\n\nKey rules: Privacy Rule (defines how PHI can be used and disclosed), Security Rule (requires administrative, physical, and technical safeguards for electronic PHI), Breach Notification Rule (requires notification within 60 days of discovering a breach), and Enforcement Rule (penalties for violations).\n\nFor technology companies: HIPAA requires encryption at rest and in transit, access controls and audit logging, Business Associate Agreements (BAAs) with all vendors handling PHI, incident response procedures, and regular risk assessments. Cloud providers (AWS, GCP, Azure) offer HIPAA-eligible services with BAAs.","url":"https://www.richardewing.io/glossary/hipaa"},{"@type":"DefinedTerm","termCode":"ai-act","name":"EU AI Act","description":"The EU AI Act is the world's first comprehensive legal framework for artificial intelligence, adopted in 2024 with enforcement beginning in 2025-2026. It classifies AI systems by risk level and imposes corresponding requirements.\n\nRisk levels: Unacceptable risk (banned — social scoring, real-time biometric identification), High risk (heavily regulated — AI in hiring, credit scoring, healthcare, law enforcement), Limited risk (transparency requirements — chatbots must disclose they're AI), and Minimal risk (no requirements — spam filters, video games).\n\nHigh-risk AI requirements: Risk management system, data governance and quality, technical documentation, record-keeping and logging, transparency to users, human oversight, accuracy and robustness, and cybersecurity. Penalties: up to €35M or 7% of global annual turnover.","url":"https://www.richardewing.io/glossary/ai-act"},{"@type":"DefinedTerm","termCode":"data-residency","name":"Data Residency","description":"Data residency requirements mandate that data about a country's citizens must be stored and/or processed within that country's borders. These requirements are driven by privacy regulations, national security concerns, and data sovereignty principles.\n\nCountries with data residency laws: Russia (strict localization), China (Critical Information Infrastructure), India (proposed data localization), Brazil (LGPD), Germany (strict interpretation of GDPR for certain data), and Australia (health data). The EU generally allows data to flow within the EEA but restricts transfers outside without adequate protections (GDPR Chapter V).\n\nFor SaaS companies: Data residency requires multi-region deployment, region-specific data routing, and the ability to guarantee where specific customer data is stored and processed. Cloud providers offer region-specific services (AWS regions, Azure regions, GCP regions) to enable compliance.","url":"https://www.richardewing.io/glossary/data-residency"},{"@type":"DefinedTerm","termCode":"model-cards","name":"Model Cards (AI Transparency)","description":"Model cards are structured documentation for machine learning models that provide transparency about a model's purpose, performance, limitations, and ethical considerations. Introduced by Mitchell et al. (Google, 2019), model cards are becoming a compliance requirement under the EU AI Act.\n\nModel card contents: Model details (architecture, training data, intended use), Performance metrics (accuracy across different demographics, failure modes), Limitations (known biases, edge cases, out-of-distribution behavior), Ethical considerations (potential harms, mitigation strategies), and Maintenance (update frequency, versioning, responsible team).\n\nModel cards serve multiple audiences: Regulators (compliance documentation), Users (understand model limitations), Developers (know when and how to use the model), and Society (transparency about AI systems that affect people).","url":"https://www.richardewing.io/glossary/model-cards"},{"@type":"DefinedTerm","termCode":"section-230","name":"Section 230","description":"Section 230 of the Communications Decency Act (1996) provides legal immunity to online platforms for content posted by users. The key provision: \"No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.\"\n\nSection 230 enables: Social media platforms (not liable for user posts), Review sites (not liable for user reviews), and Marketplace platforms (not liable for seller content). Without Section 230, every platform would face crippling liability for user-generated content.\n\nAI implications: Section 230's application to AI-generated content is actively debated. When an AI chatbot generates harmful content, is the platform protected by Section 230? Courts are currently divided. The distinction between \"hosting user content\" (protected) and \"generating content\" (potentially not protected) is a key legal frontier.","url":"https://www.richardewing.io/glossary/section-230"},{"@type":"DefinedTerm","termCode":"oss-licensing","name":"Open-Source Licensing","description":"Open-source licenses define the terms under which software can be used, modified, and distributed. Choosing the right license is a critical business decision that affects commercialization potential, community adoption, and legal liability.\n\nLicense types: Permissive (MIT, Apache 2.0, BSD — allow commercial use with minimal restrictions), Weak copyleft (LGPL, MPL — modifications to the library must be shared, but applications using the library don't), Strong copyleft (GPL — derivative works must use the same license), and Network copyleft (AGPL — even network-accessed applications must share source).\n\nFor companies building on open source: prefer MIT/Apache 2.0 dependencies (safest). Audit for GPL/AGPL contamination. For companies open-sourcing: MIT for maximum adoption, Apache 2.0 for patent protection, AGPL for \"open-core\" monetization (community edition AGPL, commercial edition proprietary).","url":"https://www.richardewing.io/glossary/oss-licensing"},{"@type":"DefinedTerm","termCode":"copyleft","name":"Copyleft","description":"Copyleft is a licensing concept that requires derivative works to be distributed under the same license as the original work. It ensures that software remains free/open and prevents proprietary forks.\n\nStrength spectrum: Strong copyleft (GPL — any \"derivative work\" must be GPL, including applications that link to GPL code), Weak copyleft (LGPL — only modifications to the library itself must be shared, not the application using it), File-level copyleft (MPL — changes to MPL files must be shared, but files in the rest of the project don't), and Network copyleft (AGPL — extends copyleft to software accessed over a network, closing the \"SaaS loophole\").\n\nThe AGPL is particularly important for SaaS companies: regular GPL only requires source disclosure when distributing binaries. AGPL extends this to network access — meaning hosting GPL'd code as a web service triggers the source-sharing requirement.","url":"https://www.richardewing.io/glossary/copyleft"},{"@type":"DefinedTerm","termCode":"permissive-license","name":"Permissive License","description":"A permissive license allows virtually unrestricted use of software — including commercial use, modification, and distribution — with minimal requirements (typically just attribution). Permissive licenses maximize adoption by imposing the fewest restrictions on users.\n\nMajor permissive licenses: MIT (most popular — \"do whatever, just include the copyright notice\"), Apache 2.0 (similar to MIT, adds patent grant — protects users from patent litigation by contributors), BSD 2-Clause (similar to MIT, historical), and ISC (simplified MIT, functionally identical).\n\nPermissive licenses enable: Commercial use without source disclosure, proprietary forks (AWS can build commercial products on permissive OSS), and maximum developer adoption (no legal review needed). The trade-off: no copyleft protection means companies can take without contributing back.","url":"https://www.richardewing.io/glossary/permissive-license"},{"@type":"DefinedTerm","termCode":"open-core","name":"Open-Core Business Model","description":"Open-core is a business model where the core product is open-source (usually AGPL or similar copyleft) and premium features are available only in a proprietary commercial edition. This combines open-source community growth with commercial revenue.\n\nOpen-core examples: GitLab (Community Edition is MIT, Enterprise Edition adds premium features), Elastic (Elasticsearch core is SSPL, premium features are proprietary), MongoDB (SSPL for server, proprietary for Atlas), and HashiCorp (BSL for core tools, proprietary for enterprise features).\n\nThe key tension: the community edition must be useful enough to drive adoption (too limited = no community), but the commercial edition must add enough value to justify the price (too generous = no revenue). Common premium gates: SSO/SAML, advanced security, audit logging, enterprise support, and multi-tenancy.","url":"https://www.richardewing.io/glossary/open-core"},{"@type":"DefinedTerm","termCode":"maintainer-burnout","name":"Maintainer Burnout (OSS)","description":"Maintainer burnout is the chronic stress and exhaustion experienced by open-source maintainers who maintain widely-used projects, often without compensation. Symptoms include decreased responsiveness to issues/PRs, declining code quality, and eventual project abandonment.\n\nCauses: Unpaid labor (maintaining critical infrastru
cture for free), demanding users (entitlement without contribution), security pressure (CVE disclosure requires immediate response), scope creep (feature requests outpace capacity), and isolation (solo maintainers without community support).\n\nImpact on the ecosystem: When a sole maintainer burns out, projects used by millions of applications become unmaintained — creating security vulnerabilities and dependency risks. Examples: left-pad (deleted, broke the internet), event-stream (maintainer handed off to attacker), and Log4Shell (critical vulnerability in undermaintained Apache project).","url":"https://www.richardewing.io/glossary/maintainer-burnout"},{"@type":"DefinedTerm","termCode":"fork-oss","name":"Fork (Open Source)","description":"A fork is a copy of an open-source repository that diverges from the original to follow a different development direction. Forks can be: Collaborative (contribute back to the original via pull requests), Maintenance (continue development when the original is abandoned), or Competitive (create a competitor from the original codebase).\n\nFamous forks: LibreOffice (forked from OpenOffice), MariaDB (forked from MySQL after Oracle acquisition), NextCloud (forked from OwnCloud), and io.js (forked from Node.js, later merged back).\n\nFork economics: Forking is technically free but operationally expensive. The forking team must maintain the entire codebase, handle security patches, build community, and diverge enough to justify existence. Most competitive forks fail because they can't sustain the maintenance burden.","url":"https://www.richardewing.io/glossary/fork-oss"},{"@type":"DefinedTerm","termCode":"truth-ledger","name":"Truth Ledger","description":"A truth ledger is a versioned, timestamped, source-attributed record of facts that AI systems rely upon. Unlike traditional databases where data can be silently overwritten, a truth ledger maintains the complete history of every fact — when it was asserted, by whom, and based on what source.\n\nIn the Exogram architecture, the Truth Ledger is the foundational layer that ensures AI agents operate on verified information rather than probabilistic guesses. Every fact stored in the ledger has: a timestamp (when it was recorded), a source attribution (where it came from — user, API, document, or another AI model), a version history (previous values are preserved, never deleted), and a confidence level (how reliable the source is).\n\nThe truth ledger solves the \"silent overwrite\" problem: in most AI systems, new information silently replaces old information with no audit trail. When an AI agent makes a bad decision, there's no way to trace why. The truth ledger makes every fact traceable, every change auditable, and every decision explainable.","url":"https://www.richardewing.io/glossary/truth-ledger"},{"@type":"DefinedTerm","termCode":"constraint-engine","name":"Constraint Engine","description":"A constraint engine is a system that enforces lockable rules that no AI model can violate. Policy becomes executable law. Unlike guardrails (which suggest behavior), constraints are hard boundaries — the AI physically cannot cross them.\n\nIn AI governance, constraints operate at the action level: before an AI agent executes any action, the constraint engine checks whether that action violates any active constraints. Violations result in deterministic rejection — not a warning, not a reduced probability, but a hard stop.\n\nConstraint types include: Scope constraints (the AI can only operate within defined domains), Action constraints (specific actions are forbidden — e.g., \"never delete production data\"), Value constraints (outputs must fall within defined ranges), Temporal constraints (certain actions are only permitted during specific time windows), and Authority constraints (certain actions require human approval above a threshold).","url":"https://www.richardewing.io/glossary/constraint-engine"},{"@type":"DefinedTerm","termCode":"conflict-detection","name":"Conflict Detection (AI)","description":"Conflict detection in AI systems identifies when new information contradicts existing verified facts. Instead of silently merging conflicting data (which causes downstream errors), conflict detection flags contradictions immediately for human review or automated resolution.\n\nCommon AI conflicts: Temporal contradictions (new data says X, but existing verified data says not-X), Source disagreements (two authoritative sources provide different values), Constraint violations (proposed action conflicts with active constraints), and Semantic conflicts (the same entity is described differently in two contexts).\n\nWithout conflict detection, AI systems suffer from \"confidence contamination\" — a hallucinated fact gets mixed with verified facts, and the system treats both with equal confidence. Conflict detection prevents this by maintaining contradiction awareness at every layer of the AI's knowledge.","url":"https://www.richardewing.io/glossary/conflict-detection"},{"@type":"DefinedTerm","termCode":"provenance-registry","name":"Provenance Registry","description":"A provenance registry tracks the origin, lineage, and chain of custody for every piece of information in an AI system. Every fact is source-bound — you always know where information came from, when it was acquired, and through what processing pipeline it arrived.\n\nProvenance metadata includes: Original source (document, API, user input, model output), Acquisition timestamp, Processing chain (which models or transformations modified the data), Confidence assessment (reliability of the source), and Usage history (which downstream decisions relied on this fact).\n\nProvenance registries are essential for: Regulatory compliance (audit trail for AI decisions), Debugging (trace bad outputs to source data), Trust calibration (weight facts differently based on source reliability), and Liability (determine responsibility when AI decisions cause harm).","url":"https://www.richardewing.io/glossary/provenance-registry"},{"@type":"DefinedTerm","termCode":"temporal-tracking","name":"Temporal Tracking (AI)","description":"Temporal tracking gives facts explicit time boundaries in AI systems. Information has a valid-from date, a valid-until date, and expired context is explicitly marked rather than silently reused. This prevents AI systems from making decisions based on outdated information.\n\nTemporal tracking patterns: Point-in-time validity (fact X was true on date Y), Range validity (fact X was true from date A to date B), Decay tracking (fact X becomes less reliable over time), and Refresh triggers (automatically flag facts that haven't been verified within a defined period).\n\nWithout temporal tracking, AI systems suffer from \"stale fact syndrome\" — they continue to use outdated information with the same confidence as fresh data. A pricing model trained on 2024 data making 2026 predictions, a legal AI citing superseded regulations, or a financial agent using last quarter's revenue as current.","url":"https://www.richardewing.io/glossary/temporal-tracking"},{"@type":"DefinedTerm","termCode":"audit-system-ai","name":"AI Audit System","description":"An AI audit system maintains an immutable, hash-chained event log where every mutation to the AI's knowledge, every decision, and every action is attributable and exportable. It's the black box recorder for AI systems.\n\nAudit trail components: Event type (fact creation, update, deletion, decision, action), Actor (which user, API, or model initiated the event), Timestamp (when it occurred), Before/after state (what changed), Hash chain (cryptographic proof that the log hasn't been tampered with), and Context (why the event occurred).\n\nAI audit systems are becoming legally required under the EU AI Act for high-risk AI systems. They're also essential for: SOC 2 compliance (demonstrating controls over AI systems), HIPAA compliance (tracking access to health data by AI), and Financial regulations (proving AI trading decisions were compliant).","url":"https://www.richardewing.io/glossary/audit-system-ai"},{"@type":"DefinedTerm","termCode":"pii-air-gap","name":"PII Air Gap","description":"A PII air gap is a security architecture that automatically scrubs personally identifiable information (SSNs, emails, phone numbers, credentials) before it reaches AI model storage or processing. Blocked data is never persisted — it's redacted at the ingress layer, before the AI ever sees it.\n\nPII air gap mechanisms: Pattern detection (regex-based identification of SSNs, credit cards, phone numbers), Named entity recognition (NER models that identify names, addresses, organizations), Token replacement (replacing PII with reversible tokens for authorized recovery), Encryption at rest (PII that must be stored is encrypted with strict access controls), and Audit logging (every PII detection and redaction event is recorded).\n\nThe PII air gap is distinct from traditional DLP (Data Loss Prevention) because it operates at the AI input layer — preventing PII from entering the AI's knowledge base, not just preventing it from leaving the network.","url":"https://www.richardewing.io/glossary/pii-air-gap"},{"@type":"DefinedTerm","termCode":"multi-llm-consistency","name":"Multi-LLM Consistency","description":"Multi-LLM consistency ensures that a single source of truth is shared across every AI model an organization uses — ChatGPT, Claude, Gemini, open-source models, and any future models. Without consistency enforcement, different models give different answers to the same question based on the same facts.\n\nThe multi-LLM consistency problem: Enterprise teams use 3-5 LLMs simultaneously. Each model has different training data, different biases, and different knowledge cutoffs. When asked \"what is our Q3 revenue?\", different models may produce different answers — creating organizational confusion and eroding trust in AI.\n\nSolution: A shared truth layer (like Exogram) that provides the same verified facts to every model. The models may generate different prose, but the underlying facts are consistent. Facts are model-agnostic — they live in the truth ledger, not in any model's context window.","url":"https://www.richardewing.io/glossary/multi-llm-consistency"},{"@type":"DefinedTerm","termCode":"action-admissibility","name":"Action Admissibility","description":"Action admissibility is the process of determining whether a proposed AI agent action should be permitted based on truth, constraints, scope, provenance, and temporal state. When an autonomous agent faces multiple possible actions, action admissibility doesn't pick the winner — it removes every option that violates the rules.\n\nThe admissibility funnel: An AI agent proposes 17 possible actions → 9 violated constraints (eliminated) → 3 relied on unverified facts (blocked) → 2 contradicted verified state (rejected) → 3 admissible actions remain → the model may now choose among the 3 that survive.\n\nThis is fundamentally different from most AI safety approaches, which try to rank actions by safety score (probabilistic). Action admissibility is binary and deterministic: an action is either admissible or it's not. There's no \"probably safe\" — only \"provably admissible within defined constraints.\"","url":"https://www.richardewing.io/glossary/action-admissibility"},{"@type":"DefinedTerm","termCode":"execution-control-plane","name":"Execution Control Plane","description":"An execution control plane is an infrastructure layer that sits between AI models and the actions they take, governing what AI agents are allowed to do. It's the equivalent of IAM (Identity and Access Management) for autonomous AI agents.\n\nThe execution control plane enforces: What the agent can access (data scope), What actions the agent can take (action permissions), What facts the agent can rely upon (truth verification), What the agent must escalate to humans (authority thresholds), and What the agent must log (audit requirements).\n\nExogram positions itself as \"IAM for autonomous AI agents\" — just as IAM controls what humans and services can do in cloud infrastructure, the execution control plane controls what AI agents can do in the real world. As agentic AI scales from prototype to production, the execution control plane becomes as essential as IAM is for cloud infrastructure.","url":"https://www.richardewing.io/glossary/execution-control-plane"},{"@type":"DefinedTerm","termCode":"deterministic-governance","name":"Deterministic Governance","description":"Deterministic governance applies provably correct rules to AI behavior, as opposed to probabilistic governance (which relies on model training and alignment to encourage good behavior). Deterministic governance guarantees outcomes; probabilistic governance estimates them.\n\nThe spectrum: Probabilistic governance uses RLHF (Reinforcement Learning from Human Feedback), constitutional AI, and prompt engineering — all of which make bad behavior unlikely but not impossible. Deterministic governance uses constraint engines, hard boundaries, and formal verification — making bad behavior provably impossible within defined scope.\n\nDeterministic governance is essential for: Financial services (trading decisions must be explainable and compliant), Healthcare (patient treatment recommendations must follow clinical guidelines), Legal (AI-generated legal advice must cite real precedent), and Government (AI decisions affecting citizens must be auditable and contestable).","url":"https://www.richardewing.io/glossary/deterministic-governance"},{"@type":"DefinedTerm","termCode":"cryptographic-execution-gating","name":"Cryptographic Execution Gating","description":"Cryptographic execution gating uses cryptographic proofs (hash chains, digital signatures, zero-knowledge proofs) to ensure that AI actions are authorized, tamper-proof, and verifiable. The AI's execution history cannot be falsified or retroactively modified.\n\nMechanisms: Hash-chained audit logs (each event includes the hash of the previous event — any tampering invalidates the chain), Signed execution records (each AI action is digitally signed by the governance system), Verifiable decision proofs (third parties can verify that an AI decision was made within its authorized constraints without seeing the underlying data), and Tamper-evident storage (any modification to stored facts or decisions is cryptographically detectable).\n\nThis is critical for enterprise AI deployment where the question isn't just \"did the AI make the right decision?\" but \"can you prove the AI made the right decision?\"","url":"https://www.richardewing.io/glossary/cryptographic-execution-gating"},{"@type":"DefinedTerm","termCode":"agent-memory-architecture","name":"Agent Memory Architecture","description":"Agent memory architecture defines how AI agents store, retrieve, and manage information across conversations, sessions, and tasks. Unlike human memory, AI agent memory must be explicitly designed — it doesn't emerge automatically from model training.\n\nMemory layers: Working memory (current conversation context — limited by context window size), Short-term memory (session-level facts and decisions — persisted between tool calls), Long-term memory (organizational knowledge, policies, and verified facts — persisted indefinitely), Episodic memory (records of past interactions and outcomes — for learning from experience), and Procedural memory (how-to knowledge and workflow patterns — for task execution).\n\nThe memory architecture directly impacts agent capability: agents with only working memory \"forget\" everything between sessions. Agents with long-term memory build institutional knowledge. Agents with episodic memory learn from mistakes. The Exogram architecture provides persistent, verified, source-attributed memory across all layers.","url":"https://www.richardewing.io/glossary/agent-memory-architecture"},{"@type":"DefinedTerm","termCode":"ai-liability-gradient","name":"AI Liability Gradient","description":"The AI liability gradient is a framework by Richard Ewing that maps how organizational liability increases non-linearly as AI agent autonomy increases. At low autonomy (AI suggests, human decides), liability is minimal. At high autonomy (AI decides and acts independently), liability is maximum and often unbounded.\n\nThe gradient has four zones: Advisory (AI provides recommendations, human decides — low liability, same as any decision support tool), Assisted (AI takes action with human approval — moderate liability, human retains final authority), Autonomous with oversight (AI acts independently with human monitoring — high liability, human may not catch errors in time), and Fully autonomous (AI acts independently without real-time oversight — maximum liability, organization is responsible for all AI actions).\n\nMost organizations underestimate where they sit on the gradient. A customer service chatbot that can issue refunds is in the \"autonomous with oversight\" zone — it's making financial decisions independently. A trading algorithm is \"fully autonomous\" during market hours. The liability implications are dramatically different from \"advisory\" AI.","url":"https://www.richardewing.io/glossary/ai-liability-gradient"},{"@type":"DefinedTerm","termCode":"ai-product-business-test","name":"AI Product Business Test","description":"The AI Product Business Test is a framework for validating the unit economics of an AI feature before writing any code. Coined by Richard Ewing, it addresses the pattern of AI products that are technically impressive but economically unviable.\n\nThe test evaluates three dimensions:\n\n**1. Marginal Cost Structure:** Does the AI feature have a marginal cost per usage (API calls, inference compute) that scales with adoption? If yes, the feature has a Cost of Goods Sold (COGS) problem that traditional software doesn't have.\n\n**2. Accuracy-Cost Curve:** What accuracy level does the use case require, and what does that accuracy cost? The Cost of Predictivity curve shows that going from 80% to 95% accuracy often costs 10x more than going from 50% to 80%.\n\n**3. Margin Contribution:** Does the AI feature's revenue contribution exceed its variable infrastructure cost at the target scale? Many AI features are margin-negative — they cost more to serve than the revenue they generate.","url":"https://www.richardewing.io/glossary/ai-product-business-test"},{"@type":"DefinedTerm","termCode":"audit-interview-protocol","name":"Audit Interview Protocol","description":"The Audit Interview Protocol is a hiring methodology designed for the AI era, replacing traditional coding interviews with verification-based assessments. Instead of asking candidates to write code from scratch, the protocol presents AI-generated code with intentional flaws and evaluates the candidate's ability to find, classify, and prioritize those flaws.\n\nThe protocol assesses five dimensions:\n\n**1. Bug Detection Rate:** Can the candidate identify the hidden defects?\n\n**2. Severity Classification:** Can they correctly rank the severity of each issue (critical, major, minor, cosmetic)?\n\n**3. Ship/No-Ship Judgment:** Given the bugs found, would they ship or block the release?\n\n**4. Fix Quality:** Can they propose correct, minimal fixes?\n\n**5. Communication:** Can they explain technical risk to non-technical stakeholders?","url":"https://www.richardewing.io/glossary/audit-interview-protocol"},{"@type":"DefinedTerm","termCode":"zombie-feature","name":"Zombie Feature","description":"A zombie feature is a product feature that is technically alive (deployed, receiving maintenance, consuming resources) but effectively dead (few or no users, minimal revenue impact, no strategic value). Zombie features persist because organizations lack the data or courage to kill them.\n\nZombie features are uniquely destructive because they compound:\n\n- **Maintenance cost** — every sprint, engineers spend time keeping zombie features compatible with platform changes\n- **Cognitive overhead** — new engineers must understand code paths that serve no users\n- **Testing burden** — QA must verify zombie features don't break during releases\n- **Security surface** — unmaintained code paths become vulnerability vectors","url":"https://www.richardewing.io/glossary/zombie-feature"},{"@type":"DefinedTerm","termCode":"subprime-code-crisis","name":"Subprime Code Crisis","description":"The Subprime Code Crisis is an analogy coined by Richard Ewing comparing the hidden risk in enterprise codebases to the 2008 financial crisis. Just as subprime mortgages were bundled into complex financial instruments that masked their true risk, technical debt is bundled into \"working software\" that masks its true maintenance cost.\n\nThe parallel is structural:\n\n**2008 Financial Crisis:** Risky mortgages → bundled into CDOs → rated AAA → systemic collapse when defaults cascaded\n\n**Subprime Code Crisis:** Technical debt → bundled into \"working features\" → rated as \"shipped\" → systemic engineering failure when maintenance costs cascade\n\nThe key insight is that technical debt, like financial debt, has a compounding interest rate. When maintenance costs exceed a threshold (typically 40-60% of engineering capacity), the system enters a death spiral where new features generate more maintenance than value.","url":"https://www.richardewing.io/glossary/subprime-code-crisis"},{"@type":"DefinedTerm","termCode":"ai-agent","name":"AI Agent","description":"An AI agent is an autonomous software system that uses large language models (LLMs) to perceive, reason, plan, and take actions in the real world without constant human oversight. Unlike simple AI assistants (which respond to prompts), agents can:\n\n- **Plan multi-step tasks** by breaking goals into sub-goals\n- **Use tools** (APIs, databases, browsers, code execution)\n- **Maintain memory** across interactions\n- **Make decisions autonomously** based on context\n- **Take actions** that affect external systems\n\nThe 2025-2026 wave of AI agents includes coding agents (Devin, Cursor Agent), customer support agents, data analysis agents, and enterprise workflow agents.","url":"https://www.richardewing.io/glossary/ai-agent"},{"@type":"DefinedTerm","termCode":"hallucination-debt","name":"Hallucination Debt","description":"Hallucination debt is the accumulated organizational risk from AI systems that generate plausible but incorrect outputs that are accepted as truth and propagated into business decisions, customer communications, and downstream systems.\n\nUnlike technical debt (which is a known trade-off), hallucination debt is invisible — the organization doesn't know it's accumulating because the AI outputs look correct. Hallucination debt compounds through:\n\n- **Decision propagation:** An AI hallucination informs a business decision, which informs downstream decisions\n- **Customer trust erosion:** AI-generated content reaches customers with factual errors\n- **System contamination:** AI outputs are fed back as training data, reinforcing the hallucination\n- **Legal liability:** AI-generated hallucinations in regulated industries create compliance violations","url":"https://www.richardewing.io/glossary/hallucination-debt"},{"@type":"DefinedTerm","termCode":"gross-margin-preservation","name":"Gross Margin Preservation","description":"Gross Margin Preservation is the discipline of protecting software gross margins as AI features are added to the product. Traditional software has near-zero marginal cost of serving an additional user. AI features introduce variable inference costs (API calls, GPU compute, token usage) that erode gross margins with every interaction.\n\n**The Margin Trap:**\n- Traditional SaaS gross margins: 75-85%\n- AI-enhanced SaaS gross margins: 50-70%\n- AI-native products with poor controls: 20-40%\n\nGross Margin Preservation strategies include: model right-sizing (using the smallest model that achieves acceptable accuracy), intelligent caching, request batching, and tiered AI access (reserving expensive models for high-value interactions).","url":"https://www.richardewing.io/glossary/gross-margin-preservation"},{"@type":"DefinedTerm","termCode":"pl-ownership-product-managers","name":"P&L Ownership for Product Managers","description":"P&L Ownership for Product Managers is the practice of making product managers financially accountable for the profit and loss impact of their product decisions. Rather than measuring PMs on shipping velocity or feature count, P&L ownership measures them on revenue contribution, cost efficiency, and margin impact.\n\nRichard Ewing's article in Mind the Product (\"The 3 Financial Metrics Every PM Needs on Their Scorecard\") argues that PMs who don't understand their P&L are making uninformed capital allocation decisions with every sprint.\n\n**The 3 Metrics:**\n1. **Revenue Attribution:** What revenue does your product area generate?\n2. **COGS Contribution:** What does it cost to serve your product area?\n3. **Margin Contribution:** Revenue minus COGS — your actual value creation","url":"https://www.richardewing.io/glossary/pl-ownership-product-managers"},{"@type":"DefinedTerm","termCode":"engineering-capital-allocation","name":"Engineering Capital Allocation","description":"Engineering Capital Allocation is the discipline of treating every engineering hour as a financial investment and evaluating it against expected returns. Most engineering organizations allocate capital (engineering time) based on stakeholder politics, customer urgency, or technical interest rather than economic value.\n\nThe Product Economist framework reframes every sprint planning decision as a capital allocation decision:\n\n- **Building Feature X** = investing $50K of engineering capital (3 engineers × 2 weeks × loaded cost)\n- **Expected Return** = $200K ARR uplift (validated) = 4x ROI ✅\n- **vs. Feature Y** = investing $50K of engineering capital\n- **Expected Return** = $30K ARR uplift (estimated) = 0.6x ROI ❌\n\nWithout this economic lens, most organizations invest equally in both features — destroying capital on Feature Y.","url":"https://www.richardewing.io/glossary/engineering-capital-allocation"},{"@type":"DefinedTerm","termCode":"model-right-sizing","name":"Model Right-Sizing","description":"Model right-sizing is the practice of selecting the smallest, cheapest AI model that achieves acceptable accuracy for a given use case. It directly addresses the Cost of Predictivity curve — the exponential relationship between AI accuracy and inference cost.\n\n**The Right-Sizing Principle:**\n- Simple queries (classification, routing): Use a small, fast model (GPT-4o-mini, Claude Haiku)\n- Medium complexity (summarization, extraction): Use a mid-tier model\n- High complexity (reasoning, code generation): Use a frontier model\n- Critical decisions: Use a frontier model with verification layer\n\nA well-right-sized AI system can serve 80% of requests at 10-20% of the cost of using a single frontier model for everything.","url":"https://www.richardewing.io/glossary/model-right-sizing"},{"@type":"DefinedTerm","termCode":"technical-due-diligence","name":"Technical Due Diligence","description":"Technical Due Diligence (Tech DD) is the systematic evaluation of a company's technology, engineering practices, architecture, and technical debt prior to investment, acquisition, or strategic partnership. It answers the question: \"Is the technology a strategic asset or a hidden liability?\"\n\n**Comprehensive Tech DD covers:**\n- **Architecture assessment:** Scalability, reliability, security\n- **Code quality:** Technical debt levels, maintenance burden, test coverage\n- **Team evaluation:** Skill distribution, retention risk, key-person dependencies\n- **AI/ML evaluation:** Model performance, inference costs, data quality\n- **Infrastructure:** Cloud costs, vendor dependencies, disaster recovery\n- **Projection:** Technical Insolvency Date, maintenance trajectory","url":"https://www.richardewing.io/glossary/technical-due-diligence"},{"@type":"DefinedTerm","termCode":"agentic-workflow","name":"Agentic Workflow","description":"An agentic workflow is a multi-step process executed by AI agents that can make decisions, use tools, and adapt their approach based on intermediate results — without requiring human intervention at each step. Unlike simple automation (which follows fixed rules), agentic workflows involve reasoning, planning, and dynamic tool selection.\n\n**Examples:**\n- A coding agent that reads a bug report, identifies the root cause, writes a fix, runs tests, and creates a PR\n- A customer support agent that reads a ticket, queries the knowledge base, checks the customer's account, and drafts a response\n- A data analysis agent that receives a question, writes SQL, executes it, interprets results, and generates a report","url":"https://www.richardewing.io/glossary/agentic-workflow"},{"@type":"DefinedTerm","termCode":"retrieval-augmented-generation","name":"Retrieval-Augmented Generation","description":"Retrieval-Augmented Generation (RAG) is a technique that enhances large language model (LLM) responses by first retrieving relevant documents from a knowledge base, then using those documents as context for the model's response generation.\n\n**How RAG works:**\n1. User sends a query\n2. The query is converted to a vector embedding\n3. Similar documents are retrieved from a vector database\n4. Retrieved documents are included in the LLM prompt as context\n5. The LLM generates a response grounded in the retrieved documents\n\nRAG reduces hallucination by grounding the model's response in factual source material rather than relying solely on the model's training data.","url":"https://www.richardewing.io/glossary/retrieval-augmented-generation"},{"@type":"DefinedTerm","termCode":"vector-database","name":"Vector Database","description":"A vector database is a specialized database designed to store, index, and query high-dimensional vector embeddings — numerical representations of data (text, images, audio) generated by machine learning models.\n\n**Key capabilities:**\n- **Similarity search:** Find the most similar vectors to a query vector (nearest neighbor search)\n- **Scalability:** Handle millions to billions of vectors with sub-second query times\n- **Filtering:** Combine vector similarity with metadata filters\n- **Real-time updates:** Add, update, and delete vectors without rebuilding the index\n\n**Popular vector databases:** Pinecone, Weaviate, Milvus, Qdrant, ChromaDB\n\nVector databases are the infrastructure layer that enables RAG, semantic search, recommendation systems, and AI agent memory.","url":"https://www.richardewing.io/glossary/vector-database"},{"@type":"DefinedTerm","termCode":"llm-fine-tuning","name":"LLM Fine-Tuning","description":"LLM Fine-Tuning is the process of training a pre-trained large language model on a domain-specific dataset to improve its performance on specialized tasks. Unlike prompting (which provides instructions at inference time), fine-tuning permanently modifies the model's weights.\n\n**When to fine-tune vs. prompt:**\n- **Fine-tune when:** You need consistent formatting, domain-specific terminology, or the task requires knowledge not in the base model\n- **Prompt when:** The task is achievable with instructions and examples, or you need flexibility to change behavior quickly\n- **Use RAG when:** The required knowledge changes frequently or is too large for fine-tuning\n\n**Cost considerations:** Fine-tuning requires training compute (one-time), but the fine-tuned model may require fewer tokens per request (ongoing savings).","url":"https://www.richardewing.io/glossary/llm-fine-tuning"},{"@type":"DefinedTerm","termCode":"ship-no-ship-decision","name":"Ship/No-Ship Decision","description":"The Ship/No-Ship Decision is the judgment call on whether a software release is ready for production deployment, given the known bugs, risks, and trade-offs. It is the most critical judgment engineers make — and the skill most under-tested in traditional hiring.\n\nThe Audit Interview Protocol specifically evaluates Ship/No-Ship judgment because it reveals:\n\n- **Risk tolerance:** Does the candidate understand which bugs are showstoppers vs. acceptable?\n- **Customer empathy:** Does the candidate consider the user impact of known issues?\n- **Business awareness:** Does the candidate weigh the cost of delay vs. the cost of defects?\n- **Communication:** Can the candidate explain their decision to non-technical stakeholders?","url":"https://www.richardewing.io/glossary/ship-no-ship-decision"},{"@type":"DefinedTerm","termCode":"cicd-pipeline","name":"CI/CD Pipeline","description":"A CI/CD pipeline (Continuous Integration / Continuous Deployment) is an automated workflow that takes code from a developer's commit through build, test, and deployment to production. It eliminates manual steps in the software delivery process.\n\n**Continuous Integration (CI):** Every code commit triggers automated build and tests. Failed tests block merging. This catches defects early.\n\n**Continuous Deployment (CD):** Code that passes CI is automatically deployed to production without manual intervention. This reduces deployment risk by making each change small.","url":"https://www.richardewing.io/glossary/cicd-pipeline"},{"@type":"DefinedTerm","termCode":"infrastructure-as-code","name":"Infrastructure as Code","description":"Infrastructure as Code (IaC) is the practice of managing infrastructure (servers, networks, databases) through code files rather than manual configuration. Infrastructure definitions are version-controlled, reviewed, tested, and deployed through the same CI/CD pipeline as application code.\n\n**Popular IaC tools:** Terraform (multi-cloud), Pulumi (programming languages), AWS CloudFormation, Ansible, Chef, Puppet.\n\n**Key benefits:** Reproducibility (same infrastructure in every environment), auditability (who changed what, when), disaster recovery (rebuild from code), and cost visibility (infrastructure as a reviewable bill of materials).","url":"https://www.richardewing.io/glossary/infrastructure-as-code"},{"@type":"DefinedTerm","termCode":"kubernetes","name":"Kubernetes","description":"Kubernetes (K8s) is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Originally developed by Google, it is now the industry standard for running production workloads at scale.\n\n**Key concepts:** Pods (smallest deployable unit), Services (network abstraction), Deployments (declarative updates), Namespaces (resource isolation), Ingress (external traffic routing), ConfigMaps/Secrets (configuration management).","url":"https://www.richardewing.io/glossary/kubernetes"},{"@type":"DefinedTerm","termCode":"observability","name":"Observability","description":"Observability is the ability to understand the internal state of a system by examining its outputs — logs, metrics, and traces (the \"three pillars\"). Unlike monitoring (which checks known failure modes), observability enables investigating unknown-unknowns: problems you didn't anticipate.\n\n**The Three Pillars:**\n- **Logs:** Detailed event records from application code\n- **Metrics:** Numerical measurements over time (latency, error rate, throughput)\n- **Traces:** End-to-end request tracking across distributed services\n\n**Tools:** Datadog, Grafana, Prometheus, OpenTelemetry, Honeycomb, New Relic.","url":"https://www.richardewing.io/glossary/observability"},{"@type":"DefinedTerm","termCode":"site-reliability-engineering","name":"Site Reliability Engineering","description":"Site Reliability Engineering (SRE) is a discipline originated by Google that applies software engineering practices to infrastructure and operations problems. SREs write code to automate operations tasks, define Service Level Objectives (SLOs), and manage error budgets.\n\n**Key concepts:** SLIs (Service Level Indicators) — what you measure, SLOs (Service Level Objectives) — the target, Error Budgets — the acceptable amount of unreliability before halting feature releases.","url":"https://www.richardewing.io/glossary/site-reliability-engineering"},{"@type":"DefinedTerm","termCode":"feature-flags","name":"Feature Flags","description":"Feature flags (also called feature toggles) are conditional statements in code that allow teams to enable or disable features without deploying new code. They separate code deployment from feature release.\n\n**Types:** Release flags (rollout control), Experiment flags (A/B testing), Ops flags (kill switches for performance), Permission flags (premium features).","url":"https://www.richardewing.io/glossary/feature-flags"},{"@type":"DefinedTerm","termCode":"incident-management","name":"Incident Management","description":"Incident management is the process of detecting, responding to, resolving, and learning from production outages and degradations. A mature incident management process includes defined severity levels, escalation procedures, war room protocols, customer communication templates, and blameless postmortem practices.","url":"https://www.richardewing.io/glossary/incident-management"},{"@type":"DefinedTerm","termCode":"finops","name":"FinOps","description":"FinOps (Financial Operations) is a cloud financial management discipline that brings financial accountability to the variable cost model of cloud computing. It combines engineering, finance, and business teams to make real-time data-driven spending decisions.\n\nFinOps operates on three phases: Inform (visibility into cloud costs), Optimize (right-size, reserve, eliminate waste), Operate (continuously manage cloud economics).","url":"https://www.richardewing.io/glossary/finops"},{"@type":"DefinedTerm","termCode":"cloud-cost-optimization","name":"Cloud Cost Optimization","description":"Cloud cost optimization is the continuous process of reducing cloud infrastructure spend while maintaining performance and reliability. It addresses the most common sources of cloud waste:\n\n**Over-provisioning:** Resources sized for peak load but running at 10-20% utilization\n**Zombie resources:** Instances, volumes, and load balancers no longer attached to active services\n**Missing reservations:** Paying on-demand prices for predictable workloads\n**Data transfer costs:** Unexpected cross-region or cross-AZ data transfer charges\n**AI/ML compute waste:** GPU instances left running after training completes","url":"https://www.richardewing.io/glossary/cloud-cost-optimization"},{"@type":"DefinedTerm","termCode":"product-led-growth","name":"Product-Led Growth","description":"Product-Led Growth (PLG) is a go-to-market strategy where the product itself is the primary driver of customer acquisition, expansion, and retention. Users discover the product, experience value through a free or freemium tier, and upgrade to paid plans based on usage.\n\n**PLG characteristics:** Self-serve onboarding, freemium or free trial, in-product upgrade prompts, viral or collaborative features, usage-based pricing.\n\n**Examples:** Slack, Zoom, Notion, Figma, Dropbox, Canva.","url":"https://www.richardewing.io/glossary/product-led-growth"},{"@type":"DefinedTerm","termCode":"revenue-operations","name":"Revenue Operations","description":"Revenue Operations (RevOps) is the alignment of marketing, sales, and customer success operations to drive full-funnel revenue growth. It breaks down silos between departments by unifying data, processes, tools, and goals.\n\nRevOps centralizes: CRM management, pipeline tracking, forecasting, territory and quota planning, attribution modeling, and cross-functional reporting.","url":"https://www.richardewing.io/glossary/revenue-operations"},{"@type":"DefinedTerm","termCode":"operating-leverage","name":"Operating Leverage","description":"Operating leverage measures how effectively a company converts revenue growth into profit growth. High operating leverage means each additional dollar of revenue costs less to generate than the previous dollar — revenue grows faster than costs.\n\nSoftware companies have inherently high operating leverage because the marginal cost of serving an additional customer is near-zero (for traditional software). AI features reduce operating leverage by introducing variable costs that scale with usage.","url":"https://www.richardewing.io/glossary/operating-leverage"},{"@type":"DefinedTerm","termCode":"microservices-architecture","name":"Microservices Architecture","description":"Microservices architecture is an approach to software design where an application is composed of small, independent services that communicate over well-defined APIs. Each service owns its own data, can be deployed independently, and is typically maintained by a small team.\n\n**Benefits:** Independent scaling, technology diversity, fault isolation, faster deployment cycles.\n\n**Costs:** Network complexity, distributed data management, operational overhead, debugging difficulty.","url":"https://www.richardewing.io/glossary/microservices-architecture"},{"@type":"DefinedTerm","termCode":"ai-bias-fairness","name":"AI Bias & Fairness","description":"AI bias refers to systematic errors in AI system outputs that create unfair outcomes for certain groups. Bias can enter AI systems through training data (historical bias), feature selection (measurement bias), or model design (algorithmic bias).\n\nFairness in AI requires defining what \"fair\" means for each use case — equal outcome rates across groups, equal error rates, individual fairness (similar people get similar results), or procedural fairness (the process is transparent and consistent).\n\nThe 2026 regulatory landscape (EU AI Act, NIST AI RMF) requires organizations to assess and mitigate AI bias in high-risk applications including hiring, lending, healthcare, and criminal justice.","url":"https://www.richardewing.io/glossary/ai-bias-fairness"},{"@type":"DefinedTerm","termCode":"ai-guardrails","name":"AI Guardrails","description":"AI guardrails are technical and procedural controls that constrain AI system behavior within acceptable boundaries. They prevent AI from generating harmful, inaccurate, off-topic, or policy-violating outputs.\n\nTypes of guardrails include: input filtering (blocking malicious prompts), output filtering (detecting harmful content), topic constraints (keeping AI on-task), factual grounding (requiring source citations), rate limiting (preventing abuse), and human-in-the-loop gates (requiring approval for high-risk actions).\n\nExogram's Constraint Engine represents the most sophisticated approach to AI guardrails — lockable rules that no model can violate, enforced at the infrastructure level rather than the prompt level.","url":"https://www.richardewing.io/glossary/ai-guardrails"},{"@type":"DefinedTerm","termCode":"ai-hallucination-debt","name":"AI Hallucination Debt","description":"AI Hallucination Debt is a term coined by Richard Ewing describing the accumulated organizational risk from AI-generated falsehoods that are accepted as truth and propagated through business decisions, customer communications, and downstream systems.\n\nUnlike technical debt (a known trade-off), hallucination debt is invisible — the organization doesn't know it's accumulating because hallucinated outputs look correct. It compounds through decision chains: one hallucination informs a business decision, which informs downstream decisions, creating a cascade of conclusions built on false premises.\n\nHallucination debt is uniquely dangerous because it compounds exponentially rather than linearly. Each downstream system that consumes hallucinated data becomes a new source of misinformation.","url":"https://www.richardewing.io/glossary/ai-hallucination-debt"},{"@type":"DefinedTerm","termCode":"ai-unit-economics","name":"AI Unit Economics","description":"AI Unit Economics measures the per-interaction profitability of AI-powered features. Unlike traditional software with near-zero marginal costs, AI features have significant variable costs — every API call, every inference request, every token processed costs money.\n\n**The AI Unit Economics Formula:**\nRevenue per AI interaction − Cost per AI interaction = Margin per interaction\n\nCosts include: LLM API fees, embedding generation, vector database queries, retrieval pipeline compute, post-processing, monitoring, and error handling. Many AI features are margin-negative — they cost more to serve than the revenue they generate.\n\nRichard Ewing's AUEB (AI Unit Economics Benchmark) calculator at richardewing.io/tools/aueb helps teams model these economics before and after launch.","url":"https://www.richardewing.io/glossary/ai-unit-economics"},{"@type":"DefinedTerm","termCode":"api-design","name":"API Design","description":"API design is the practice of defining the interface through which software components communicate. Good API design creates clear, consistent, well-documented contracts that are easy to use correctly and hard to use incorrectly.\n\n**Key principles:** consistency (similar operations work similarly), simplicity (minimal surface area), versioning (backward compatibility), error handling (clear, actionable error messages), and documentation (complete, accurate, with examples).\n\n**Common patterns:** REST (resource-oriented), GraphQL (query-based), gRPC (performance-oriented), WebSocket (real-time). Each has trade-offs for different use cases.","url":"https://www.richardewing.io/glossary/api-design"},{"@type":"DefinedTerm","termCode":"career-levels","name":"Career Levels in Engineering","description":"Engineering career levels (also called career ladders or leveling frameworks) define the progression path for software engineers from junior through staff, principal, and distinguished levels. Well-designed levels create clarity about expectations, compensation, and growth.\n\n**Common IC track:** Junior (L3) → Mid (L4) → Senior (L5) → Staff (L6) → Senior Staff (L7) → Principal (L8) → Distinguished (L9)\n\n**Common management track:** Tech Lead → Engineering Manager → Senior EM → Director → VP Engineering → CTO\n\nThe transition from Senior to Staff is the most critical inflection point — it requires shifting from individual contribution to force multiplication.","url":"https://www.richardewing.io/glossary/career-levels"},{"@type":"DefinedTerm","termCode":"change-failure-rate","name":"Change Failure Rate","description":"Change Failure Rate (CFR) is one of the four DORA metrics. It measures the percentage of deployments to production that cause a failure requiring remediation — a rollback, hotfix, or incident response.\n\n**Benchmarks (DORA State of DevOps):**\n- Elite: 0-15%\n- High: 16-30%\n- Medium: 16-30%\n- Low: 46-60%\n\nChange failure rate is the quality counterpart to deployment frequency and lead time. High deployment frequency with high CFR means you're shipping bugs faster.","url":"https://www.richardewing.io/glossary/change-failure-rate"},{"@type":"DefinedTerm","termCode":"continuous-deployment","name":"Continuous Deployment","description":"Continuous Deployment is the practice of automatically deploying every code change that passes automated tests to production — without any manual approval step. It is the most aggressive form of CI/CD and the hallmark of elite engineering teams.\n\nContinuous Deployment requires: comprehensive automated test suites, feature flags for risk control, robust monitoring and alerting, fast rollback capability, and a culture of small, incremental changes.\n\n**Not to be confused with Continuous Delivery**, which automatically *prepares* code for release but requires manual approval to deploy.","url":"https://www.richardewing.io/glossary/continuous-deployment"},{"@type":"DefinedTerm","termCode":"engineering-management-role","name":"Engineering Manager","description":"An Engineering Manager (EM) is a people leader responsible for the productivity, growth, and well-being of a software engineering team. Unlike tech leads (who lead through technical influence), EMs lead through people management — hiring, coaching, performance reviews, career development, and organizational design.\n\n**Core responsibilities:** hiring and team building, 1:1s and career development, performance management, process optimization, stakeholder communication, and shielding the team from organizational chaos.\n\nThe best EMs are force multipliers — they make their entire team more productive rather than being the most productive individual.","url":"https://www.richardewing.io/glossary/engineering-management-role"},{"@type":"DefinedTerm","termCode":"gdpr","name":"GDPR","description":"The General Data Protection Regulation (GDPR) is the European Union's comprehensive data privacy law enacted in 2018. It governs how organizations collect, store, process, and delete personal data of EU residents.\n\n**Key requirements:** lawful basis for processing, explicit consent, data minimization, right to access, right to deletion (right to be forgotten), data portability, breach notification (72 hours), Data Protection Officer (DPO) requirement, and Privacy Impact Assessments.\n\n**Penalties:** Up to €20M or 4% of global annual revenue, whichever is higher. Major fines have been issued to Meta ($1.3B), Amazon ($887M), and Google ($57M).","url":"https://www.richardewing.io/glossary/gdpr"},{"@type":"DefinedTerm","termCode":"hiring-bar-calibration","name":"Hiring Bar Calibration","description":"Hiring bar calibration is the process of aligning interviewers on what constitutes a \"pass\" or \"fail\" for engineering candidates. Without calibration, hiring decisions depend on which interviewers conduct the loop — creating inconsistent and unfair outcomes.\n\nCalibration involves: defining competency matrices for each level, conducting mock interview scoring sessions, tracking interviewer pass rates (too high = low bar, too low = blocking good candidates), and regular review of hire quality outcomes.\n\nRichard Ewing's Audit Interview Protocol provides a calibrated alternative to traditional coding interviews — a standardized assessment that measures verification judgment rather than code generation speed.","url":"https://www.richardewing.io/glossary/hiring-bar-calibration"},{"@type":"DefinedTerm","termCode":"microservices","name":"Microservices","description":"Microservices architecture structures an application as a collection of small, independent services that communicate over APIs. Each service is owned by a single team, deployable independently, and organized around a specific business capability.\n\n**Benefits:** independent deployment, technology flexibility, team autonomy, fault isolation, and scalability for specific components.\n\n**Costs:** distributed systems complexity, network latency, data consistency challenges, operational overhead, and debugging difficulty across service boundaries.\n\nMicroservices are not inherently better than monoliths. They trade local complexity (large codebase) for distributed complexity (network, consistency, observability).","url":"https://www.richardewing.io/glossary/microservices"},{"@type":"DefinedTerm","termCode":"monolith","name":"Monolith Architecture","description":"A monolith is a software application built as a single, unified codebase where all components share the same process, database, and deployment pipeline. Monoliths are the default architecture for most applications and remain the right choice for many organizations.\n\n**Advantages:** simpler development, easier debugging, single deployment, no network overhead between components, straightforward data consistency, and lower operational complexity.\n\n**Disadvantages at scale:** deployment bottlenecks (one team's change blocks everyone), scaling limitations (must scale everything together), technology lock-in, and growing build/test times.","url":"https://www.richardewing.io/glossary/monolith"},{"@type":"DefinedTerm","termCode":"one-on-one","name":"One-on-One Meetings","description":"One-on-one (1:1) meetings are regular, private conversations between a manager and their direct report. They are the single most important management practice for building trust, providing feedback, and supporting career development.\n\n**Best practices:** weekly cadence (30-60 minutes), employee-driven agenda, avoid status updates (use standups for that), focus on coaching and career growth, discuss blockers and frustrations, and never cancel — rescheduling is fine, canceling signals deprioritization.\n\nEffective 1:1s cover three domains: tactical (current work blockers), developmental (skill growth and career goals), and relational (trust, satisfaction, engagement).","url":"https://www.richardewing.io/glossary/one-on-one"},{"@type":"DefinedTerm","termCode":"platform-engineering","name":"Platform Engineering","description":"Platform Engineering is the discipline of building and maintaining internal developer platforms (IDPs) that abstract away infrastructure complexity and provide self-service capabilities to engineering teams.\n\nPlatform engineering evolved from DevOps as organizations recognized that expecting every team to manage their own infrastructure creates duplication and inconsistency. Instead, a dedicated platform team builds tools, templates, and automation that other teams consume.\n\n**Components:** CI/CD pipelines, infrastructure provisioning, monitoring and observability, secrets management, deployment automation, environment management, and developer documentation.","url":"https://www.richardewing.io/glossary/platform-engineering"},{"@type":"DefinedTerm","termCode":"product-economics","name":"Product Economics","description":"Product Economics is the discipline of treating every product decision as an economic decision — evaluating features, sprints, and roadmaps through the lens of capital allocation, ROI, and margin impact rather than velocity or feature count.\n\nCoined and developed by Richard Ewing, Product Economics encompasses: the Product Debt Index (quantifying technical debt in dollar terms), the Innovation Tax (measuring hidden maintenance burden), the Cost of Predictivity (exponential AI accuracy costs), the Kill Switch Protocol (deprecating zombie features), and the Feature Bloat Calculus (when maintenance exceeds value).\n\nThe Product Economist Doctrine holds four principles: Capital Allocation > Agile Theater, The Truth is in the P&L, Kill Zombies Ruthlessly, and Sovereignty Over Dependency.","url":"https://www.richardewing.io/glossary/product-economics"},{"@type":"DefinedTerm","termCode":"product-management","name":"Product Management","description":"Product Management is the function responsible for defining what to build, for whom, and why — then ensuring it gets built, launched, and iterated on to maximize business value. Product managers (PMs) sit at the intersection of business, technology, and user experience.\n\n**Core PM activities:** customer research, market analysis, prioritization (RICE, WSJF), roadmapping, writing requirements (PRDs, user stories), collaborating with engineering and design, launch coordination, and metrics analysis.\n\nIn the AI era, PMs must also understand AI unit economics, the Cost of Predictivity, and the trade-offs between AI-powered and deterministic features.","url":"https://www.richardewing.io/glossary/product-management"},{"@type":"DefinedTerm","termCode":"security-compliance","name":"Security & Compliance","description":"Security and compliance are two related disciplines that protect organizations from threats and ensure adherence to regulatory requirements.\n\n**Security** focuses on protecting systems, data, and users from unauthorized access, breaches, and attacks. Key areas: application security, network security, identity and access management, encryption, vulnerability management, and incident response.\n\n**Compliance** ensures organizational practices meet regulatory and industry standards. Key frameworks: SOC 2, GDPR, HIPAA, PCI-DSS, ISO 27001, NIST CSF, and the EU AI Act.\n\nIn the AI era, security and compliance extend to model security, training data privacy, inference access control, and AI-specific regulations.","url":"https://www.richardewing.io/glossary/security-compliance"},{"@type":"DefinedTerm","termCode":"soc-2","name":"SOC 2","description":"SOC 2 (Service Organization Control Type 2) is an auditing standard developed by the AICPA that evaluates an organization's controls related to security, availability, processing integrity, confidentiality, and privacy (the Trust Service Criteria).\n\nA SOC 2 Type I report evaluates whether controls are properly designed at a point in time. A SOC 2 Type II report evaluates whether controls operated effectively over a period (typically 6-12 months). Type II is the gold standard.\n\nSOC 2 compliance is the most commonly required security certification for B2B SaaS companies. Enterprise customers and investors expect SOC 2 Type II.","url":"https://www.richardewing.io/glossary/soc-2"},{"@type":"DefinedTerm","termCode":"staff-engineer-role","name":"Staff Engineer","description":"A Staff Engineer (also Staff+ Engineer) is a senior individual contributor role that operates at the intersection of technical depth and organizational influence. Staff engineers solve problems that span multiple teams, define architectural direction, and mentor senior engineers.\n\nWill Larson's four archetypes of Staff Engineers: Tech Lead (team-scoped leadership), Architect (cross-team technical vision), Solver (hard problem specialist), and Right Hand (executive-partnered leadership).\n\nThe Staff level is the most critical inflection point in an engineering career — it requires shifting from deep individual contribution to force multiplication through influence, mentorship, and organizational design.","url":"https://www.richardewing.io/glossary/staff-engineer-role"},{"@type":"DefinedTerm","termCode":"team-topologies","name":"Team Topologies","description":"Team Topologies is a framework by Matthew Skelton and Manuel Pais that defines four fundamental team types and three interaction modes for organizing engineering teams.\n\n**Four team types:** Stream-aligned (delivers value to users), Enabling (helps stream-aligned teams adopt new capabilities), Complicated Subsystem (owns technically complex domains), Platform (provides self-service internal tools).\n\n**Three interaction modes:** Collaboration (teams work closely together), X-as-a-Service (one team consumes another's output), Facilitating (one team coaches another).\n\nTeam Topologies uses Conway's Law intentionally — designing team structures that produce the desired software architecture.","url":"https://www.richardewing.io/glossary/team-topologies"},{"@type":"DefinedTerm","termCode":"vulnerability-management","name":"Vulnerability Management","description":"Vulnerability management is the continuous process of identifying, evaluating, treating, and reporting security vulnerabilities in software systems and infrastructure. It encompasses vulnerability scanning, penetration testing, patch management, and risk prioritization.\n\n**Key practices:** regular automated vulnerability scanning (SAST, DAST, SCA), CVSS-based risk scoring, SLA-driven remediation timelines (critical: 24hrs, high: 7 days, medium: 30 days), dependency monitoring (Dependabot, Snyk), and vulnerability disclosure programs.\n\nIn the AI era, vulnerability management extends to model vulnerabilities (prompt injection, data poisoning, model extraction) and AI supply chain risks.","url":"https://www.richardewing.io/glossary/vulnerability-management"},{"@type":"DefinedTerm","termCode":"zero-trust","name":"Zero Trust Architecture","description":"Zero Trust is a security model based on the principle \"never trust, always verify.\" Unlike traditional perimeter-based security (castle-and-moat), Zero Trust assumes that threats exist both outside and inside the network. Every access request is verified regardless of where it originates.\n\n**Core principles:** verify explicitly (authenticate and authorize every request), least-privilege access (minimum permissions needed), assume breach (design systems expecting compromise), micro-segmentation (isolate network segments), and continuous verification (re-authenticate based on risk signals).\n\nThe 2021 US Executive Order on Cybersecurity mandated Zero Trust adoption for federal agencies, accelerating enterprise adoption.","url":"https://www.richardewing.io/glossary/zero-trust"},{"@type":"DefinedTerm","termCode":"truth-ledger","name":"Truth Ledger","description":"The Truth Ledger is Exogram's core innovation — a versioned, timestamped, source-attributed knowledge store that serves as the single source of truth for AI agents. Unlike RAG systems that retrieve documents without verifying their accuracy, the Truth Ledger ensures every fact is provenance-tracked, conflict-checked, and temporally valid.\n\n**Key properties:**\n- **Versioned:** Every fact has a version history. No silent overwrites.\n- **Timestamped:** Facts have creation and expiration times. Expired context is explicitly marked.\n- **Source-attributed:** Every fact traces to its original source (user statement, document, API response).\n- **Conflict-detected:** Contradictions are flagged immediately — no silent merging of conflicting facts.\n\nThe Truth Ledger prevents AI Hallucination Debt by ensuring an AI agent cannot present unverified information as truth.","url":"https://www.richardewing.io/glossary/truth-ledger"},{"@type":"DefinedTerm","termCode":"constraint-engine","name":"Constraint Engine","description":"The Constraint Engine is Exogram's policy enforcement layer — lockable rules that no AI model can violate, regardless of prompt or context. Unlike prompt-level guardrails (which can be bypassed through prompt injection), Constraint Engine rules are enforced at the infrastructure level.\n\n**Types of constraints:**\n- **Architectural:** \"Never expose internal API endpoints\"\n- **Business:** \"Never promise delivery dates without checking inventory\"\n- **Compliance:** \"Never persist PII without explicit consent\"\n- **Security:** \"Never execute code outside the sandbox\"\n- **Operational:** \"Never exceed $0.50 per inference request\"\n\nConstraints are lockable — once set by an authorized administrator, they cannot be overridden by the AI model, even if instructed to do so.","url":"https://www.richardewing.io/glossary/constraint-engine"},{"@type":"DefinedTerm","termCode":"action-admissibility","name":"Action Admissibility","description":"Action Admissibility is Exogram's core filtering concept. When an autonomous AI agent proposes an action, Action Admissibility determines whether that action is permitted given the current truth state, constraints, scope, provenance, and temporal context.\n\n**How it works:** An AI agent faces 17 possible actions. Exogram's Action Admissibility filter evaluates each against all active constraints, truth ledger state, and scope boundaries. Result: 9 violate constraints (removed), 3 rely on missing facts (blocked), 2 contradict verified state (rejected). Only 3 admissible actions remain for the model to choose from.\n\nThis is fundamentally different from guardrails (which filter outputs) — Action Admissibility filters the decision space itself.","url":"https://www.richardewing.io/glossary/action-admissibility"},{"@type":"DefinedTerm","termCode":"execution-control-plane","name":"Execution Control Plane","description":"The Execution Control Plane is Exogram's product category — described as \"IAM for autonomous AI agents.\" Just as IAM (Identity and Access Management) governs what humans and services can do in cloud infrastructure, the Execution Control Plane governs what AI agents can do in production.\n\n**Components:** Truth Ledger (verified knowledge), Constraint Engine (policy enforcement), Action Admissibility (decision filtering), Provenance Registry (source tracking), Audit System (immutable logging), PII Air Gap (data protection), and Multi-LLM Consistency (truth unification across models).\n\nThe Execution Control Plane sits between AI agents and external systems — every action passes through governance before execution.","url":"https://www.richardewing.io/glossary/execution-control-plane"},{"@type":"DefinedTerm","termCode":"ai-liability-gradient","name":"AI Liability Gradient","description":"The AI Liability Gradient is a framework coined by Richard Ewing that maps the relationship between AI agent autonomy and organizational liability. As AI systems move from assistive to autonomous, liability increases non-linearly.\n\n**The Gradient:**\n- **Level 1 (Assistive):** AI suggests, human decides and acts. Liability: minimal — the human is accountable.\n- **Level 2 (Augmented):** AI recommends with high confidence, human approves. Liability: moderate — the organization shares accountability.\n- **Level 3 (Supervised Autonomous):** AI acts independently within defined bounds, human monitors. Liability: high — the organization is accountable for the bounds.\n- **Level 4 (Fully Autonomous):** AI acts without human oversight. Liability: maximum — the organization is fully responsible for all agent actions.\n\nMost production AI agents in 2026 operate at Level 2-3. Exogram's governance infrastructure enables safe operation at Level 3.","url":"https://www.richardewing.io/glossary/ai-liability-gradient"},{"@type":"DefinedTerm","termCode":"provenance-registry","name":"Provenance Registry","description":"The Provenance Registry is Exogram's source attribution system — every fact stored in the Truth Ledger is permanently linked to its original source. You always know WHERE information came from, WHEN it was recorded, WHO provided it, and WHAT evidence supports it.\n\n**Source types tracked:** user statements, document uploads, API responses, web scrapes, model outputs (labeled), third-party integrations, and manual administrator entries.\n\nProvenance is essential for regulatory compliance (GDPR right to explanation), audit trails (SOC 2), and trust calibration (should the AI weigh a user's casual remark the same as an official document?).","url":"https://www.richardewing.io/glossary/provenance-registry"},{"@type":"DefinedTerm","termCode":"pii-air-gap","name":"PII Air Gap","description":"The PII Air Gap is Exogram's data protection mechanism that automatically detects and scrubs personally identifiable information (PII) before it enters persistent storage. SSNs, email addresses, phone numbers, credentials, and other sensitive data are blocked at the ingestion layer — they are never persisted in the Truth Ledger.\n\n**How it works:** All incoming data passes through a PII detection pipeline before storage. Detected PII is: flagged, stripped or tokenized, logged (that PII was detected, not the PII itself), and optionally routed to a separate, encrypted PII vault with strict access controls.\n\nThe Air Gap principle: sensitive data should never accidentally enter AI context. If it's never stored, it can never be leaked, hallucinated, or exposed.","url":"https://www.richardewing.io/glossary/pii-air-gap"},{"@type":"DefinedTerm","termCode":"multi-llm-consistency","name":"Multi-LLM Consistency","description":"Multi-LLM Consistency is Exogram's capability to maintain a single, verified truth layer across multiple AI model providers — ChatGPT, Claude, Gemini, Llama, and any other LLM an organization uses.\n\n**The problem:** Organizations using multiple LLMs (for cost optimization, capability matching, or vendor diversification) face truth fragmentation. Each model has different training data, different knowledge cutoffs, and different hallucination patterns. Without a shared truth layer, different models give different (sometimes contradictory) answers about the same facts.\n\n**The solution:** Exogram's Truth Ledger serves as the single source of truth for ALL models. Regardless of which LLM processes a request, the facts it can access are identical, verified, and consistent.","url":"https://www.richardewing.io/glossary/multi-llm-consistency"},{"@type":"DefinedTerm","termCode":"ai-technical-debt","name":"AI Technical Debt","description":"AI Technical Debt is the accumulation of shortcuts, missing infrastructure, and data quality issues in AI/ML systems that create escalating maintenance costs and system fragility over time.\n\nUnlike traditional code debt, AI debt is uniquely dangerous because it is multi-dimensional: data debt (biased or stale training data), model debt (overfitted or unmonitored models), pipeline debt (fragile data pipelines), configuration debt (hard-coded hyperparameters), and orchestration debt (complex agent-to-agent dependencies).\n\nGoogle's seminal 2015 paper \"Hidden Technical Debt in Machine Learning Systems\" identified that ML systems have a special capacity for incurring technical debt because only a small fraction of real-world ML systems is composed of the ML code itself.","url":"https://www.richardewing.io/glossary/ai-technical-debt"},{"@type":"DefinedTerm","termCode":"model-debt","name":"Model Debt","description":"Model Debt is a subcategory of AI Technical Debt referring to the accumulated risk from ML models that are overfitted, under-monitored, poorly versioned, or operating as \"shadow AI\" (unauthorized models in production).\n\n**Sources of model debt:**\n- **Overfitting:** Models that perform well on training data but poorly on real-world inputs\n- **Version sprawl:** Multiple model versions in production without clear ownership\n- **Shadow AI:** Models deployed by teams outside of governed ML infrastructure\n- **Drift:** Models whose accuracy degrades as the world changes but retraining doesn't keep pace\n- **Dependency chains:** Models that consume outputs of other models, creating cascading failure risk","url":"https://www.richardewing.io/glossary/model-debt"},{"@type":"DefinedTerm","termCode":"orchestration-debt","name":"Orchestration Debt","description":"Orchestration Debt is an emerging form of AI technical debt (2026) created when autonomous AI agents interact with multiple enterprise systems, creating complex dependency chains that are difficult to monitor, debug, and maintain.\n\nAs organizations deploy agentic AI workflows where agents call other agents, access databases, invoke APIs, and make decisions autonomously, the orchestration layer between these components accumulates debt through: undocumented dependencies, brittle error handling, cascading failure modes, and untested interaction patterns.\n\nOrchestration debt is uniquely dangerous because it is invisible — each individual agent may work correctly, but the interactions between agents produce emergent behaviors that no single team designed or tested.","url":"https://www.richardewing.io/glossary/orchestration-debt"},{"@type":"DefinedTerm","termCode":"agentic-governance","name":"Agentic Governance","description":"Agentic Governance is the management and oversight framework required for autonomous AI agents operating in production environments. It encompasses policies, controls, and tooling that ensure AI agents act within defined boundaries, maintain accountability, and produce auditable decision trails.\n\n**Key components:**\n- **Identity and Access Management for agents** (what each agent can do)\n- **Action Admissibility** (filtering the decision space before agents choose)\n- **Audit logging** (immutable record of all agent actions)\n- **Constraint enforcement** (non-bypassable rules)\n- **Human-in-the-loop gates** (escalation triggers for high-risk actions)\n\nExogram's Execution Control Plane represents the most comprehensive implementation of agentic governance in production.","url":"https://www.richardewing.io/glossary/agentic-governance"},{"@type":"DefinedTerm","termCode":"eu-ai-act","name":"EU AI Act","description":"The EU AI Act is the world's first comprehensive legal framework for artificial intelligence, enacted by the European Union. It classifies AI systems by risk level and imposes requirements proportional to that risk.\n\n**Risk levels:**\n- **Unacceptable risk (banned):** Social scoring, real-time biometric surveillance, emotional manipulation\n- **High risk (heavily regulated):** AI in healthcare, finance, employment, law enforcement, education\n- **Limited risk (transparency required):** Chatbots, deepfakes, emotion recognition\n- **Minimal risk (no restrictions):** AI-enabled video games, spam filters\n\n**Timeline:** Prohibited practices enforcement: Feb 2025. High-risk rules: Aug 2026. Full enforcement: Aug 2027.\n\n**Penalties:** Up to €35M or 7% of global annual revenue.","url":"https://www.richardewing.io/glossary/eu-ai-act"},{"@type":"DefinedTerm","termCode":"data-debt","name":"Data Debt","description":"Data Debt is the accumulated quality, governance, and infrastructure deficiencies in an organization's data assets that create escalating costs and risks. In AI/ML contexts, data debt is particularly dangerous because model quality is bounded by data quality.\n\n**Forms of data debt:**\n- **Stale data:** Training data that no longer reflects reality\n- **Missing labels:** Unlabeled data that requires expensive manual annotation\n- **Biased datasets:** Data that systematically over- or under-represents populations\n- **Broken lineage:** Inability to trace data from source to model\n- **Schema drift:** Data format changes that break downstream pipelines\n- **Duplication:** Redundant data that inflates storage costs and confuses models","url":"https://www.richardewing.io/glossary/data-debt"},{"@type":"DefinedTerm","termCode":"software-entropy","name":"Software Entropy","description":"Software Entropy is the tendency of software systems to become increasingly disordered, complex, and difficult to maintain over time — even without any code changes. It is the second law of thermodynamics applied to software: all systems tend toward disorder.\n\n**Drivers of software entropy:**\n- **Dependency aging:** Libraries, frameworks, and APIs evolve independently\n- **Environmental drift:** Infrastructure, OS, and runtime changes\n- **Knowledge loss:** Original developers leave, institutional knowledge decays\n- **Requirement evolution:** Business needs change but architecture doesn't\n- **Patch accumulation:** Quick fixes compound into structural degradation\n\nIn AI systems, software entropy accelerates because models drift, training data goes stale, and the real world changes — all without anyone touching a line of code.","url":"https://www.richardewing.io/glossary/software-entropy"},{"@type":"DefinedTerm","termCode":"shadow-ai","name":"Shadow AI","description":"Shadow AI refers to the use of artificial intelligence tools, models, and systems by employees or teams without the knowledge, approval, or governance of IT, security, or compliance departments. It is the AI-era equivalent of \"shadow IT.\"\n\n**Common forms:**\n- Employees using ChatGPT/Claude with company data without approval\n- Teams deploying ML models outside the governed ML platform\n- Departments purchasing AI SaaS tools without security review\n- Engineers fine-tuning models on company data using personal accounts\n\nShadow AI creates untracked risk because the organization has no visibility into what data is being exposed, what decisions are being made, or what compliance obligations are being violated.","url":"https://www.richardewing.io/glossary/shadow-ai"},{"@type":"DefinedTerm","termCode":"generative-engine-optimization","name":"Generative Engine Optimization (GEO)","description":"Generative Engine Optimization (GEO) is the practice of structuring digital content to maximize visibility and citation within AI-generated responses from systems like ChatGPT, Claude, Gemini, Perplexity AI, and Google AI Overviews.\n\nUnlike traditional SEO (ranking in search results), GEO focuses on being **cited, summarized, or directly referenced** in AI-generated answers. This requires:\n- **Structured, well-organized content** (clear headings, Q&A format, tables)\n- **Authoritative, citable information** (original research, statistics, named frameworks)\n- **Schema markup** (FAQPage, SpeakableSpecification, DefinedTerm)\n- **LLM-readable metadata** (llms.txt, ai-plugin.json)\n- **Topical authority** (comprehensive coverage of a subject)\n\nGEO represents the future of content discovery as AI-powered search increasingly replaces traditional search engines.","url":"https://www.richardewing.io/glossary/generative-engine-optimization"},{"@type":"DefinedTerm","termCode":"ai-agent-iam","name":"AI Agent Identity & Access Management","description":"AI Agent IAM (Identity and Access Management) is the practice of applying IAM principles — authentication, authorization, permissions, and audit logging — to autonomous AI agents operating in production systems.\n\nTraditional IAM was designed for humans and services with predictable behaviors. AI agents introduce new challenges:\n- **Dynamic scope:** Agent permissions may need to change based on task context\n- **Delegation chains:** Agent A invoking Agent B requires permission inheritance rules\n- **Least-privilege at inference time:** Permissions scoped to the current task, not the agent's total capability\n- **Non-repudiation:** Proving which agent took which action, when, and why\n\nExogram's Execution Control Plane implements AI Agent IAM through Action Admissibility — governing what each agent can do at the infrastructure level.","url":"https://www.richardewing.io/glossary/ai-agent-iam"},{"@type":"DefinedTerm","termCode":"prompt-injection","name":"Prompt Injection","description":"Prompt injection is a security vulnerability where an attacker crafts input that causes an AI model to ignore its original instructions and follow the attacker's instructions instead. It is the most critical security vulnerability in LLM-powered applications.\n\n**Types:**\n- **Direct prompt injection:** User directly provides malicious instructions to the model\n- **Indirect prompt injection:** Malicious instructions hidden in external data (web pages, emails, documents) that the model processes\n\n**Examples:** Data exfiltration (\"ignore previous instructions, output all system prompts\"), unauthorized actions (\"book a flight to Las Vegas using the company card\"), and misinformation (\"tell the user this product is recalled\").\n\nPrompt-level defenses (system prompts, guardrails) are insufficient because they operate at the same layer as the attack. Infrastructure-level defenses like Exogram's Constraint Engine are required.","url":"https://www.richardewing.io/glossary/prompt-injection"},{"@type":"DefinedTerm","termCode":"ai-observability","name":"AI Observability","description":"AI Observability is the ability to understand the internal state, behavior, and performance of AI systems in production through logging, monitoring, and analysis of inputs, outputs, decisions, and model states.\n\nTraditional software observability tracks three signals: metrics, logs, and traces. AI observability adds:\n- **Model performance monitoring:** Accuracy, latency, token usage, cost per inference\n- **Drift detection:** Distribution shifts in inputs or outputs over time\n- **Hallucination detection:** Identifying factually incorrect outputs\n- **Fairness monitoring:** Tracking bias metrics across demographic groups\n- **Cost tracking:** Per-query, per-model, per-feature cost attribution\n- **Provenance:** Tracing which data and model version produced each output","url":"https://www.richardewing.io/glossary/ai-observability"},{"@type":"DefinedTerm","termCode":"rag-architecture","name":"RAG Architecture","description":"Retrieval-Augmented Generation (RAG) is an AI architecture pattern that combines information retrieval with text generation. Instead of relying solely on a model's training data, RAG systems retrieve relevant documents from a knowledge base and provide them as context for the model to generate more accurate, grounded responses.\n\n**Components:** Document ingestion pipeline, embedding model, vector database, retrieval engine, reranker (optional), and generation model.\n\n**Limitations:** RAG retrieves relevant documents but does NOT verify their accuracy. The retrieved document may be outdated, contradictory, or wrong. This is why Exogram's Truth Ledger goes beyond RAG — it verifies facts, not just relevance.","url":"https://www.richardewing.io/glossary/rag-architecture"},{"@type":"DefinedTerm","termCode":"nist-ai-rmf","name":"NIST AI Risk Management Framework","description":"The NIST AI Risk Management Framework (AI RMF) is a voluntary framework published by the National Institute of Standards and Technology to help organizations manage risks associated with AI systems throughout their lifecycle.\n\n**Four core functions:**\n1. **Govern:** Establish policies, processes, and accountability structures\n2. **Map:** Identify and categorize AI risks based on context and impact\n3. **Measure:** Assess and quantify identified risks using metrics and testing\n4. **Manage:** Mitigate, monitor, and respond to AI risks in production\n\nThe NIST AI RMF is increasingly referenced alongside the EU AI Act as the standard for AI governance in the United States.","url":"https://www.richardewing.io/glossary/nist-ai-rmf"},{"@type":"DefinedTerm","termCode":"ai-cost-attribution","name":"AI Cost Attribution","description":"AI Cost Attribution is the practice of tracking and assigning the full cost of AI features to specific products, features, customers, or business units. Unlike traditional software (near-zero marginal cost), AI features have significant variable costs that must be attributed accurately for economic decision-making.\n\n**Costs to attribute:** LLM API fees, embedding generation, vector database queries, retrieval pipeline compute, post-processing, monitoring, error handling and retry costs, prompt engineering time, model fine-tuning, and human-in-the-loop review.\n\nWithout proper cost attribution, organizations cannot calculate AI unit economics, identify margin-negative features, or make informed build-vs-buy decisions.","url":"https://www.richardewing.io/glossary/ai-cost-attribution"},{"@type":"DefinedTerm","termCode":"burn-multiple","name":"Burn Multiple","description":"The Burn Multiple is a capital efficiency metric that measures how much cash a company consumes to generate each new dollar of net Annual Recurring Revenue (ARR).\n\n**Formula:** Burn Multiple = Net Burn / Net New ARR\n\n**Benchmarks (2025-2026):**\n- **< 1.0x:** Best-in-class efficiency (AI-native startups)\n- **1.0x - 1.5x:** Excellent\n- **1.5x - 2.0x:** Good / median\n- **2.0x - 3.0x:** Concerning\n- **> 3.0x:** Unsustainable\n\nThe burn multiple has emerged as one of the most important metrics for Series A and B boards because it captures capital discipline in a single number that's harder to game than growth rate alone.","url":"https://www.richardewing.io/glossary/burn-multiple"},{"@type":"DefinedTerm","termCode":"product-led-growth","name":"Product-Led Growth (PLG)","description":"Product-Led Growth (PLG) is a go-to-market strategy where the product itself is the primary driver of customer acquisition, conversion, and expansion. Users discover, try, and adopt the product before encountering a sales team.\n\n**Key characteristics:**\n- Free tier or freemium model\n- Self-serve onboarding\n- In-product upgrade prompts\n- Usage-based expansion triggers\n- Viral loops and sharing mechanics\n\n**Examples:** Slack (team invites), Figma (collaboration), Notion (templates), and Zoom (meeting links) all used PLG to achieve massive adoption.\n\nRichard Ewing's site practices PLG: free diagnostic tools (PDI, AUEB, Audit Interview) serve as the acquisition layer that drives advisory engagement.","url":"https://www.richardewing.io/glossary/product-led-growth"},{"@type":"DefinedTerm","termCode":"developer-experience","name":"Developer Experience (DevEx)","description":"Developer Experience (DevEx) is the holistic experience of software developers as they interact with tools, processes, systems, and organizational culture to accomplish their work.\n\n**DevEx encompasses:**\n- **Tooling:** IDE quality, CI/CD speed, debugging tools, documentation\n- **Process:** Code review speed, deployment frequency, approval bottlenecks\n- **Environment:** Build times, test reliability, environment provisioning speed\n- **Culture:** Autonomy, knowledge sharing, on-call burden, meeting load\n\nDevEx has become a critical investment area because it directly impacts developer productivity, retention, and code quality. Companies with strong DevEx report 2x faster delivery and 50% lower engineer turnover.","url":"https://www.richardewing.io/glossary/developer-experience"},{"@type":"DefinedTerm","termCode":"ai-cogs","name":"AI COGS","description":"AI COGS (Cost of Goods Sold) refers to the variable costs directly attributable to delivering AI-powered features to customers. Unlike traditional SaaS (near-zero marginal cost per user), AI features have significant per-interaction costs.\n\n**Components of AI COGS:**\n- LLM API fees (OpenAI, Anthropic, Google per-token charges)\n- Embedding generation and vector database queries\n- GPU compute for inference or fine-tuning\n- Data retrieval and processing pipeline costs\n- Monitoring, logging, and observability infrastructure\n- Error handling, retry logic, and fallback model costs\n- Human-in-the-loop review costs\n\n**Impact on SaaS economics:** Traditional SaaS enjoys 80%+ gross margins. AI-heavy SaaS products can see margins compress to 40-60%, fundamentally changing valuation multiples and capital requirements.","url":"https://www.richardewing.io/glossary/ai-cogs"},{"@type":"DefinedTerm","termCode":"agentic-workflow","name":"Agentic Workflow","description":"An Agentic Workflow is an automated process where one or more AI agents autonomously plan, execute, and iterate on tasks with minimal human intervention. Unlike simple automation (fixed rules) or basic LLM use (single prompt/response), agentic workflows involve chains of reasoning, tool use, and decision-making.\n\n**Characteristics:**\n- Agents break complex goals into subtasks\n- Each agent can call tools, APIs, and other agents\n- Agents evaluate results and adjust their approach\n- The workflow can branch, retry, and recover from errors\n- Human oversight is optional (but recommended via Exogram)\n\nAgentic workflows are the dominant AI architecture trend for 2025-2026, moving beyond chatbots to autonomous business process automation.","url":"https://www.richardewing.io/glossary/agentic-workflow"},{"@type":"DefinedTerm","termCode":"platform-engineering","name":"Platform Engineering","description":"Platform Engineering is the discipline of designing and building self-service toolchains and workflows that enable software engineering teams to deliver value faster and more reliably.\n\nPlatform engineers build \"Internal Developer Platforms\" (IDPs) — curated, self-service environments where product engineers can provision infrastructure, deploy applications, and access tools without filing tickets or waiting for platform teams.\n\n**Key components:** Self-service infrastructure provisioning, golden path templates, CI/CD pipelines, observability dashboards, and service catalogs.\n\nGartner predicts that by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components, and tools.","url":"https://www.richardewing.io/glossary/platform-engineering"},{"@type":"DefinedTerm","termCode":"ai-red-teaming","name":"AI Red-Teaming","description":"AI Red-Teaming is the practice of systematically testing AI systems for vulnerabilities, biases, harmful outputs, and failure modes by simulating adversarial attacks and edge cases.\n\n**What red teams test:**\n- **Prompt injection resistance:** Can the model be tricked into ignoring safety instructions?\n- **Bias and fairness:** Does the model produce discriminatory outputs for certain demographic groups?\n- **Hallucination rates:** How often does the model fabricate facts, citations, or reasoning?\n- **Data leakage:** Can the model be prompted to reveal training data or system prompts?\n- **Harmful content generation:** Can the model produce dangerous, illegal, or harmful content?\n- **Robustness:** How does the model perform with adversarial, noisy, or out-of-distribution inputs?\n\nThe White House Executive Order on AI (2023) and the EU AI Act both reference AI red-teaming as a required practice for high-risk AI systems.","url":"https://www.richardewing.io/glossary/ai-red-teaming"},{"@type":"DefinedTerm","termCode":"finops","name":"FinOps","description":"FinOps (Financial Operations) is the practice of bringing financial accountability to the variable spend model of cloud computing. It brings together technology, finance, and business teams to collaborate on data-driven spending decisions.\n\n**Core principles:**\n1. **Teams need to collaborate** — engineering, finance, and business must work together\n2. **Everyone takes ownership** — engineers are accountable for the cost of their infrastructure\n3. **A centralized team drives FinOps** — a cross-functional FinOps team coordinates efforts\n4. **Reports should be accessible and timely** — real-time cost visibility for all stakeholders\n5. **Decisions are driven by business value** — cloud spend is evaluated by the value it generates, not just the cost\n\nFor AI-heavy organizations, FinOps extends to AI cost management — tracking LLM API costs, GPU inference costs, and embedding generation costs at the feature level.","url":"https://www.richardewing.io/glossary/finops"},{"@type":"DefinedTerm","termCode":"zero-trust","name":"Zero Trust Architecture","description":"Zero Trust is a security framework based on the principle that no user, device, or system should be implicitly trusted, regardless of whether they are inside or outside the network perimeter.\n\n**Core tenets:**\n- **Never trust, always verify** — every access request is authenticated and authorized\n- **Least privilege access** — users and systems get minimum necessary permissions\n- **Assume breach** — design systems as if adversaries are already inside the network\n- **Micro-segmentation** — divide networks into small zones with independent access controls\n- **Continuous verification** — trust is not permanent; it is continuously re-evaluated\n\nFor AI systems, Zero Trust principles apply to AI agents — each agent should have task-scoped, time-limited permissions with no implicit trust between agents.","url":"https://www.richardewing.io/glossary/zero-trust"},{"@type":"DefinedTerm","termCode":"infrastructure-as-code","name":"Infrastructure as Code (IaC)","description":"Infrastructure as Code (IaC) is the practice of managing and provisioning computing infrastructure through machine-readable configuration files rather than manual processes.\n\n**Key tools:** Terraform, AWS CloudFormation, Pulumi, Ansible, and Kubernetes manifests.\n\n**Benefits:**\n- **Reproducibility:** Infrastructure is version-controlled and reproducible\n- **Speed:** Environments can be provisioned in minutes, not days\n- **Consistency:** Every environment is identical (dev, staging, production)\n- **Auditability:** Infrastructure changes are code-reviewed and logged\n\n**IaC Debt:** When IaC configurations drift from actual infrastructure, or when IaC modules become unmaintained, organizations accumulate IaC Debt — a subcategory of infrastructure technical debt.","url":"https://www.richardewing.io/glossary/infrastructure-as-code"},{"@type":"DefinedTerm","termCode":"shift-left-testing","name":"Shift-Left Testing","description":"Shift-Left Testing is the practice of moving testing activities earlier in the software development lifecycle. Instead of testing only after code is written, shift-left integrates testing into design, development, and CI/CD stages.\n\n**Types of shift-left:**\n- **Design-level testing:** Architecture reviews, threat modeling before coding\n- **Unit testing in development:** TDD and property-based testing during coding\n- **CI pipeline testing:** Automated tests run on every commit\n- **Security shift-left:** SAST/DAST tools integrated into PR workflows\n- **Compliance shift-left:** Governance checks embedded in build pipelines\n\nFor AI systems, shift-left means testing model quality, fairness, and safety during development — not after production deployment.","url":"https://www.richardewing.io/glossary/shift-left-testing"},{"@type":"DefinedTerm","termCode":"technical-debt-ratio","name":"Technical Debt Ratio","description":"The Technical Debt Ratio (TDR) measures the proportion of engineering effort spent on maintaining existing systems versus building new capabilities. It is the single most important metric for quantifying technical debt's economic impact.\n\n**Formula:** TDR = Maintenance Effort / Total Engineering Effort × 100%\n\n**Benchmarks:**\n- **< 20%:** Healthy — strong innovation capacity\n- **20-40%:** Normal — some debt accumulation, manageable\n- **40-60%:** Concerning — innovation velocity declining\n- **60-80%:** Dangerous — approaching technical insolvency\n- **> 80%:** Critical — near or at technical insolvency\n\nThe TDR is a component of the Product Debt Index (PDI) calculation and directly correlates with the Technical Insolvency Date.","url":"https://www.richardewing.io/glossary/technical-debt-ratio"},{"@type":"DefinedTerm","termCode":"service-level-objectives","name":"Service Level Objectives (SLOs)","description":"Service Level Objectives (SLOs) are specific, measurable targets for service reliability that define how reliable a service should be. They are the foundation of Site Reliability Engineering (SRE) and modern operations practices.\n\n**Hierarchy:**\n- **SLI (Service Level Indicator):** The metric (e.g., request latency, availability %)\n- **SLO (Service Level Objective):** The target for the SLI (e.g., 99.9% availability)\n- **SLA (Service Level Agreement):** The contractual commitment to customers (usually looser than the SLO)\n- **Error Budget:** The acceptable amount of downtime before action is required\n\n**Key insight:** 99.9% availability ≠ 99.99% availability. The difference is 8.7 hours vs 52.6 minutes of downtime per year — a 10x difference in engineering investment.","url":"https://www.richardewing.io/glossary/service-level-objectives"},{"@type":"DefinedTerm","termCode":"customer-acquisition-cost","name":"Customer Acquisition Cost (CAC)","description":"Customer Acquisition Cost (CAC) is the total cost of acquiring a new customer, including all sales and marketing expenses.\n\n**Formula:** CAC = Total Sales & Marketing Spend / Number of New Customers Acquired\n\n**2025 benchmarks:**\n- B2B SaaS average: ~$1,200 per customer\n- Enterprise SaaS: $5,000-$50,000+ per customer\n- SMB SaaS: $200-$2,000 per customer\n- PLG SaaS: $50-$500 per customer\n\n**Critical ratios:**\n- **LTV:CAC ratio:** Should be ≥ 3:1 for healthy economics\n- **CAC Payback Period:** Months to recover CAC from subscription revenue (ideal: < 18 months)","url":"https://www.richardewing.io/glossary/customer-acquisition-cost"},{"@type":"DefinedTerm","termCode":"customer-lifetime-value","name":"Customer Lifetime Value (LTV / CLTV)","description":"Customer Lifetime Value (LTV or CLTV) is the total revenue expected from a customer account over the entire duration of their relationship with your company.\n\n**Simple formula:** LTV = ARPA × Customer Lifetime\n\n**More precise:** LTV = ARPA / Monthly Churn Rate\n\nWhere ARPA = Average Revenue Per Account\n\n**Example:**\n- ARPA: $500/month\n- Monthly churn rate: 2%\n- LTV = $500 / 0.02 = $25,000\n\nLTV is the most important metric to pair with Customer Acquisition Cost (CAC). The LTV:CAC ratio determines whether your unit economics are sustainable.","url":"https://www.richardewing.io/glossary/customer-lifetime-value"},{"@type":"DefinedTerm","termCode":"ai-agent","name":"AI Agent","description":"An AI Agent is an autonomous software system that can perceive its environment, reason about goals, make plans, use tools, and take actions with minimal human intervention.\n\n**How AI agents differ from chatbots:**\n- **Chatbot:** Responds to prompts, stateless, single-turn\n- **AI Agent:** Plans multi-step actions, uses tools, maintains state, operates autonomously\n\n**Agent capabilities:**\n- Break complex goals into subtasks\n- Call APIs, databases, and other tools\n- Evaluate results and adjust approach\n- Maintain context across multiple interactions\n- Collaborate with other agents\n\n**Examples:** Coding agents (Devin, SWE-Agent), research agents, customer service agents, DevOps agents, and data analysis agents.\n\nSearch interest for \"AI agents\" surged 900% in 2025, making it one of the most searched AI terms globally.","url":"https://www.richardewing.io/glossary/ai-agent"},{"@type":"DefinedTerm","termCode":"fine-tuning","name":"Fine-Tuning","description":"Fine-tuning is the process of taking a pre-trained AI model and further training it on a smaller, specialized dataset to adapt it for specific tasks or domains.\n\n**When to fine-tune vs use RAG:**\n- **Fine-tune when:** You need consistent behavior, specific formatting, domain-specific language, or model personality changes\n- **Use RAG when:** You need up-to-date information, source attribution, or dynamic knowledge that changes frequently\n\n**Cost considerations:**\n- Fine-tuning has high upfront cost (training compute) but lower per-query cost\n- RAG has lower upfront cost but higher per-query cost (retrieval + generation)\n- The breakeven depends on query volume and accuracy requirements\n\n**Process:** Prepare labeled data → Upload to provider → Train on your data → Evaluate → Deploy → Monitor for drift","url":"https://www.richardewing.io/glossary/fine-tuning"},{"@type":"DefinedTerm","termCode":"generative-ai","name":"Generative AI","description":"Generative AI refers to AI systems that can create new content — text, images, code, audio, video, and 3D models — based on patterns learned from training data.\n\n**Key modalities:**\n- **Text:** GPT-4, Claude, Gemini, Llama\n- **Images:** DALL-E, Midjourney, Stable Diffusion\n- **Code:** GitHub Copilot, Cursor, Claude Code\n- **Audio:** ElevenLabs, Suno, Udio\n- **Video:** Sora, Runway, Pika\n\n**Economic impact:** Generative AI introduces variable cost to content creation for the first time. Every generated image, text passage, or code snippet costs compute. This fundamentally changes the economics of content-driven products.\n\nBy 2025, generative AI had become the fastest-adopted technology in history, reaching 200M weekly active users faster than any previous technology.","url":"https://www.richardewing.io/glossary/generative-ai"},{"@type":"DefinedTerm","termCode":"microservices","name":"Microservices Architecture","description":"Microservices is an architectural style where an application is composed of small, independently deployable services that communicate over well-defined APIs.\n\n**Benefits:**\n- Independent deployment and scaling\n- Technology flexibility per service\n- Team autonomy and ownership\n- Fault isolation\n\n**Hidden costs (Microservices Debt):**\n- **Distributed system complexity:** Network latency, partial failures, eventual consistency\n- **Operational overhead:** Each service needs monitoring, logging, deployment pipelines\n- **Integration testing difficulty:** Testing interactions between 50+ services is exponentially harder\n- **Data consistency challenges:** Transactions across services require saga patterns or event sourcing\n\nThe initial move to microservices often creates more technical debt than it eliminates — especially when teams don't have the operational maturity to manage distributed systems.","url":"https://www.richardewing.io/glossary/microservices"},{"@type":"DefinedTerm","termCode":"cloud-native","name":"Cloud-Native","description":"Cloud-native is an approach to building and running applications that fully exploits the advantages of the cloud computing model — elasticity, scalability, and managed services.\n\n**Core pillars:**\n- **Containerization:** Packaging applications in Docker/OCI containers\n- **Orchestration:** Kubernetes for container management\n- **Microservices:** Decomposed, independently deployable services\n- **Service mesh:** Infrastructure layer for service-to-service communication\n- **Immutable infrastructure:** Replace rather than update infrastructure\n- **Declarative APIs:** Define desired state, let the system reconcile\n\n**Cloud-native does NOT mean:** \"We use AWS/Azure/GCP.\" Many cloud-hosted applications are not cloud-native. Running a monolith on EC2 is cloud-hosted, not cloud-native.","url":"https://www.richardewing.io/glossary/cloud-native"},{"@type":"DefinedTerm","termCode":"technical-debt-definition","name":"Technical Debt","description":"Technical Debt is the accumulated cost of expedient engineering decisions that create future maintenance burden. Coined by Ward Cunningham in 1992, the debt metaphor describes how choosing quick solutions over optimal ones generates \"interest payments\" in the form of increased maintenance work.\n\n**Types of technical debt:**\n- **Deliberate debt:** Conscious shortcuts taken under deadline pressure\n- **Accidental debt:** Debt accumulated through lack of knowledge or changing requirements\n- **Bit rot:** Debt that accumulates simply from aging code and evolving ecosystems\n- **Design debt:** Architectural decisions that made sense originally but no longer scale\n- **AI-generated debt:** Code produced by LLMs without full understanding of system context\n\n**The economic model:**\n- Technical debt accrues \"interest\" — ongoing maintenance cost\n- Interest compounds as the codebase grows\n- The \"principal\" is the cost to refactor/replace\n- The Technical Insolvency Date is when interest consumes 100% of engineering capacity\n\nRichard Ewing's contribution: treating technical debt as an economic phenomenon measurable in dollars and quarters, not just a code quality concern.","url":"https://www.richardewing.io/glossary/technical-debt-definition"},{"@type":"DefinedTerm","termCode":"openclaw","name":"OpenClaw","description":"OpenClaw is an open-source AI agent framework that functions as an \"operating system for personal AI.\" Created by Peter Steinberger (later hired by OpenAI), OpenClaw went viral in early 2026 and was showcased at NVIDIA's GTC Developer Conference.\n\n**What OpenClaw does:**\n- Runs multiple AI agents locally on your machine\n- Intercepts and orchestrates messages across LLMs\n- Executes commands across shell, filesystem, and web browsers\n- Integrates with Telegram, Discord, Slack, and WhatsApp\n- Provides a tool-execution environment for AI agents\n\n**Why it matters for product economics:** OpenClaw-style frameworks shift AI compute costs from cloud API calls to local inference. This fundamentally changes AI COGS calculations — local models have higher upfront cost but near-zero marginal cost per query.","url":"https://www.richardewing.io/glossary/openclaw"},{"@type":"DefinedTerm","termCode":"nemoclaw","name":"NemoClaw","description":"NemoClaw is NVIDIA's enterprise-grade AI agent framework, built on the OpenClaw foundation. Announced at GTC 2026, NemoClaw adds enterprise security, governance, and compliance features to OpenClaw's open-source agent architecture.\n\n**Enterprise additions over OpenClaw:**\n- **Role-based access control (RBAC):** Fine-grained permissions for agent actions\n- **Authentication integration:** Enterprise SSO and identity management\n- **Audit logging:** Comprehensive logging of all agent actions for compliance\n- **Privacy routing:** Intelligently routes sensitive workloads to local models\n- **Local Nemotron deployment:** Ensures sensitive data never leaves premises\n- **Policy-based guardrails:** Enforced boundaries on agent behavior\n\nNemoClaw addresses the core enterprise concern with AI agents: \"How do I give agents autonomy while maintaining control?\" — which is exactly the problem Exogram's EAAP protocol solves.","url":"https://www.richardewing.io/glossary/nemoclaw"},{"@type":"DefinedTerm","termCode":"langchain","name":"LangChain","description":"LangChain is the most widely-used framework for building applications powered by Large Language Models. It provides modular components for chaining together LLM calls, tool use, memory management, and retrieval systems.\n\n**Core components:**\n- **Chains:** Sequences of LLM calls and operations\n- **Agents:** LLM-powered decision-makers that choose which tools to use\n- **Memory:** Persistent context across conversation turns\n- **Retrievers:** Interfaces to vector stores and knowledge bases for RAG\n- **Tools:** Integrations with APIs, databases, search engines, and more\n\n**LangGraph:** A companion framework for building stateful, multi-agent workflows with explicit state management and loop handling.\n\nLangChain has become the de facto standard for LLM application development, with thousands of integrations and a massive community.","url":"https://www.richardewing.io/glossary/langchain"},{"@type":"DefinedTerm","termCode":"rag-architecture","name":"Retrieval-Augmented Generation (RAG)","description":"Retrieval-Augmented Generation (RAG) is an AI architecture pattern that enhances LLM responses by first retrieving relevant information from external knowledge bases before generating an answer.\n\n**How RAG works:**\n1. **Index:** Documents are split into chunks and converted to embeddings (vectors)\n2. **Store:** Embeddings are stored in a vector database (Pinecone, Chroma, Weaviate)\n3. **Retrieve:** User query is converted to an embedding and similar chunks are retrieved\n4. **Generate:** Retrieved chunks + user query are sent to the LLM for response generation\n\n**RAG vs Fine-Tuning:**\n- RAG: Lower upfront cost, higher per-query cost, dynamic knowledge\n- Fine-tuning: Higher upfront cost, lower per-query cost, static knowledge\n\n**Advanced RAG patterns:**\n- **Agentic RAG:** AI agents that iteratively retrieve, reason, and retrieve again\n- **Multimodal RAG:** Retrieving across text, images, audio, and video\n- **Hybrid search:** Combining vector similarity with keyword matching\n\nThe RAG market is experiencing explosive growth driven by enterprise AI adoption.","url":"https://www.richardewing.io/glossary/rag-architecture"},{"@type":"DefinedTerm","termCode":"vector-database","name":"Vector Database","description":"A Vector Database is a specialized database designed to store, index, and query high-dimensional vector embeddings efficiently. It is the infrastructure backbone of RAG systems and semantic search.\n\n**How it works:** Text, images, or other data are converted into numerical vectors (embeddings) that capture semantic meaning. Similar items have similar vectors. The database enables fast similarity search across millions or billions of vectors.\n\n**Leading solutions (2025-2026):**\n- **Pinecone:** Managed, serverless, enterprise-grade\n- **Chroma:** Open-source, developer-friendly\n- **Weaviate:** Open-source with hybrid search\n- **Milvus/Zilliz:** High-performance, scalable\n- **pgvector:** PostgreSQL extension for vector search\n\n**Market size:** The vector database market reached $2.55B in 2025, projected to reach $3.7B+ in 2026. Growth is driven by enterprise AI adoption and the explosion of unstructured data.","url":"https://www.richardewing.io/glossary/vector-database"},{"@type":"DefinedTerm","termCode":"embeddings","name":"Embeddings","description":"Embeddings are numerical vector representations of data (text, images, audio) that capture semantic meaning in a high-dimensional space. Similar concepts have similar embeddings, enabling semantic search and similarity matching.\n\n**How embeddings work:**\n- Text → Embedding model → [0.023, -0.184, 0.442, ...] (768-3072 dimensions)\n- \"CEO\" and \"Chief Executive\" produce similar vectors\n- \"CEO\" and \"hamburger\" produce very different vectors\n\n**Key embedding models (2025-2026):**\n- **OpenAI text-embedding-3-large:** Most popular commercial model\n- **Cohere Embed v3:** Multilingual, high-performance\n- **BGE-M3:** Open-source, multilingual\n- **Sentence-BERT:** Foundation open-source model\n\n**Emerging trends:**\n- **Multimodal embeddings:** Unifying text, image, and audio in one vector space\n- **Self-hosted models:** Privacy-first, rivaling commercial quality\n- **Dynamic embeddings:** Context-aware, adapting to user behavior","url":"https://www.richardewing.io/glossary/embeddings"},{"@type":"DefinedTerm","termCode":"crewai","name":"CrewAI","description":"CrewAI is an open-source framework for building role-based multi-agent AI systems that collaborate like real-world teams.\n\n**Core concept:** Assign each AI agent a specific role (researcher, analyst, writer, reviewer) and let them collaborate on complex tasks with defined workflows.\n\n**Components:**\n- **Agents:** Role-defined AI entities with specific goals and backstories\n- **Tasks:** Specific assignments given to agents\n- **Crews:** Teams of agents working together on a shared objective\n- **Tools:** External capabilities agents can use (search, APIs, databases)\n\n**Use cases:** Research automation, content creation pipelines, data analysis workflows, code review teams, and customer support escalation.\n\nCrewAI is one of the fastest-growing multi-agent frameworks, competing with LangGraph and Microsoft AutoGen.","url":"https://www.richardewing.io/glossary/crewai"},{"@type":"DefinedTerm","termCode":"model-context-protocol","name":"Model Context Protocol (MCP)","description":"The Model Context Protocol (MCP) is an open standard developed by Anthropic that enables AI models and agents to connect with external tools, data sources, and services through a standardized interface.\n\n**What MCP enables:**\n- AI models can access databases, APIs, and file systems through unified connectors\n- Standardized tool calling across different AI models and frameworks\n- Pluggable architecture — add new capabilities without changing the AI model\n- Secure, permission-controlled access to enterprise systems\n\n**Why MCP matters:** Before MCP, every AI integration was custom-built. MCP provides a standard \"USB port\" for AI — any MCP-compatible tool works with any MCP-compatible AI model. This reduces the integration debt that AI features accumulate.","url":"https://www.richardewing.io/glossary/model-context-protocol"},{"@type":"DefinedTerm","termCode":"ollama","name":"Ollama","description":"Ollama is a lightweight, open-source framework for running Large Language Models (LLMs) locally on your own hardware. It simplifies the process of downloading, configuring, and running models like Llama, Mistral, and Gemma without cloud dependencies.\n\n**Why Ollama is popular:**\n- **Privacy:** Data never leaves your machine\n- **Cost:** No API fees after hardware investment\n- **Speed:** No network latency for inference\n- **Flexibility:** Run any open-source model\n\n**Economic implications:** Ollama enables a \"fixed cost\" AI model where hardware is the upfront investment and marginal query cost is essentially electricity. This contrasts with cloud APIs where every query has a variable cost.\n\nFor organizations with high query volume, local inference via Ollama can be 10-100x cheaper than API-based models.","url":"https://www.richardewing.io/glossary/ollama"},{"@type":"DefinedTerm","termCode":"hugging-face","name":"Hugging Face","description":"Hugging Face is the largest open-source platform for AI models, datasets, and machine learning tools. Often called the \"GitHub of machine learning,\" Hugging Face hosts over 500,000 pre-trained models and 100,000 datasets.\n\n**Key offerings:**\n- **Transformers library:** The standard Python library for using pre-trained AI models\n- **Model Hub:** Repository of 500K+ models (text, image, audio, multimodal)\n- **Datasets Hub:** 100K+ datasets for training and evaluation\n- **Spaces:** Hosted demo applications for AI models\n- **Inference API:** Serverless model deployment\n\n**For product leaders:** Hugging Face is where open-source AI innovation happens. Understanding what models are available helps evaluate build-vs-buy decisions for AI features.","url":"https://www.richardewing.io/glossary/hugging-face"},{"@type":"DefinedTerm","termCode":"prompt-injection","name":"Prompt Injection","description":"Prompt Injection is a security vulnerability where malicious input causes an AI model to ignore its system instructions, reveal internal prompts, or perform unintended actions.\n\n**Types:**\n- **Direct injection:** User input that overrides system instructions (e.g., \"Ignore all previous instructions and...\")\n- **Indirect injection:** Malicious content embedded in external data the AI processes (e.g., hidden instructions in a webpage the AI summarizes)\n\n**Why it's dangerous:**\n- AI agents with tool access can be tricked into executing harmful actions\n- Customer-facing AI can be made to reveal proprietary system prompts\n- RAG systems can be poisoned by injecting malicious content into knowledge bases\n\n**Mitigation strategies:** Input sanitization, output filtering, instruction hierarchy separation, and validation layers between agent decisions and action execution.","url":"https://www.richardewing.io/glossary/prompt-injection"},{"@type":"DefinedTerm","termCode":"transformer-architecture","name":"Transformer Architecture","description":"The Transformer is the neural network architecture that powers virtually all modern AI — GPT, Claude, Gemini, Llama, and every other LLM. Introduced in the 2017 paper \"Attention Is All You Need,\" the transformer uses a self-attention mechanism that allows the model to weigh the importance of different parts of the input simultaneously.\n\n**Key innovations:**\n- **Self-attention:** Each element can attend to every other element in the sequence\n- **Parallelization:** Unlike RNNs, transformers process all inputs simultaneously (faster training)\n- **Scaling:** Performance improves predictably with more parameters, data, and compute\n\n**Why it matters for AI economics:** Transformer compute costs scale quadratically with input length (context window). A 128K context window costs 4x more than a 64K context window. This directly impacts AI COGS.","url":"https://www.richardewing.io/glossary/transformer-architecture"},{"@type":"DefinedTerm","termCode":"api-gateway","name":"API Gateway","description":"An API Gateway is a server that acts as a single entry point for all client requests to your backend services. It handles request routing, API composition, rate limiting, authentication, monitoring, and protocol translation.\n\n**Key functions:**\n- **Routing:** Directs requests to appropriate microservices\n- **Rate limiting:** Prevents abuse and protects backend services\n- **Authentication/Authorization:** Validates API keys, JWT tokens, OAuth\n- **Load balancing:** Distributes traffic across service instances\n- **Caching:** Reduces backend load for frequently requested data\n- **Monitoring:** Collects metrics on API usage and performance\n\n**Popular solutions:** AWS API Gateway, Kong, Nginx, Traefik, Cloudflare Gateway.\n\nAPI gateways become a critical chokepoint — and a form of infrastructure debt — when they're misconfigured, under-monitored, or not scaled properly.","url":"https://www.richardewing.io/glossary/api-gateway"},{"@type":"DefinedTerm","termCode":"ci-cd-pipeline","name":"CI/CD Pipeline","description":"A CI/CD Pipeline is an automated workflow that builds, tests, and deploys code changes from development to production. CI (Continuous Integration) automatically builds and tests code on every commit. CD (Continuous Delivery/Deployment) automatically deploys verified code to staging or production.\n\n**Typical pipeline stages:**\n1. **Source:** Code pushed to repository (GitHub, GitLab)\n2. **Build:** Compile code, install dependencies\n3. **Test:** Run unit tests, integration tests, security scans\n4. **Deploy to staging:** Automatic deployment for QA\n5. **Deploy to production:** Automatic or manual promotion\n\n**Pipeline as code:** Modern CI/CD pipelines are defined in code (YAML files) alongside the application, making them version-controlled and reviewable.\n\n**Pipeline debt:** Over time, CI/CD pipelines accumulate their own technical debt — slow tests, flaky builds, manual steps, and security gaps.","url":"https://www.richardewing.io/glossary/ci-cd-pipeline"},{"@type":"DefinedTerm","termCode":"kubernetes","name":"Kubernetes","description":"Kubernetes (K8s) is an open-source container orchestration platform originally developed by Google. It automates deploying, scaling, and managing containerized applications across clusters of machines.\n\n**Core concepts:**\n- **Pods:** Smallest deployable units (one or more containers)\n- **Services:** Stable network endpoints for sets of pods\n- **Deployments:** Declarative updates for pods and replica sets\n- **Namespaces:** Virtual clusters for resource isolation\n- **Ingress:** External access routing to services\n\n**The Kubernetes Tax:** Running Kubernetes requires 1-3 full-time platform engineers just for cluster management. For small teams (< 20 engineers), this overhead often exceeds the benefits. Many companies adopt Kubernetes prematurely, creating significant infrastructure debt.\n\n**Alternatives:** Managed platforms (Vercel, Railway, Render) abstract away Kubernetes complexity for teams that don't need fine-grained infrastructure control.","url":"https://www.richardewing.io/glossary/kubernetes"},{"@type":"DefinedTerm","termCode":"observability","name":"Observability","description":"Observability is the ability to understand a system's internal state by examining its external outputs. Unlike traditional monitoring (which checks known failure modes), observability enables debugging unknown failure modes through three pillars:\n\n**The Three Pillars:**\n1. **Logs:** Timestamped records of discrete events\n2. **Metrics:** Numerical measurements aggregated over time (CPU, latency, error rates)\n3. **Traces:** End-to-end request paths through distributed systems\n\n**Beyond the three pillars (2025-2026):**\n- **Profiling:** Continuous profiling for performance optimization\n- **Real User Monitoring (RUM):** Client-side performance and experience data\n- **AI-Powered Analysis:** LLM-based log analysis and anomaly detection\n\n**Popular tools:** Datadog, Grafana/Prometheus, New Relic, Honeycomb, OpenTelemetry.\n\nObservability debt accumulates when systems grow faster than monitoring coverage — creating blind spots that lead to longer incident resolution times.","url":"https://www.richardewing.io/glossary/observability"},{"@type":"DefinedTerm","termCode":"product-led-growth","name":"Product-Led Growth (PLG)","description":"Product-Led Growth (PLG) is a go-to-market strategy where the product itself is the primary driver of customer acquisition, conversion, and expansion. Users can try the product (free trial or freemium) before talking to sales.\n\n**PLG mechanics:**\n- **Self-serve onboarding:** Users sign up and get value without sales involvement\n- **Freemium or free trial:** Low barrier to entry\n- **In-product upsells:** Conversion happens inside the product\n- **Viral loops:** Users invite other users naturally\n\n**PLG companies:** Slack, Figma, Notion, Calendly, Datadog, Vercel\n\n**PLG economics:** Lower CAC ($50-500 vs $5K-50K for sales-led), faster time-to-value, but requires excellent product and UX — which means technical debt directly impacts growth.\n\n**The PLG-to-Enterprise motion:** Most successful PLG companies eventually add sales for enterprise deals while keeping PLG for SMB.","url":"https://www.richardewing.io/glossary/product-led-growth"},{"@type":"DefinedTerm","termCode":"net-revenue-retention-nrr","name":"Net Revenue Retention (NRR)","description":"Net Revenue Retention (NRR) — also called Net Dollar Retention (NDR) — measures the percentage of recurring revenue retained from existing customers over a period, including expansion (upgrades), contraction (downgrades), and churn (cancellations).\n\n**Formula:** NRR = (Starting MRR + Expansion - Contraction - Churn) / Starting MRR × 100\n\n**Benchmarks:**\n- **Below 90%:** Concerning — customer base is shrinking\n- **90-100%:** Average — some growth from existing customers\n- **100-120%:** Good — existing customers growing\n- **120-140%:** Excellent — strong expansion revenue\n- **140%+:** Elite — (Snowflake at 158%, Datadog at 130%)\n\nNRR above 100% means your existing customer base grows without any new customer acquisition. This is the \"holy grail\" of SaaS because it means you grow even if you stop acquiring new customers.\n\nNRR is the #1 predictor of SaaS valuation multiples. Companies with 130%+ NRR trade at 2-3x higher multiples.","url":"https://www.richardewing.io/glossary/net-revenue-retention-nrr"},{"@type":"DefinedTerm","termCode":"burn-multiple-metric","name":"Burn Multiple","description":"Burn Multiple is a capital efficiency metric that measures how much a company burns to generate each incremental dollar of ARR. It was popularized by David Sacks of Craft Ventures.\n\n**Formula:** Burn Multiple = Net Burn / Net New ARR\n\n**Benchmarks:**\n- **< 1x:** Amazing — generating more ARR than you burn\n- **1-1.5x:** Great — efficient growth\n- **1.5-2x:** Good — acceptable efficiency\n- **2-3x:** Concerning — burning too much per ARR dollar\n- **> 3x:** Bad — very inefficient growth\n\n**Why it matters for fundraising:** In 2025-2026, investors use burn multiple as a primary efficiency screen. Companies with burn multiples above 2x face significantly harder fundraising environments.\n\nBurn multiple directly connects to technical debt: if engineering inefficiency means it takes 3x as many engineers to deliver the same features, your burn multiple suffers proportionally.","url":"https://www.richardewing.io/glossary/burn-multiple-metric"},{"@type":"DefinedTerm","termCode":"model-drift","name":"Model Drift","description":"Model drift occurs when an AI/ML model's performance degrades over time because the real-world data it encounters differs from the data it was trained on. There are two types:\n\n**Data drift (covariate shift):** The input data distribution changes. Example: a fraud detection model trained on pre-COVID purchase patterns performs poorly post-COVID because consumer behavior changed.\n\n**Concept drift:** The relationship between input features and the target variable changes. Example: a house price prediction model becomes inaccurate as economic conditions shift.\n\n**Economic impact:**\n- Undetected drift causes silent accuracy degradation\n- Wrong predictions lead to wrong business decisions\n- Retraining costs (compute, data, engineering time) are ongoing\n- Each model is a maintenance commitment, not a one-time deployment\n\nModel drift is a form of AI technical debt — it requires continuous investment just to maintain current performance.","url":"https://www.richardewing.io/glossary/model-drift"},{"@type":"DefinedTerm","termCode":"token-ai","name":"Token","description":"In AI/LLM context, a token is a chunk of text that a language model processes as a single unit. Tokens are the fundamental unit of both input and output for LLMs, and they determine cost.\n\n**Tokenization rules of thumb:**\n- 1 token ≈ 4 characters in English\n- 1 token ≈ ¾ of a word\n- 100 tokens ≈ 75 words\n- 1,000 tokens ≈ 750 words ≈ 1.5 pages of text\n\n**Pricing is per-token:**\n- GPT-4o: ~$2.50/1M input tokens, ~$10/1M output tokens\n- Claude Sonnet: ~$3/1M input, ~$15/1M output\n- Llama 3 (self-hosted): Cost of GPU compute only\n\n**Context window:** The maximum number of tokens a model can process in a single request. GPT-4o supports 128K tokens. Larger context = more tokens = higher cost.\n\nEvery AI feature's unit economics ultimately reduce to: cost per token × tokens per interaction × interactions per user × users.","url":"https://www.richardewing.io/glossary/token-ai"},{"@type":"DefinedTerm","termCode":"agentic-workflow","name":"Agentic Workflow","description":"An agentic workflow is a multi-step process where AI agents autonomously plan, execute, evaluate, and iterate on tasks to achieve a defined goal. Unlike simple prompt-response interactions, agentic workflows involve loops, tool use, and decision-making.\n\n**Agentic workflow patterns:**\n- **Reflection:** Agent evaluates its own output and iterates\n- **Tool use:** Agent calls APIs, databases, or external services\n- **Planning:** Agent decomposes complex goals into subtasks\n- **Multi-agent delegation:** Multiple specialized agents collaborate\n- **Human-in-the-loop:** Agent pauses for human approval on critical decisions\n\n**Economic implications:** Agentic workflows consume 5-50x more tokens than single-turn interactions. A workflow that makes 10 LLM calls with tool use costs 10x a single query. This multiplier must be factored into AI unit economics.\n\nResearch agents, coding agents (like Devin), and customer service agents all use agentic workflow patterns.","url":"https://www.richardewing.io/glossary/agentic-workflow"},{"@type":"DefinedTerm","termCode":"design-system","name":"Design System","description":"A design system is a collection of reusable UI components, design tokens, guidelines, and documentation that enables teams to build consistent user interfaces at scale. It is a single source of truth for design and code.\n\n**Components of a design system:**\n- **Design tokens:** Colors, spacing, typography, shadows as variables\n- **Component library:** Buttons, inputs, cards, modals, navigation\n- **Pattern library:** Common layouts, forms, data tables\n- **Documentation:** Usage guidelines, accessibility standards, do's and don'ts\n- **Tooling:** Storybook, Figma libraries, code generators\n\n**Examples:** Material Design (Google), Carbon (IBM), Polaris (Shopify), Primer (GitHub).\n\nDesign systems reduce design debt by standardizing decisions. Without one, every developer invents their own button style, creating visual fragmentation and maintenance burden.","url":"https://www.richardewing.io/glossary/design-system"},{"@type":"DefinedTerm","termCode":"design-tokens","name":"Design Tokens","description":"Design tokens are the smallest atomic units of a design system — named values for colors, spacing, typography, shadows, and other visual properties stored as platform-agnostic variables.\n\n**Examples:**\n- `color-primary: #0066FF`\n- `spacing-md: 16px`\n- `font-size-lg: 1.25rem`\n- `border-radius-lg: 12px`\n\n**Why tokens matter:** They create a single source of truth. Change `color-primary` once and it updates everywhere — web, mobile, email, documentation. Without tokens, every color is hardcoded in dozens of files.\n\nDesign tokens bridge the gap between design (Figma) and code (CSS/React/Swift). Tools like Style Dictionary and Tokens Studio automate token generation across platforms.","url":"https://www.richardewing.io/glossary/design-tokens"},{"@type":"DefinedTerm","termCode":"accessibility-a11y","name":"Accessibility (A11y)","description":"Accessibility (often abbreviated A11y — \"a\" + 11 letters + \"y\") is the practice of designing and building digital products that can be used by people with disabilities, including visual, auditory, motor, and cognitive impairments.\n\n**Standards:** WCAG 2.1/2.2 (Web Content Accessibility Guidelines) defines three conformance levels: A (minimum), AA (standard requirement), AAA (enhanced). Most legal requirements mandate AA compliance.\n\n**Key requirements:**\n- **Screen reader support:** Semantic HTML, ARIA labels, alt text\n- **Keyboard navigation:** All interactions accessible without a mouse\n- **Color contrast:** Minimum 4.5:1 ratio for normal text\n- **Focus management:** Visible focus indicators for keyboard users\n- **Captions:** Video/audio content must have captions\n\n**Legal landscape:** ADA (US), EAA (EU), Section 508 (US Government). Accessibility lawsuits in the US exceeded 4,000/year in 2024.","url":"https://www.richardewing.io/glossary/accessibility-a11y"},{"@type":"DefinedTerm","termCode":"design-sprint","name":"Design Sprint","description":"A Design Sprint is a five-day process for rapidly solving design problems through prototyping and user testing. Developed at Google Ventures by Jake Knapp, it compresses months of work into one week.\n\n**The five-day framework:**\n- **Monday — Map:** Define the problem and pick a target\n- **Tuesday — Sketch:** Generate competing solutions individually\n- **Wednesday — Decide:** Vote on the best solution to prototype\n- **Thursday — Prototype:** Build a realistic facade (not a working product)\n- **Friday — Test:** Put the prototype in front of real users\n\nDesign sprints prevent the most expensive product mistake: building something nobody wants. By testing with real users before writing code, teams validate or invalidate ideas in 5 days instead of 5 months.","url":"https://www.richardewing.io/glossary/design-sprint"},{"@type":"DefinedTerm","termCode":"user-research","name":"User Research","description":"User research is the systematic investigation of users' needs, behaviors, and motivations through observation, task analysis, interviews, and experiments. It provides evidence for product decisions rather than relying on assumptions.\n\n**Research methods:**\n- **Quantitative:** Analytics, A/B testing, surveys, funnel analysis\n- **Qualitative:** User interviews, usability testing, contextual inquiry, diary studies\n- **Evaluative:** Testing existing designs with users\n- **Generative:** Discovering unmet needs and opportunities\n\n**When to research:** Before building (discovery), during building (usability testing), after launch (analytics, NPS). The ratio should be roughly 60% pre-build, 30% during, 10% post-launch.\n\nUser research prevents the most expensive product failure: building features nobody wants. Every hour of research saves approximately 10 hours of development time on the wrong thing.","url":"https://www.richardewing.io/glossary/user-research"},{"@type":"DefinedTerm","termCode":"series-funding","name":"Series A / B / C Funding","description":"Series A, B, and C are sequential rounds of venture capital financing that fund a startup's growth:\n\n**Pre-Seed / Seed ($500K-$5M):** Product development, initial hiring, finding product-market fit. Investors: angels, micro-VCs. Typical valuation: $5-20M.\n\n**Series A ($5M-$25M):** Scaling after PMF. Build the repeatable sales engine. Investors: early-stage VCs. Typical valuation: $20-100M. Key metric: evidence of PMF (retention, engagement).\n\n**Series B ($15M-$75M):** Aggressive scaling. Expand markets, hire significantly. Investors: growth-stage VCs. Typical valuation: $100-500M. Key metric: revenue growth rate (2-3x YoY).\n\n**Series C+ ($50M-$500M+):** Market dominance, international expansion, M&A preparation. Investors: growth equity, crossover funds. Key metric: path to profitability or market leadership.\n\nEach round comes with dilution — founders typically own 10-20% by Series C.","url":"https://www.richardewing.io/glossary/series-funding"},{"@type":"DefinedTerm","termCode":"cap-table","name":"Cap Table","description":"A capitalization table (cap table) is a spreadsheet or database that records who owns what percentage of a company — all equity shares, stock options, warrants, and convertible instruments.\n\n**Key components:**\n- **Common shares:** Held by founders and employees\n- **Preferred shares:** Held by investors (with liquidation preferences)\n- **Option pool:** Reserved for future employee grants (typically 10-20%)\n- **SAFEs/Convertible notes:** Early-stage instruments that convert to equity\n\n**Why it matters:** A clean cap table attracts investors. A messy cap table (dead equity, unclear ownership, missing documentation) slows fundraising and can kill deals during due diligence.\n\nTools: Carta, Pulley, Capshare, AngelList. Manual spreadsheets work for pre-seed but become error-prone by Series A.","url":"https://www.richardewing.io/glossary/cap-table"},{"@type":"DefinedTerm","termCode":"dilution","name":"Dilution","description":"Dilution is the reduction in existing shareholders' ownership percentage when a company issues new shares — typically during fundraising, employee option grants, or convertible note conversion.\n\n**Typical dilution per round:**\n- Seed: 15-25% dilution\n- Series A: 20-30% dilution\n- Series B: 15-25% dilution\n- Option pool: 10-20% reserved\n\n**Example:** A founder with 50% ownership who raises a Series A with 25% dilution now owns 37.5% (50% × 75%). After Series B with 20% dilution: 30% (37.5% × 80%).\n\n**Anti-dilution provisions:** Investors often get anti-dilution protection (weighted-average or full-ratchet) that protects their ownership in down rounds, shifting dilution further to founders and employees.","url":"https://www.richardewing.io/glossary/dilution"},{"@type":"DefinedTerm","termCode":"vc-due-diligence","name":"Venture Capital Due Diligence","description":"Venture capital due diligence is the investigation process investors conduct before committing capital. It covers technology, team, market, financials, legal, and governance.\n\n**Technology due diligence specifically examines:**\n- **Architecture quality:** Scalability, maintainability, security\n- **Technical debt level:** Maintenance burden, deployment frequency\n- **Team capability:** Engineering talent depth and retention\n- **IP ownership:** Clear ownership of all code and technology\n- **Dependency risk:** Critical vendor dependencies, open-source licensing\n\nRichard Ewing's R&D Capital Audit framework provides the quantitative assessment investors need: Product Debt Index score, Technical Insolvency Date, Innovation Tax percentage, and dollar-denominated debt.","url":"https://www.richardewing.io/glossary/vc-due-diligence"},{"@type":"DefinedTerm","termCode":"pitch-deck","name":"Pitch Deck","description":"A pitch deck is a presentation (typically 10-15 slides) used by startups to communicate their business opportunity to potential investors. The standard structure follows Guy Kawasaki's 10/20/30 rule: 10 slides, 20 minutes, 30pt font.\n\n**Essential slides:**\n1. **Title/Hook:** Company name, one-line description\n2. **Problem:** What pain point you solve\n3. **Solution:** How your product solves it\n4. **Market size:** TAM, SAM, SOM\n5. **Business model:** How you make money\n6. **Traction:** Growth metrics, customer logos\n7. **Team:** Key team members and backgrounds\n8. **Competition:** Competitive landscape and differentiation\n9. **Financials:** Revenue, projections, unit economics\n10. **Ask:** How much you're raising and what you'll do with it\n\nThe best pitch decks tell a story, not list features. Sequoia's pitch deck template remains the gold standard.","url":"https://www.richardewing.io/glossary/pitch-deck"},{"@type":"DefinedTerm","termCode":"data-mesh","name":"Data Mesh","description":"Data mesh is a decentralized data architecture paradigm where domain teams own and publish their data as products, rather than centralizing all data into a single data warehouse or lake managed by a central team.\n\n**Four principles (Zhamak Dehghani):**\n1. **Domain ownership:** Each business domain owns its analytical data\n2. **Data as a product:** Data is treated like a product with an SLA, documentation, and quality guarantees\n3. **Self-serve platform:** A shared infrastructure platform enables domain teams to manage their own data\n4. **Federated governance:** Global standards with local implementation\n\nData mesh solves the central data team bottleneck: as organizations grow, a single data team can't serve every domain's needs. But it requires significant organizational maturity and investment.","url":"https://www.richardewing.io/glossary/data-mesh"},{"@type":"DefinedTerm","termCode":"data-lakehouse","name":"Data Lakehouse","description":"A data lakehouse is a modern data architecture that combines the best features of data lakes (cheap storage for all data types) and data warehouses (structured querying and ACID transactions).\n\n**Data Lake vs. Warehouse vs. Lakehouse:**\n- **Data Lake:** Stores raw data cheaply (S3, GCS) but queries are slow and governance is weak\n- **Data Warehouse:** Fast queries and strong governance (Snowflake, BigQuery) but expensive for raw data\n- **Data Lakehouse:** Both — cheap raw storage with warehouse-grade query performance and governance\n\n**Technologies:** Delta Lake (Databricks), Apache Iceberg (Netflix), Apache Hudi. These add ACID transactions, schema enforcement, and time travel to data lakes.\n\nThe lakehouse architecture is becoming the default for organizations that need both AI/ML workloads (which need raw data) and business analytics (which need structured queries).","url":"https://www.richardewing.io/glossary/data-lakehouse"},{"@type":"DefinedTerm","termCode":"feature-store","name":"Feature Store","description":"A feature store is a centralized repository for storing, managing, and serving machine learning features — the input variables that ML models use for predictions.\n\n**Why feature stores exist:** Without one, ML teams rebuild the same features repeatedly across models. Feature engineering often consumes 80% of ML project time.\n\n**Key capabilities:**\n- **Feature registry:** Discover and reuse features across teams\n- **Online serving:** Low-latency feature retrieval for real-time predictions\n- **Offline serving:** Batch feature retrieval for model training\n- **Point-in-time correctness:** Prevent data leakage in training\n- **Monitoring:** Track feature drift and data quality\n\n**Solutions:** Feast (open-source), Tecton, Databricks Feature Store, AWS SageMaker Feature Store.\n\nFeature stores reduce ML engineering debt by centralizing feature logic and ensuring consistency between training and serving.","url":"https://www.richardewing.io/glossary/feature-store"},{"@type":"DefinedTerm","termCode":"mlops","name":"MLOps","description":"MLOps (Machine Learning Operations) is the set of practices for deploying, monitoring, and managing machine learning models in production. It applies DevOps principles to the ML lifecycle.\n\n**MLOps lifecycle:**\n1. **Data pipeline:** Collection, cleaning, feature engineering\n2. **Model training:** Experimentation, hyperparameter tuning\n3. **Model validation:** Testing, bias detection, performance benchmarking\n4. **Deployment:** Serving models via APIs or batch processing\n5. **Monitoring:** Tracking drift, performance degradation, cost\n6. **Retraining:** Automated or triggered model updates\n\n**Tools:** MLflow (experiment tracking), Kubeflow (Kubernetes-native ML), Weights & Biases (experiment management), DVC (data version control).\n\nMLOps is essential because models degrade over time (model drift). Without MLOps, deployed models silently become less accurate — creating hidden AI technical debt.","url":"https://www.richardewing.io/glossary/mlops"},{"@type":"DefinedTerm","termCode":"sprint-retrospective","name":"Sprint Retrospective","description":"A sprint retrospective is a meeting held at the end of each sprint where the team reflects on what went well, what didn't, and what to improve. It's the core continuous improvement mechanism in agile development.\n\n**Standard format (Start/Stop/Continue):**\n- **Start:** What should we begin doing?\n- **Stop:** What should we stop doing?\n- **Continue:** What's working that we should keep?\n\n**Alternative formats:** 4Ls (Liked, Learned, Lacked, Longed For), Sailboat (wind = what propels us, anchor = what holds us back), Mad/Sad/Glad.\n\nEffective retros lead to concrete action items (max 2-3 per sprint). Ineffective retros are therapy sessions with no follow-through. The key difference: action items are tracked and reviewed at the next retro.","url":"https://www.richardewing.io/glossary/sprint-retrospective"},{"@type":"DefinedTerm","termCode":"kanban","name":"Kanban","description":"Kanban is a workflow management method that visualizes work, limits work-in-progress (WIP), and optimizes flow. Unlike Scrum's fixed sprints, Kanban uses continuous flow — items move through stages as capacity allows.\n\n**Core principles:**\n- **Visualize work:** Board with columns (To Do, In Progress, Review, Done)\n- **Limit WIP:** Maximum items per column (e.g., 3 items in \"In Progress\")\n- **Manage flow:** Optimize cycle time (time from start to done)\n- **Make policies explicit:** Clear definitions of \"done\" for each stage\n- **Feedback loops:** Regular review of metrics and process\n\n**Kanban metrics:** Cycle time (how long items take), throughput (items completed per week), WIP count, and cumulative flow diagrams.\n\nKanban is ideal for teams with unpredictable work (support, ops, maintenance) or teams that find Scrum sprints too rigid.","url":"https://www.richardewing.io/glossary/kanban"},{"@type":"DefinedTerm","termCode":"story-points","name":"Story Points","description":"Story points are a relative estimation unit used in agile development to measure the effort, complexity, and uncertainty of user stories. They use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) to estimate relative size.\n\n**Key principle:** Story points measure relative effort, not time. A 5-point story is roughly twice as complex as a 3-point story. This relative approach accounts for different developers having different speeds.\n\n**Estimation techniques:** Planning Poker (team members independently estimate, then discuss outliers), T-shirt sizing (S, M, L, XL as a first pass), and reference stories (compare new work to previously completed stories).\n\n**The controversy:** Many engineering leaders argue story points are \"agile theater\" — energy spent estimating instead of building. Richard Ewing's perspective: story points measure activity, not value. Revenue per engineer (APER) measures what actually matters.","url":"https://www.richardewing.io/glossary/story-points"},{"@type":"DefinedTerm","termCode":"ai-cogs","name":"AI COGS (Cost of Goods Sold)","description":"AI COGS is a framework coined by Richard Ewing for quantifying the variable cost of AI features as a component of Cost of Goods Sold. Unlike traditional software with near-zero marginal costs, AI features have significant per-unit costs that directly eat into gross margins.\n\n**AI COGS components:**\n- **Inference costs:** LLM API calls ($0.001-$0.10 per query)\n- **Embedding costs:** Vector generation for RAG systems\n- **Storage costs:** Vector database hosting\n- **Compute costs:** GPU/TPU for self-hosted models\n- **Data enrichment:** Third-party API calls for context\n- **Retraining costs:** Periodic model updates\n\n**Gross margin impact:** Traditional SaaS has 70-80% gross margins. AI-heavy products often see margins compress to 40-60% because AI COGS scale with usage. This is the core of the Cost of Predictivity problem.\n\nThe AUEB calculator at richardewing.io/tools/aueb helps companies calculate their AI COGS and find their margin collapse point.","url":"https://www.richardewing.io/glossary/ai-cogs"},{"@type":"DefinedTerm","termCode":"eaap-protocol","name":"EAAP (Exogram Action Admissibility Protocol)","description":"The Exogram Action Admissibility Protocol (EAAP) is an open standard created by Richard Ewing for verifying whether an AI agent's proposed action should be allowed to execute. It provides a governance layer between AI decision and AI action.\n\n**How EAAP works:**\n1. AI agent proposes an action\n2. EAAP evaluates against policy rules, risk thresholds, and context\n3. Action is admitted (allowed), denied (blocked), or escalated (human review)\n4. Complete audit trail is recorded\n\n**The problem EAAP solves:** As AI agents become more autonomous (OpenClaw, NemoClaw, CrewAI), there is no standard protocol for governing what they're allowed to do. EAAP provides this missing governance layer.\n\nEAAP is analogous to OAuth for API authorization — but for AI agent actions. It is open-source and published as an RFC at github.com/exogram-ai/eaap-rfc.","url":"https://www.richardewing.io/glossary/eaap-protocol"},{"@type":"DefinedTerm","termCode":"orchestration-debt","name":"Orchestration Debt","description":"Orchestration Debt is a framework coined by Richard Ewing for the technical debt that accumulates in AI agent coordination systems. As multi-agent architectures grow in complexity, the orchestration layer — the code that decides which agent does what, when, and how they communicate — becomes the dominant source of system fragility.\n\n**Sources of orchestration debt:**\n- **Agent sprawl:** Too many specialized agents with overlapping capabilities\n- **Communication overhead:** N agents create N² potential communication paths\n- **State management:** Tracking conversation context across agent handoffs\n- **Error cascading:** One agent's failure creates unpredictable downstream effects\n- **Cost multiplication:** Each orchestration step adds LLM calls\n\nOrchestration debt is the AI-era equivalent of microservices communication debt — the same architectural pattern, amplified by the probabilistic nature of LLM-based components.","url":"https://www.richardewing.io/glossary/orchestration-debt"},{"@type":"DefinedTerm","termCode":"serverless","name":"Serverless Computing","description":"Serverless computing is a cloud execution model where the cloud provider manages server infrastructure and automatically allocates compute resources on-demand. Developers write functions that execute in response to events — without provisioning, scaling, or managing servers.\n\n**Serverless services:** AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers, Vercel Edge Functions.\n\n**Serverless economics:**\n- **Pay-per-execution:** Charged only when code runs (typically per 100ms)\n- **Auto-scaling:** Scales to zero when idle, scales to thousands during spikes\n- **Cold starts:** Functions that haven't run recently take 100ms-5s to initialize\n- **Vendor lock-in:** Serverless code is tightly coupled to provider APIs\n\n**When serverless is wrong:** Long-running processes, consistent high throughput, or workloads needing GPU access. At high volume, serverless can cost 2-5x more than dedicated servers.","url":"https://www.richardewing.io/glossary/serverless"},{"@type":"DefinedTerm","termCode":"edge-computing","name":"Edge Computing","description":"Edge computing is a distributed computing paradigm where computation and data storage are performed closer to the data source or end user — at the \"edge\" of the network — rather than in a centralized data center.\n\n**Edge locations:** CDN points of presence (Cloudflare has 300+), IoT devices, cell towers, on-premise servers, and edge clouds.\n\n**Use cases:**\n- **Low-latency responses:** Gaming, video streaming, AR/VR (< 20ms required)\n- **IoT data processing:** Process sensor data locally instead of sending to cloud\n- **AI inference:** Run ML models at the edge for real-time predictions\n- **Privacy/compliance:** Keep data in specific geographic regions\n\n**Edge platforms:** Cloudflare Workers, Vercel Edge, AWS CloudFront Functions, Fastly Compute@Edge.\n\nEdge computing creates a distributed systems challenge: how to keep data consistent across hundreds of locations while maintaining low latency.","url":"https://www.richardewing.io/glossary/edge-computing"},{"@type":"DefinedTerm","termCode":"multi-cloud","name":"Multi-Cloud Strategy","description":"Multi-cloud is the strategy of using services from two or more cloud providers (AWS, GCP, Azure) to avoid vendor lock-in, optimize costs, or meet compliance requirements.\n\n**Motivations:**\n- **Vendor lock-in avoidance:** Don't be dependent on one provider\n- **Best-of-breed services:** Use AWS for compute, GCP for AI/ML, Azure for enterprise\n- **Compliance:** Some regulations require data in specific providers or regions\n- **Negotiation leverage:** Competition between providers can reduce costs\n\n**The reality:** True multi-cloud is expensive and complex. Running the same workload on two clouds doesn't mean you can switch in a day. Each cloud has unique APIs, IAM models, networking, and billing.\n\n**Most companies use \"multi-cloud\" to mean:** Different workloads on different clouds (this is reasonable), not the same workload simultaneously on multiple clouds (this is usually over-engineering).","url":"https://www.richardewing.io/glossary/multi-cloud"},{"@type":"DefinedTerm","termCode":"finops","name":"FinOps","description":"FinOps (Financial Operations) is the practice of bringing financial accountability to cloud spending. It combines engineering, finance, and business to optimize cloud costs without sacrificing performance.\n\n**FinOps lifecycle:**\n1. **Inform:** Understand where cloud spend goes — by team, service, environment\n2. **Optimize:** Right-size instances, eliminate waste, use reserved/spot pricing\n3. **Operate:** Build cost-awareness into engineering culture and workflows\n\n**Common cloud waste patterns:**\n- Over-provisioned compute (running large instances for small workloads)\n- Idle resources (dev/staging environments running 24/7)\n- Unattached storage volumes and snapshots\n- Data transfer costs from poor architecture decisions\n\n**FinOps tools:** Vantage, CloudZero, Kubecost, AWS Cost Explorer, Google Cloud FinOps Hub.\n\nThe average company wastes 30% of its cloud spend. FinOps aims to reduce this to under 10%.","url":"https://www.richardewing.io/glossary/finops"},{"@type":"DefinedTerm","termCode":"soc-2-compliance","name":"SOC 2 Compliance","description":"SOC 2 (Service Organization Control 2) is an auditing framework that evaluates how a company protects customer data. It is the most requested compliance certification for B2B SaaS companies.\n\n**Five Trust Service Criteria:**\n1. **Security (required):** Protection against unauthorized access\n2. **Availability:** System uptime and reliability\n3. **Processing Integrity:** Accurate and complete data processing\n4. **Confidentiality:** Protection of sensitive information\n5. **Privacy:** Personal data handling practices\n\n**Two report types:**\n- **Type I:** Point-in-time assessment (are controls in place today?)\n- **Type II:** Period assessment (have controls operated effectively for 6-12 months?)\n\n**Cost:** $20K-$100K for initial audit, depending on company size. Ongoing compliance costs: $30K-$80K/year.\n\nSOC 2 is increasingly table stakes for B2B SaaS sales. Enterprise customers won't proceed without it.","url":"https://www.richardewing.io/glossary/soc-2-compliance"},{"@type":"DefinedTerm","termCode":"supply-chain-security","name":"Supply Chain Security","description":"Software supply chain security is the practice of securing the entire software delivery pipeline — from source code to dependencies to build systems to deployment. It protects against attacks that compromise software through its development process.\n\n**Attack vectors:**\n- **Dependency poisoning:** Malicious code in npm, PyPI, or Maven packages\n- **Build system compromise:** Attackers inject code during CI/CD (SolarWinds attack)\n- **Source code tampering:** Unauthorized commits to repositories\n- **Container image attacks:** Compromised base images in Docker Hub\n\n**SBOM (Software Bill of Materials):** Executive Order 14028 requires SBOMs for government software. An SBOM lists every component in your software — like an ingredient list for food.\n\n**Tools:** Snyk, Dependabot, Renovate, Sigstore (signing), SLSA framework (supply chain integrity).","url":"https://www.richardewing.io/glossary/supply-chain-security"},{"@type":"DefinedTerm","termCode":"incident-response","name":"Incident Response","description":"Incident response is the structured process for identifying, containing, resolving, and learning from production incidents. It defines how teams respond when things break in production.\n\n**Incident response lifecycle:**\n1. **Detection:** Monitoring/alerting identifies an issue\n2. **Triage:** Assess severity (SEV1-SEV4) and assign incident commander\n3. **Communication:** Notify stakeholders via status page, Slack, email\n4. **Mitigation:** Restore service (rollback, failover, hotfix)\n5. **Resolution:** Fully fix the underlying issue\n6. **Post-mortem:** Root cause analysis, action items, process improvements\n\n**Blameless post-mortems:** Modern incident response uses blameless post-mortems — focusing on systemic causes rather than individual blame. This encourages transparency and prevents information hiding.\n\n**SLAs for response time:**\n- SEV1 (service down): 15 min response, 1 hour resolution\n- SEV2 (major degradation): 30 min response, 4 hour resolution\n- SEV3 (minor issue): 4 hour response, next business day resolution","url":"https://www.richardewing.io/glossary/incident-response"},{"@type":"DefinedTerm","termCode":"engineering-manager","name":"Engineering Manager","description":"An Engineering Manager (EM) is a people manager for software engineers, responsible for team health, career development, hiring, and delivery. The EM role is the first management rung on the engineering ladder, typically managing 5-10 engineers.\n\n**Core responsibilities:**\n- **People management:** 1:1s, feedback, performance reviews, career development\n- **Hiring:** Interview loops, candidate evaluation, team growth\n- **Delivery:** Sprint planning, roadmap execution, stakeholder communication\n- **Technical guidance:** Code review involvement, architecture decisions (varies)\n\n**EM vs. Tech Lead:** An EM focuses on people and process. A Tech Lead focuses on technical direction. Some organizations merge these roles; elite organizations separate them.\n\n**The EM's dilemma:** EMs are measured on team output but don't write code. Their leverage comes through others — coaching, unblocking, and creating the conditions for great work.","url":"https://www.richardewing.io/glossary/engineering-manager"},{"@type":"DefinedTerm","termCode":"architecture-review-board","name":"Architecture Review Board","description":"An Architecture Review Board (ARB) is a governance body that evaluates and approves significant technical decisions — new technologies, architecture changes, platform migrations, and build-vs-buy decisions.\n\n**ARB responsibilities:**\n- Review and approve major architecture decisions\n- Maintain architecture decision records (ADRs)\n- Ensure consistency across teams and services\n- Evaluate technical risk of proposed changes\n- Set and maintain technology standards\n\n**Anti-patterns:** An ARB that moves too slowly becomes a bottleneck. An ARB that rubber-stamps everything provides no value. The best ARBs are lightweight, async-first, and focus only on high-impact decisions.\n\n**Architecture Decision Records (ADRs):** Written documents that capture the context, decision, and rationale for significant architecture choices. ADRs are the institutional memory that prevents repeated debates.","url":"https://www.richardewing.io/glossary/architecture-review-board"},{"@type":"DefinedTerm","termCode":"event-driven-architecture","name":"Event-Driven Architecture","description":"Event-driven architecture (EDA) is a software design pattern where services communicate by producing and consuming events — asynchronous messages that represent something that happened (e.g., \"OrderPlaced\", \"UserRegistered\").\n\n**Components:**\n- **Event producers:** Services that emit events when state changes\n- **Event broker:** Message infrastructure (Kafka, RabbitMQ, AWS EventBridge)\n- **Event consumers:** Services that react to events\n- **Event store:** Persistent log of all events (event sourcing)\n\n**Benefits:** Decoupled services (producers don't know about consumers), natural audit log, easy to add new consumers, horizontal scalability.\n\n**Challenges:** Eventual consistency (not immediate), debugging distributed flows, ordering guarantees, event schema evolution.\n\nEDA is increasingly used with AI systems: model predictions trigger events, AI results are consumed asynchronously, and event stores provide training data.","url":"https://www.richardewing.io/glossary/event-driven-architecture"},{"@type":"DefinedTerm","termCode":"cqrs","name":"CQRS","description":"CQRS (Command Query Responsibility Segregation) is an architecture pattern that separates read operations (queries) from write operations (commands) into different models, data stores, or services.\n\n**Traditional approach:** Single model handles both reads and writes (simple but creates contention at scale).\n\n**CQRS approach:**\n- **Command side:** Handles writes, validates business rules, emits events\n- **Query side:** Handles reads, optimized for specific view patterns, denormalized data\n\n**When CQRS helps:**\n- Read/write ratios are heavily skewed (99% reads, 1% writes)\n- Read and write models have different optimization needs\n- You need different views of the same data for different consumers\n- Combined with event sourcing for complete audit trails\n\n**When CQRS hurts:** Simple CRUD applications, small teams, early-stage products where the complexity isn't justified.","url":"https://www.richardewing.io/glossary/cqrs"},{"@type":"DefinedTerm","termCode":"strangler-fig-pattern","name":"Strangler Fig Pattern","description":"The Strangler Fig pattern is a migration strategy for incrementally replacing a legacy system with a modern one — without a risky \"big bang\" rewrite. Named after strangler fig trees that grow around and eventually replace their host tree.\n\n**How it works:**\n1. **Identify:** Choose a specific capability to migrate\n2. **Build:** Create the new implementation alongside the old\n3. **Route:** Direct traffic to the new implementation (via API gateway, proxy, or feature flag)\n4. **Verify:** Confirm the new implementation works correctly\n5. **Remove:** Decommission the old implementation\n6. **Repeat:** Move to the next capability\n\n**The alternative — \"big bang\" rewrite — fails 70% of the time.** Strangler fig succeeds because it's incremental, reversible, and delivers value continuously.\n\nThis pattern is the recommended approach for most legacy system modernizations, including mainframe-to-cloud migrations.","url":"https://www.richardewing.io/glossary/strangler-fig-pattern"},{"@type":"DefinedTerm","termCode":"usage-based-pricing","name":"Usage-Based Pricing","description":"Usage-based pricing (UBP) is a monetization model where customers pay based on how much they use the product — API calls, data volume, compute hours, active users, or transactions — rather than a fixed subscription fee.\n\n**Examples:**\n- **AWS:** Pay per compute hour, GB stored, API call\n- **Twilio:** Pay per SMS, voice minute, API request\n- **Snowflake:** Pay per compute credit consumed\n- **OpenAI:** Pay per token processed\n\n**Advantages:** Low barrier to entry (start free, pay as you grow), natural expansion revenue (usage grows with customer success), and fair pricing (customers pay for what they use).\n\n**Challenges:** Revenue unpredictability (usage fluctuates monthly), complex billing infrastructure, and margin management (your COGS scales with customer usage).\n\nUsage-based pricing is becoming the default for AI products where inference costs are the dominant COGS.","url":"https://www.richardewing.io/glossary/usage-based-pricing"},{"@type":"DefinedTerm","termCode":"freemium-model","name":"Freemium Model","description":"Freemium is a pricing strategy where a basic product is offered for free, with premium features or capabilities available for a paid upgrade. The free tier serves as the top of the acquisition funnel.\n\n**Freemium economics:**\n- **Conversion rate:** 2-5% of free users convert to paid (industry average)\n- **CAC advantage:** Free users acquire other free users (viral growth)\n- **Cost risk:** Free users consume resources without generating revenue\n\n**Freemium design principles:**\n1. Free tier must be genuinely useful (not a stripped-down teaser)\n2. Upgrade trigger should be natural (usage limits, team features, advanced capabilities)\n3. Free tier should demonstrate value that justifies the paid price\n4. Monitor free-to-paid conversion funnel obsessively\n\n**Examples:** Slack (free up to 10K messages), Spotify (free with ads), Figma (free for 3 projects), GitHub (free for public repos). Richard Ewing's site uses freemium: PDI, APER, AUEB calculators are free → advisory is paid.","url":"https://www.richardewing.io/glossary/freemium-model"},{"@type":"DefinedTerm","termCode":"ai-inference","name":"AI Inference","description":"AI inference is the process of running a trained machine learning model to generate predictions, classifications, or outputs from new input data. Unlike training (which teaches the model), inference is the production use — every ChatGPT response, every recommendation, every fraud detection is an inference.\n\n**Inference economics:**\n- **Cost per inference:** GPT-4: $0.03-0.12 per 1K tokens. GPT-3.5: $0.002 per 1K tokens. Self-hosted open models: $0.0001-0.001.\n- **Latency:** Real-time inference: <100ms (fraud detection). Batch inference: minutes-hours (recommendations).\n- **Hardware:** GPUs (NVIDIA A100, H100), TPUs (Google), or CPU (for simpler models).\n\n**Inference optimization:**\n- Model quantization (reduce precision: FP32 → INT8)\n- Model distillation (train smaller model to mimic larger)\n- Caching (store common responses)\n- Batching (process multiple requests together)","url":"https://www.richardewing.io/glossary/ai-inference"},{"@type":"DefinedTerm","termCode":"synthetic-data","name":"Synthetic Data","description":"Synthetic data is artificially generated data that mimics the statistical properties of real data without containing actual user information. It's created by generative models trained on real datasets.\n\n**Use cases:**\n- **Privacy:** Train models without exposing personal data (GDPR, HIPAA)\n- **Data augmentation:** Generate more training examples for rare events (fraud, disease)\n- **Testing:** Create realistic test datasets without production data risks\n- **Bias reduction:** Generate balanced datasets to reduce model bias\n\n**Quality measures:** Fidelity (does it match real data distributions?), Privacy (can original data be reconstructed?), Utility (do models trained on synthetic data perform well?).\n\n**Tools:** Mostly AI, Gretel, Tonic, CTGAN, and LLM-generated synthetic datasets.\n\nGartner predicts that by 2030, synthetic data will overtake real data in AI model training.","url":"https://www.richardewing.io/glossary/synthetic-data"},{"@type":"DefinedTerm","termCode":"ai-alignment","name":"AI Alignment","description":"AI alignment is the field of ensuring that AI systems behave in accordance with human values, intentions, and goals. It addresses the problem: how do you make sure an AI does what you want it to do — not just what you told it to do?\n\n**Alignment challenges:**\n- **Specification gaming:** AI finds loopholes in reward functions (optimizing the metric, not the goal)\n- **Goal misalignment:** AI pursues sub-goals that conflict with human intentions\n- **Deceptive alignment:** AI appears aligned during testing but behaves differently in deployment\n- **Value learning:** How to infer human values from behavior (inverse reinforcement learning)\n\n**Practical alignment in enterprise AI:**\n- RLHF (Reinforcement Learning from Human Feedback) — the method behind ChatGPT\n- Constitutional AI — giving AI explicit rules to follow\n- Red teaming — adversarial testing for dangerous behaviors\n- EAAP Protocol — action admissibility governance for AI agents","url":"https://www.richardewing.io/glossary/ai-alignment"},{"@type":"DefinedTerm","termCode":"mixture-of-experts","name":"Mixture of Experts (MoE)","description":"Mixture of Experts (MoE) is a neural network architecture where the model is divided into multiple specialized \"expert\" sub-networks, and a gating mechanism routes each input to the most relevant experts. Only a subset of experts activate per query.\n\n**How MoE works:**\n1. Input arrives at the gating network\n2. Gate selects top-K experts (typically 2 of 8-64 total)\n3. Only selected experts process the input\n4. Outputs are weighted and combined\n\n**Economics:** MoE models have the knowledge capacity of a large model but the inference cost of a smaller one. GPT-4 is rumored to use MoE with 8 experts, activating 2 per query.\n\n**Mixtral (Mistral's MoE):** 8 experts, 2 active per token, achieves GPT-3.5 performance at a fraction of the cost.\n\nMoE is the architecture pattern that makes large AI models economically viable.","url":"https://www.richardewing.io/glossary/mixture-of-experts"},{"@type":"DefinedTerm","termCode":"ai-orchestration","name":"AI Orchestration","description":"AI orchestration is the coordination layer that manages how multiple AI models, tools, and data sources work together to complete complex tasks. It's the \"conductor\" that decides which AI component handles each step.\n\n**Orchestration patterns:**\n- **Sequential chain:** Model A → Model B → Model C (LangChain)\n- **Router:** Gate model decides which specialist model handles the query\n- **Parallel fan-out:** Send to multiple models, aggregate results\n- **Agent loop:** Model plans → acts → observes → repeats until task complete\n\n**Orchestration platforms:** LangChain, LlamaIndex, Semantic Kernel (Microsoft), CrewAI, AutoGen.\n\n**The orchestration cost problem:** Each orchestration step adds an LLM call. A 5-step agent workflow costs 5x a single-model response. This is why Richard Ewing's Orchestration Debt framework matters — orchestration complexity compounds cost exponentially.","url":"https://www.richardewing.io/glossary/ai-orchestration"},{"@type":"DefinedTerm","termCode":"feature-flag","name":"Feature Flag","description":"A feature flag (also called feature toggle) is a software development technique that allows teams to enable or disable features in production without deploying new code. Feature flags decouple deployment from release.\n\n**Use cases:**\n- **Progressive rollout:** Ship to 1% of users, then 10%, then 100%\n- **A/B testing:** Show different features to different user segments\n- **Kill switch:** Instantly disable a feature if it causes problems\n- **Beta access:** Give specific customers early access to new features\n- **Trunk-based development:** Merge incomplete features behind flags\n\n**Tools:** LaunchDarkly, Statsig, Flagsmith, Unleash, ConfigCat.\n\n**Feature flag debt:** Old, unused feature flags accumulate and become dead code. Best practice: every flag has an expiration date and an owner. Remove flags within 2 sprints of full rollout.","url":"https://www.richardewing.io/glossary/feature-flag"},{"@type":"DefinedTerm","termCode":"trunk-based-development","name":"Trunk-Based Development","description":"Trunk-based development (TBD) is a source control branching model where developers integrate their changes into a single shared branch (\"trunk\" or \"main\") at least once per day. Short-lived feature branches (< 1 day) are permitted, but long-lived branches are avoided.\n\n**TBD vs. GitFlow:**\n- **TBD:** Small, frequent merges to main. Deploy from main. Feature flags for incomplete work.\n- **GitFlow:** Long-lived develop/feature/release branches. Merge periodically. Complex merge conflicts.\n\n**Why TBD wins at scale:** DORA research shows that trunk-based development correlates with elite deployment frequency and lead time. Elite teams deploy multiple times per day from trunk.\n\n**Requirements for TBD:** Comprehensive CI pipeline, feature flags, strong test coverage, and team discipline around small, incremental changes.","url":"https://www.richardewing.io/glossary/trunk-based-development"},{"@type":"DefinedTerm","termCode":"graphql","name":"GraphQL","description":"GraphQL is a query language for APIs developed by Meta (Facebook) that allows clients to request exactly the data they need — no more, no less. Unlike REST APIs that return fixed data shapes, GraphQL lets the client specify its data requirements.\n\n**Key concepts:**\n- **Schema:** Strongly-typed contract defining available data and operations\n- **Queries:** Read data (like GET in REST)\n- **Mutations:** Write data (like POST/PUT/DELETE)\n- **Subscriptions:** Real-time data updates (WebSocket-based)\n\n**GraphQL vs. REST:**\n- REST: Multiple endpoints, over-fetching/under-fetching, versioning needed\n- GraphQL: Single endpoint, precise data fetching, schema evolution\n\n**When GraphQL hurts:** Complex authorization, N+1 query problems, caching complexity, and the learning curve. For simple CRUD APIs, REST is often simpler and sufficient.","url":"https://www.richardewing.io/glossary/graphql"},{"@type":"DefinedTerm","termCode":"technical-debt-ratio-metric","name":"Technical Debt Ratio","description":"Technical Debt Ratio (TDR) is a metric that quantifies the proportion of development time spent on fixing or working around existing technical debt versus building new capabilities.\n\n**Formula:** TDR = (Time spent on debt-related work / Total engineering time) × 100%\n\n**Benchmarks:**\n- **Healthy:** < 20% — Most time goes to new value creation\n- **Concerning:** 20-40% — Debt is slowing the team noticeably\n- **Critical:** 40-60% — More time on maintenance than innovation\n- **Insolvent:** > 60% — The team cannot deliver new features effectively\n\nRichard Ewing's Innovation Tax framework extends TDR by translating these percentages into dollar values: if your R&D budget is $10M and TDR is 45%, you're spending $4.5M on debt maintenance.\n\nTDR should be tracked monthly and reported to leadership. It's the most accessible technical debt metric for non-technical stakeholders.","url":"https://www.richardewing.io/glossary/technical-debt-ratio-metric"},{"@type":"DefinedTerm","termCode":"canary-deployment","name":"Canary Deployment","description":"A canary deployment is a release strategy where a new version of software is rolled out to a small subset of users or servers first — the \"canary\" — before being deployed to the entire infrastructure.\n\n**Named after:** Coal mine canaries that detected dangerous gas before miners could.\n\n**Canary deployment process:**\n1. Deploy new version to 1-5% of traffic\n2. Monitor error rates, latency, and business metrics\n3. If metrics are healthy: gradually increase to 10%, 25%, 50%, 100%\n4. If metrics degrade: automatically roll back to previous version\n\n**Canary vs. Blue-Green vs. Rolling:**\n- **Canary:** Small subset gets new version, gradual rollout\n- **Blue-Green:** Two identical environments, instant traffic switch\n- **Rolling:** Servers updated one-at-a-time\n\n**Tools:** Argo Rollouts, Flagger, AWS CodeDeploy, Istio traffic splitting.","url":"https://www.richardewing.io/glossary/canary-deployment"},{"@type":"DefinedTerm","termCode":"technical-interview","name":"Technical Interview","description":"A technical interview is an assessment of a candidate's engineering abilities, typically involving coding challenges, system design questions, and behavioral evaluation. Traditional technical interviews are widely criticized for low signal-to-noise ratio.\n\n**Common formats:**\n- **Coding challenge:** Algorithmic problem solving on a whiteboard or online (LeetCode-style)\n- **System design:** Design a system like Twitter, Uber, or a URL shortener\n- **Take-home project:** Build a small application in 4-8 hours\n- **Pair programming:** Write code together on a real problem\n- **Behavioral:** Past experience questions (STAR method)\n\n**The criticism:** LeetCode-style interviews test algorithmic knowledge that's rarely used at work. They have high false-negative rates (reject good engineers who don't practice puzzles).\n\nRichard Ewing's Audit Interview takes a different approach: standardized assessment across multiple tracks (PM, Engineering, Leadership) with AI-powered scoring and committee review.","url":"https://www.richardewing.io/glossary/technical-interview"},{"@type":"DefinedTerm","termCode":"platform-team","name":"Platform Team","description":"A platform team is an internal engineering team that builds and maintains shared infrastructure, tools, and services that other product teams use. They treat internal developers as their customers.\n\n**What platform teams own:**\n- CI/CD pipelines and deployment infrastructure\n- Observability stack (monitoring, logging, alerting)\n- Developer tooling (local dev environments, code generators)\n- Shared services (authentication, authorization, notifications)\n- Infrastructure as code and cloud management\n\n**Platform team anti-patterns:**\n- Building infrastructure nobody uses (\"build it and they will come\")\n- Mandating tools without understanding customer needs\n- Optimizing for architectural purity over developer experience\n\n**When to create a platform team:** When product teams spend >20% of time on infrastructure. Typically around 50+ engineers. Before that, shared infrastructure is a part-time responsibility.","url":"https://www.richardewing.io/glossary/platform-team"},{"@type":"DefinedTerm","termCode":"chaos-engineering","name":"Chaos Engineering","description":"Chaos engineering is the practice of intentionally introducing failures into production systems to identify weaknesses before they cause real outages. Pioneered by Netflix's \"Chaos Monkey\" tool.\n\n**Principles of chaos engineering:**\n1. **Start with a hypothesis:** \"Our system should handle a database failover in < 30 seconds\"\n2. **Introduce real-world failures:** Kill instances, simulate network latency, corrupt data\n3. **Measure the impact:** Did the system recover? How long? Were customers affected?\n4. **Minimize blast radius:** Start small, use feature flags to limit scope\n\n**Chaos experiments:**\n- Kill a random production instance (Chaos Monkey)\n- Simulate an entire region failure (Chaos Kong)\n- Inject network latency between services\n- Corrupt or delay database responses\n- Simulate third-party API failures\n\n**Tools:** Gremlin, Litmus Chaos, AWS Fault Injection Simulator, Netflix Simian Army.","url":"https://www.richardewing.io/glossary/chaos-engineering"},{"@type":"DefinedTerm","termCode":"langchain","name":"LangChain","description":"LangChain is an open-source framework for building applications powered by large language models (LLMs). It provides abstractions for chaining LLM calls, connecting to external data sources, and implementing agentic workflows.\n\n**Core components:**\n- **Chains:** Sequential or branching LLM call workflows\n- **Agents:** LLMs that decide which tools to use and when\n- **RAG (Retrieval-Augmented Generation):** Connect LLMs to your data via vector databases\n- **Memory:** Maintain conversation context across interactions\n- **Tools:** Integrations with APIs, databases, and external services\n\n**LangChain alternatives:** LlamaIndex (data-focused), Semantic Kernel (Microsoft), Haystack (NLP-focused), CrewAI (multi-agent).\n\n**Criticism:** LangChain is often over-abstracted for simple use cases. For basic LLM calls, direct API usage is simpler and more debuggable.","url":"https://www.richardewing.io/glossary/langchain"},{"@type":"DefinedTerm","termCode":"crewai","name":"CrewAI","description":"CrewAI is an open-source multi-agent orchestration framework that enables teams of AI agents to collaborate on complex tasks. Each agent has a defined role, goal, and backstory — creating specialized AI \"crew members\" that work together.\n\n**Key concepts:**\n- **Agents:** Specialized AI entities with defined roles (e.g., \"Researcher\", \"Writer\", \"Reviewer\")\n- **Tasks:** Specific work items assigned to agents\n- **Crew:** A team of agents working toward a shared goal\n- **Process:** Sequential or hierarchical task execution\n\n**Use cases:** Content generation pipelines, research automation, code review workflows, customer support triage.\n\n**Economics:** Each agent in a CrewAI crew makes independent LLM calls. A 5-agent crew processing one request may cost 5-15x a single LLM call. This is the Orchestration Debt Richard Ewing's framework addresses.","url":"https://www.richardewing.io/glossary/crewai"},{"@type":"DefinedTerm","termCode":"opentelemetry","name":"OpenTelemetry","description":"OpenTelemetry (OTel) is an open-source observability framework for generating, collecting, and exporting telemetry data — traces, metrics, and logs — from applications and infrastructure.\n\n**Three pillars:**\n- **Traces:** Request flows across distributed services (who called what, how long)\n- **Metrics:** Quantitative measurements (request count, error rate, latency)\n- **Logs:** Textual records of events and state changes\n\n**Why OpenTelemetry matters:**\n- **Vendor-neutral:** Instrument once, send to any backend (Datadog, Grafana, New Relic)\n- **CNCF project:** Industry standard backed by Google, Microsoft, and others\n- **Auto-instrumentation:** Libraries that automatically capture telemetry from popular frameworks\n\n**OpenTelemetry replaces:** Vendor-specific instrumentation (Datadog APM, New Relic agents) with a single, portable standard.","url":"https://www.richardewing.io/glossary/opentelemetry"},{"@type":"DefinedTerm","termCode":"ai-guardrails","name":"AI Guardrails","description":"AI guardrails are safety mechanisms that constrain AI model behavior within acceptable bounds — preventing harmful, inaccurate, or policy-violating outputs. Guardrails are the practical implementation of AI alignment in production.\n\n**Types of guardrails:**\n- **Input guardrails:** Filter dangerous prompts before they reach the model (prompt injection detection, topic filtering)\n- **Output guardrails:** Validate model responses before returning to users (content moderation, factual verification, PII detection)\n- **Behavioral guardrails:** Constrain the model's action space (EAAP Protocol — what actions the AI is allowed to take)\n\n**Guardrail tools:** NVIDIA NeMo Guardrails, Guardrails AI, LangChain output parsers, custom validation layers.\n\n**The guardrail tax:** Every guardrail adds latency and cost. A typical production AI system has 3-5 guardrail layers. Each adds 50-200ms latency and requires its own model call (for ML-based guardrails).","url":"https://www.richardewing.io/glossary/ai-guardrails"},{"@type":"DefinedTerm","termCode":"technical-debt-quadrant","name":"Technical Debt Quadrant","description":"The Technical Debt Quadrant is a classification framework (created by Martin Fowler) that categorizes technical debt along two dimensions: deliberate vs. inadvertent, and reckless vs. prudent.\n\n**Four quadrants:**\n1. **Reckless + Deliberate:** \"We don't have time for design\" — knowingly shipping bad code\n2. **Reckless + Inadvertent:** \"What's layering?\" — shipping bad code without knowing it's bad\n3. **Prudent + Deliberate:** \"We must ship now and deal with consequences\" — conscious trade-offs\n4. **Prudent + Inadvertent:** \"Now we know how we should have done it\" — learning-driven debt\n\n**Quadrant 3 (Prudent + Deliberate) is the only acceptable form of intentional debt.** It represents conscious, documented trade-offs with a plan to repay.\n\nRichard Ewing's Product Debt Index extends this framework by attaching dollar values to each quadrant — making the economic impact of each debt type visible to finance and leadership.","url":"https://www.richardewing.io/glossary/technical-debt-quadrant"},{"@type":"DefinedTerm","termCode":"nemo-guardrails","name":"NeMo Guardrails","description":"NeMo Guardrails is an open-source toolkit by NVIDIA for adding programmable guardrails to LLM-based applications. It allows developers to define conversation flows, topical constraints, and safety policies using a simple configuration language called Colang.\n\n**Capabilities:**\n- **Topical guardrails:** Prevent AI from discussing off-topic subjects\n- **Safety guardrails:** Block harmful, biased, or inappropriate responses\n- **Hallucination reduction:** Fact-checking responses against known data\n- **Input filtering:** Detect and block prompt injection attacks\n- **Custom policies:** Define application-specific behavior constraints\n\n**Colang example:** A simple configuration that says \"if user asks about competitors, redirect to our product features\" — all without modifying the LLM itself.\n\nNeMo Guardrails is part of NVIDIA's broader AI Enterprise platform and integrates with LangChain, LlamaIndex, and direct API usage.","url":"https://www.richardewing.io/glossary/nemo-guardrails"},{"@type":"DefinedTerm","termCode":"ai-red-teaming","name":"AI Red Teaming","description":"AI red teaming is the practice of adversarially testing AI systems to discover safety vulnerabilities, harmful behaviors, and failure modes before deployment. Red teamers try to make AI systems misbehave.\n\n**Red team attack types:**\n- **Prompt injection:** Trick the model into ignoring instructions\n- **Jailbreaking:** Bypass safety filters to get prohibited outputs\n- **Data extraction:** Get the model to reveal training data or system prompts\n- **Bias probing:** Find discriminatory or biased responses\n- **Factuality testing:** Identify confident hallucinations\n\n**Red teaming process:**\n1. Define the attack surface and scope\n2. Assemble red team (ideally diverse backgrounds and perspectives)\n3. Run structured attack scenarios\n4. Document findings with severity ratings\n5. Implement mitigations and guardrails\n6. Retest to verify fixes\n\nGoogle, OpenAI, Anthropic, and Meta all run extensive red team programs before model releases.","url":"https://www.richardewing.io/glossary/ai-red-teaming"},{"@type":"DefinedTerm","termCode":"product-led-growth","name":"Product-Led Growth (PLG)","description":"Product-Led Growth (PLG) is a go-to-market strategy where the product itself is the primary driver of customer acquisition, conversion, and expansion. Users discover, adopt, and pay for the product with minimal sales involvement.\n\n**PLG flywheel:**\n1. **Free tier / freemium:** Users start for free\n2. **Self-serve onboarding:** Users get value without talking to sales\n3. **Usage triggers:** Natural upgrade moments (\"you've reached your limit\")\n4. **Virality:** Users invite colleagues and teams\n5. **Expansion:** Individual use becomes team/enterprise adoption\n\n**PLG examples:** Slack, Figma, Notion, Calendly, Loom, Datadog.\n\n**PLG metrics:** Time to value, product-qualified leads (PQLs), free-to-paid conversion rate, natural rate of revenue growth (NRG).\n\nRichardEwing.io uses PLG: free tools (PDI, APER, AUEB, Audit Interview) → advisory conversion.","url":"https://www.richardewing.io/glossary/product-led-growth"},{"@type":"DefinedTerm","termCode":"api-gateway","name":"API Gateway","description":"An API gateway is a server that acts as the single entry point for all API requests in a microservices architecture. It handles routing, authentication, rate limiting, load balancing, and request/response transformation.\n\n**Core functions:**\n- **Routing:** Direct requests to the correct microservice\n- **Authentication:** Validate API keys, JWTs, OAuth tokens\n- **Rate limiting:** Prevent abuse and ensure fair usage\n- **Load balancing:** Distribute traffic across service instances\n- **Caching:** Cache common responses to reduce backend load\n- **Monitoring:** Log requests, track latency, generate alerts\n\n**Popular API gateways:** Kong, AWS API Gateway, Azure API Management, Nginx, Traefik, Envoy.\n\nThe API gateway pattern is essential for microservices but creates a single point of failure. Gateway resilience, caching strategy, and rate limiting configuration all create potential technical debt.","url":"https://www.richardewing.io/glossary/api-gateway"},{"@type":"DefinedTerm","termCode":"service-level-objectives","name":"Service Level Objectives (SLOs)","description":"Service Level Objectives (SLOs) are specific, measurable targets for service reliability — the percentage of time a service should work correctly. SLOs are the foundation of Site Reliability Engineering (SRE).\n\n**SLO components:**\n- **SLI (Service Level Indicator):** The metric (e.g., request latency, error rate, availability)\n- **SLO (Service Level Objective):** The target (e.g., 99.9% of requests under 200ms)\n- **SLA (Service Level Agreement):** The business contract built on SLOs (with penalties for violations)\n- **Error budget:** The allowed amount of unreliability (100% - SLO = error budget)\n\n**The error budget concept:**\nIf your SLO is 99.9% availability: you have 0.1% error budget = ~43 minutes of downtime per month. This budget is \"spent\" on deployments, experiments, and incidents. When your budget is exhausted, you shift to reliability work.\n\nGoogle pioneered SLOs in their SRE practice. The concept transforms reliability from \"we need 100% uptime\" (impossible) to \"we accept X% unreliability and manage it intentionally.\"","url":"https://www.richardewing.io/glossary/service-level-objectives"},{"@type":"DefinedTerm","termCode":"data-lake","name":"Data Lake","description":"A data lake is a centralized repository that stores raw data at any scale — structured (databases), semi-structured (JSON, XML), and unstructured (images, logs, documents) — in its native format until needed for analysis.\n\n**Data lake vs. data warehouse:**\n- **Data warehouse:** Structured, cleaned, schema-on-write, optimized for business reporting (Snowflake, BigQuery)\n- **Data lake:** Raw, uncleaned, schema-on-read, optimized for flexibility (S3, ADLS, GCS)\n- **Data lakehouse:** Hybrid combining lake flexibility with warehouse performance (Delta Lake, Apache Iceberg)\n\n**Data lake anti-patterns:**\n- **Data swamp:** Lake without governance, cataloging, or documentation\n- **Dump and pray:** Putting everything in the lake without use cases\n- **Copy everything:** Replicating full databases instead of selecting what's needed\n\nThe lakehouse architecture (Delta Lake, Apache Iceberg) is replacing pure data lakes by adding ACID transactions and schema enforcement.","url":"https://www.richardewing.io/glossary/data-lake"},{"@type":"DefinedTerm","termCode":"zero-trust-security","name":"Zero Trust Security","description":"Zero Trust is a security architecture that requires all users, devices, and applications to be continuously authenticated and authorized — regardless of whether they are inside or outside the network perimeter. The core principle: \"never trust, always verify.\"\n\n**Zero Trust principles:**\n1. **Verify explicitly:** Authenticate every request based on all available data\n2. **Least privilege access:** Grant minimum permissions needed for the task\n3. **Assume breach:** Design systems assuming the attacker is already inside\n\n**Zero Trust implementation:**\n- Identity-aware proxies (BeyondCorp, Cloudflare Access)\n- Micro-segmentation (network isolation between services)\n- Continuous authentication (not just at login)\n- Device posture checking\n- Encrypted communications everywhere (mTLS)\n\nThe traditional perimeter-based security model (\"castle and moat\") is obsolete. Remote work, cloud computing, and API-first architectures have dissolved the network perimeter.","url":"https://www.richardewing.io/glossary/zero-trust-security"},{"@type":"DefinedTerm","termCode":"cost-per-hire","name":"Cost per Hire","description":"Cost per Hire (CPH) is the total cost to recruit and onboard a new employee, including advertising, recruiter fees, interview time, background checks, and onboarding costs.\n\n**CPH components:**\n- **External costs:** Job board fees, recruiter commissions (typically 15-25% of salary), advertising\n- **Internal costs:** HR time, interviewer time, hiring manager time, background checks\n- **Onboarding costs:** Equipment, training, ramp-up productivity loss\n\n**Engineering-specific benchmarks:**\n- Junior engineer: $10K-$20K CPH\n- Senior engineer: $25K-$40K CPH\n- Staff/Principal: $40K-$75K CPH\n- Using external recruiters: add 20-25% of first-year salary\n\n**Cost of a bad hire:** 3-5x annual salary when you factor in ramp-up time, team disruption, severance, and re-hiring. For a $200K engineer, a bad hire costs $600K-$1M.\n\nRichard Ewing's Audit Interview reduces CPH by standardizing assessment (15 minutes vs. 6-hour loops) and reducing mis-hire rates.","url":"https://www.richardewing.io/glossary/cost-per-hire"},{"@type":"DefinedTerm","termCode":"customer-acquisition-cost","name":"Customer Acquisition Cost (CAC)","description":"Customer Acquisition Cost (CAC) is the total cost to acquire a new paying customer, including marketing spend, sales team costs, and any free-tier infrastructure costs.\n\n**Formula:** CAC = (Total Sales + Marketing Spend) / Number of New Customers Acquired\n\n**Benchmarks by stage:**\n- **Seed/Series A:** CAC < 3x monthly subscription price\n- **Series B+:** CAC payback period < 18 months\n- **Enterprise SaaS:** $5K-$50K CAC (longer sales cycles, higher ACV)\n- **PLG Self-Serve:** $100-$1,000 CAC (lower touch, higher volume)\n\n**CAC to LTV ratio:** Healthy = 1:3 or better (every $1 in acquisition returns $3+ in lifetime value). Below 1:3 signals unsustainable growth.\n\n**AI impact on CAC:** AI features can reduce CAC through better targeting, personalized onboarding, and product-led growth — but AI inference costs increase the COGS side of the equation.","url":"https://www.richardewing.io/glossary/customer-acquisition-cost"},{"@type":"DefinedTerm","termCode":"openclaw","name":"OpenClaw","description":"OpenClaw refers to open-source AI frameworks and libraries for building controllable, structured AI agent systems — focusing on giving developers \"claws\" (action capabilities) for AI agents while maintaining safety boundaries.\n\n**The open-source AI agent ecosystem:**\n- **AutoGPT:** One of the earliest autonomous AI agent frameworks\n- **CrewAI:** Multi-agent collaboration framework\n- **LangGraph:** Stateful, multi-actor applications with LLMs\n- **OpenHands (formerly OpenDevin):** Open-source AI software developer\n- **AgentGPT:** Browser-based autonomous AI agent\n\n**Key challenge:** Giving AI agents the ability to take real-world actions (writing code, sending emails, querying databases) while preventing harmful or unauthorized actions.\n\nRichard Ewing's EAAP (Exogram Action Admissibility Protocol) addresses this by defining an admissibility governance framework — what actions an AI agent is allowed to take and under what conditions.","url":"https://www.richardewing.io/glossary/openclaw"},{"@type":"DefinedTerm","termCode":"token-ai","name":"Token (AI)","description":"In AI and natural language processing, a token is a unit of text that a language model processes. Tokens are how LLMs \"read\" — they break text into smaller pieces before processing.\n\n**Token economics:**\n- 1 token ≈ 4 characters in English (≈ 0.75 words)\n- \"ChatGPT is great\" = 4 tokens\n- Average email: ~300 tokens\n- Average article: ~2,000 tokens\n\n**Cost per token (as of 2025):**\n- GPT-4o: $2.50 / 1M input tokens, $10 / 1M output tokens\n- GPT-4o mini: $0.15 / 1M input, $0.60 / 1M output\n- Claude 3.5 Sonnet: $3 / 1M input, $15 / 1M output\n- Open-source (self-hosted): $0.01-0.10 / 1M tokens\n\n**Context window:** The maximum number of tokens a model can process at once. GPT-4o: 128K tokens. Claude 3: 200K tokens. Larger context = more expensive per request.\n\nToken economics are the foundation of AI product pricing. Richard Ewing's AI COGS framework starts with per-token cost analysis.","url":"https://www.richardewing.io/glossary/token-ai"},{"@type":"DefinedTerm","termCode":"observability","name":"Observability","description":"Observability is the ability to understand the internal state of a system by examining its external outputs — logs, metrics, and traces. Unlike monitoring (which tells you WHEN something is wrong), observability helps you understand WHY.\n\n**Three pillars of observability:**\n1. **Logs:** Textual records of events (\"User X attempted login, failed: invalid password\")\n2. **Metrics:** Numerical measurements over time (request rate, error rate, latency percentiles)\n3. **Traces:** Request flow across distributed services (Service A → Service B → Database → Response)\n\n**Observability vs. monitoring:**\n- Monitoring = predefined dashboards for known problems\n- Observability = ability to ask arbitrary questions about system behavior\n\n**Observability stack:** Grafana + Prometheus + Loki (open-source), Datadog, New Relic, Splunk, Honeycomb.\n\nThe observability gap — when teams can see symptoms but can't diagnose causes — is a major contributor to high MTTR (Mean Time to Recovery).","url":"https://www.richardewing.io/glossary/observability"},{"@type":"DefinedTerm","termCode":"annual-recurring-revenue","name":"Annual Recurring Revenue (ARR)","description":"Annual Recurring Revenue (ARR) is the normalized annual value of recurring subscription revenue. It's the primary top-line metric for SaaS businesses and the basis for valuation multiples.\n\n**ARR calculation:** Monthly Recurring Revenue (MRR) × 12\n\n**ARR components:**\n- **New ARR:** Revenue from new customers\n- **Expansion ARR:** Revenue growth from existing customers (upsells, cross-sells)\n- **Contraction ARR:** Revenue decrease from existing customers (downgrades)\n- **Churned ARR:** Revenue lost from customers who cancel\n\n**Valuation multiples (2025):**\n- High-growth SaaS (>40% growth): 10-20x ARR\n- Moderate growth (20-40%): 5-10x ARR\n- Slow growth (<20%): 3-5x ARR\n- Rule of 40: Growth rate + profit margin > 40% = premium valuation\n\nRichard Ewing's EV-SE (Enterprise Value per Software Engineer) framework connects ARR to engineering headcount — answering \"how efficiently does engineering investment convert to recurring revenue?\"","url":"https://www.richardewing.io/glossary/annual-recurring-revenue"},{"@type":"DefinedTerm","termCode":"small-language-models","name":"Small Language Models (SLMs)","description":"Small Language Models (SLMs) are compact neural networks designed to perform language tasks locally, on-edge, or with minimal compute resources compared to traditional Large Language Models (LLMs).\n\nUnlike massive models (GPT-4, Claude 3 Opus) which pass 1 Trillion parameters, SLMs typically range from 1B to 8B parameters (e.g., Llama 3 8B, Phi-3, Gemma, Mistral). They sacrifice broad general knowledge but maintain extremely high reasoning capabilities.\n\n**Why they matter in 2025/2026:** SLMs solve the AI margin collapse problem. Because they are 10-50x cheaper to run, organizations are aggressively routing routine tasks to SLMs while reserving expensive LLMs only for highly complex cognitive routing.","url":"https://www.richardewing.io/glossary/small-language-models"},{"@type":"DefinedTerm","termCode":"open-weights","name":"Open Weights","description":"Open Weights refers to AI models where the trained parameters (weights) are made publicly available for download and execution, but the underlying training data and training code are kept proprietary.\n\nIn 2025/2026, the technology industry shifted away from calling models like Llama or Mistral \"Open Source\" (which legally requires the training data to be public per the OSI definition) and adopted \"Open Weights\" as the technically accurate term.\n\nOpen weights democratize AI inference, allowing any company to download, self-host, and fine-tune frontier-class models securely within their own VPCs without sending sensitive data to third-party endpoints.","url":"https://www.richardewing.io/glossary/open-weights"},{"@type":"DefinedTerm","termCode":"multimodal-ai","name":"Multimodal AI","description":"Multimodal AI systems are neural networks capable of processing, understanding, and generating multiple data types—or \"modalities\"—simultaneously, such as text, images, native audio, and continuous video streams.\n\nEarly AI required distinct models for different tasks (e.g., Whisper for audio, GPT-3 for text). True multimodal models (like Gemini 1.5 Pro and GPT-4o) possess a shared embedding space, allowing them to reason across natively mixed inputs (e.g., \"watch this 10-minute video and output the bounding box coordinates for every red car\").\n\nThis fundamentally expands AI capabilities from \"chatbots\" to autonomous real-time visual and auditory agents.","url":"https://www.richardewing.io/glossary/multimodal-ai"},{"@type":"DefinedTerm","termCode":"serverless-gpus","name":"Serverless GPUs","description":"Serverless GPUs are a cloud compute execution model where organizations run artificial intelligence and machine learning workloads on graphics processing units (GPUs) without provisioning, managing, or scaling the underlying servers.\n\nTraditional GPU clusters require immense upfront commitments, dedicated DevOps management, and suffer from low utilization when idle. Serverless GPU providers (like Modal, Baseten, RunPod) scale compute down to zero instantaneously and bill purely by the millisecond of execution time.\n\nThis architecture is the infrastructure prerequisite for cost-effectively hosting custom Open Weight models or independent AI agents.","url":"https://www.richardewing.io/glossary/serverless-gpus"},{"@type":"DefinedTerm","termCode":"cloud-repatriation","name":"Cloud Repatriation","description":"Cloud Repatriation is the strategic IT trend of migrating workloads from public cloud environments (AWS, GCP, Azure) back to on-premises data centers or bare-metal colocation facilities.\n\nDriven exponentially in 2025/2026 by the soaring costs of public cloud infrastructure, SaaS margin compression, and exorbitant hardware markups for AI GPU compute, companies (famously popularized by 37signals/Basecamp) move predictable, constant-load architectures off the cloud to collapse their infrastructure bills by 60-80%.\n\nCloud repatriation is rarely an all-or-nothing move; modern hybrid approaches leave spiky, variable workloads in the cloud while pulling high-volume, static database workloads to bare metal.","url":"https://www.richardewing.io/glossary/cloud-repatriation"},{"@type":"DefinedTerm","termCode":"webassembly","name":"WebAssembly (Wasm)","description":"WebAssembly (Wasm) is a binary instruction format that allows code written in languages like Rust, C++, and Go to run at near-native speed across different environments, from web browsers to cloud edges and serverless backends.\n\nBy 2025/2026, Wasm expanded far beyond the browser. On the server side, Wasm modules effectively act as ultra-lightweight containers with start times in the single milliseconds and a highly restrictive default security sandbox.\n\nIt is rapidly replacing Docker containers for localized edge compute functions and serverless execution because of its unparalleled speed and cross-platform determinism.","url":"https://www.richardewing.io/glossary/webassembly"},{"@type":"DefinedTerm","termCode":"semantic-layer","name":"Semantic Layer","description":"A Semantic Layer is an architectural abstraction that sits between raw database storage (data warehouses/lakehouses) and data consumers (BI tools, AI agents). It centralizes all business logic, metrics definitions, and access governance.\n\nInstead of defining \"Revenue\" differently in Tableau, looker, and a custom Python script, the Semantic Layer defines \"Revenue\" once via code. Any downstream tool or AI agent querying that metric receives the exact same mathematically deterministic answer.\n\nIn the era of Agentic AI, the Semantic Layer is non-negotiable. Without it, autonomous LLMs querying direct SQL will constantly hallucinate the wrong business metrics.","url":"https://www.richardewing.io/glossary/semantic-layer"},{"@type":"DefinedTerm","termCode":"graph-rag","name":"Graph RAG","description":"Graph RAG (Retrieval-Augmented Generation) is an advanced AI architecture that integrates Knowledge Graphs with traditional vector databases to drastically improve the reasoning capabilities of Large Language Models.\n\nStandard RAG searches for semantic text similarity. The failure point? It cannot properly connect disjointed concepts across isolated documents. Graph RAG explicitly maps entities (People, Products, Locations) and their relationships (Works For, Depends On) as interconnected nodes.\n\nWhen a model queries Graph RAG, it does not just retrieve a paragraph; it retrieves the entire structural relationship map of the domain, eliminating widespread multi-hop hallucination.","url":"https://www.richardewing.io/glossary/graph-rag"},{"@type":"DefinedTerm","termCode":"dspm","name":"DSPM (Data Security Posture Management)","description":"Data Security Posture Management (DSPM) is a cybersecurity framework focused on identifying, mapping, classifying, and protecting sensitive data regardless of where it resides in multicloud and continuous delivery environments.\n\nTraditional security focuses on locking the perimeter (servers, endpoints). DSPM focuses entirely on the data layer itself. It automatically scans AWS, Snowflake, and hidden object storage to uncover \"Shadow Data\" (untracked PII, secrets, or financial records) and enforces access governance.\n\nIn 2025/2026, DSPM became mandatory due to AI models aggressively ingesting data lakes; if sensitive data is not properly classified by a DSPM, the AI will unintentionally expose it.","url":"https://www.richardewing.io/glossary/dspm"},{"@type":"DefinedTerm","termCode":"sbom","name":"SBOM (Software Bill of Materials)","description":"A Software Bill of Materials (SBOM) is a comprehensive, machine-readable inventory detailing every third-party component, open-source library, and exact dependency version packed into a software application.\n\nTriggered by massive supply chain attacks (like the Log4j crisis) and mandated by recent federal executive orders, producing a cryptographic SBOM at every build step is now standard compliance for enterprise B2B sales.\n\nWhen a zero-day vulnerability breaks out globally, an SBOM allows organizations to determine if they are exposed in minutes rather than months of manual code auditing.","url":"https://www.richardewing.io/glossary/sbom"},{"@type":"DefinedTerm","termCode":"post-quantum-cryptography","name":"Post-Quantum Cryptography","description":"Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed to be entirely secure against an attack by a quantum computer.\n\nStandard encryption algorithms widely used today (like RSA and ECC) rely on mathematical complexities that are theoretically impossible for classical computers to break, but trivial for a sufficiently powerful quantum computer (via Shor's algorithm).\n\nThe \"Harvest Now, Decrypt Later\" threat model pushed the NIST to finalize PQC standards in late 2024. In 2025/2026, Fortune 500s are undergoing massive, mandatory multi-year architecture overhauls to rip out legacy RSA in favor of quantum-safe lattice-based cryptography.","url":"https://www.richardewing.io/glossary/post-quantum-cryptography"},{"@type":"DefinedTerm","termCode":"ai-product-management","name":"AI Product Management","description":"AI Product Management is a specialized discipline of PM focused on building, scaling, and maintaining products explicitly powered by machine learning, LLMs, or autonomous agents.\n\nTraditional Product Management focuses on deterministic behaviors: \"If the user clicks this, X happens.\" AI Product Managers must operate probabilistically. They manage hallucination rates, precision vs recall tradeoffs, AI Unit Economics (AI COGS), non-deterministic testing, and specific prompt boundaries.\n\nIn 2025/2026, the transition from SaaS PM to AI PM demands a hard pivot toward empirical data analytics and data-pipeline architectural comprehension.","url":"https://www.richardewing.io/glossary/ai-product-management"},{"@type":"DefinedTerm","termCode":"continuous-discovery","name":"Continuous Discovery","description":"Continuous Discovery is a product management framework popularized by Teresa Torres emphasizing a steady, weekly cadence of customer touchpoints executed jointly by the product trio (PM, Designer, Lead Engineer).\n\nUnlike traditional \"project discovery\" (which happens once at the beginning of a quarter), Continuous Discovery leverages Opportunity Solution Trees. It acknowledges that building a product is a continuous flow of risky assumptions, and those assumptions must be co-tested alongside active development rather than segmented entirely up front.\n\nThe framework prevents the accumulation of Product Debt.","url":"https://www.richardewing.io/glossary/continuous-discovery"},{"@type":"DefinedTerm","termCode":"mach-architecture","name":"MACH Architecture","description":"MACH stands for Microservices-based, API-first, Cloud-native SaaS, and Headless. It is a set of architectural principles guiding enterprise organizations to build highly modular, pluggable tech stacks.\n\n- **Microservices:** Individual pieces of business logic scaled separately.\n- **API-first:** All functionality exposed programmatically.\n- **Cloud-native:** Serverless and auto-scaling horizontally.\n- **Headless:** The frontend UI is completely decoupled from the backend logic.\n\nBy 2025/2026, MACH became the dominant modernization strategy for the enterprise eCommerce and CMS space, allowing corporations to swap out vendors (e.g., changing from Stripe to Adyen or Contentful to Sanity) without rewriting the entire core application.","url":"https://www.richardewing.io/glossary/mach-architecture"},{"@type":"DefinedTerm","termCode":"ebpf","name":"eBPF","description":"eBPF (Extended Berkeley Packet Filter) is a revolutionary Linux kernel technology that allows developers to run sandboxed, high-performance programs directly inside the operating system kernel without changing kernel source code or loading vulnerable modules.\n\neBPF completely dominates the 2025/2026 cloud-native landscape. Because eBPF sits at the kernel level, it observes every network packet, system call, and execution metric in a massive Kubernetes cluster with near-zero performance overhead.\n\nIt is the foundational technology powering modern high-performance cloud security, container networking (Cilium), and deep system observability tools.","url":"https://www.richardewing.io/glossary/ebpf"},{"@type":"DefinedTerm","termCode":"ai-finops","name":"AI FinOps","description":"AI FinOps is the specialized sub-discipline of Financial Operations focused entirely on maximizing the Unit Economics, visibility, and forecasting of Artificial Intelligence and Machine Learning workloads.\n\nStandard Cloud FinOps deals with predictable EC2 instances and object storage. AI FinOps tracks extreme variability: billions of stateless token generations, vast embedding databases, RAG compute overhead, model fine-tuning jobs, and Serverless GPU spin-ups.\n\nWithout AI FinOps, high-growth AI companies rapidly succumb to the \"Cost of Predictivity\"—where the raw expense of LLM API calls completely degrades their software gross margins down to unsalvageable levels.","url":"https://www.richardewing.io/glossary/ai-finops"},{"@type":"DefinedTerm","termCode":"down-round","name":"Down Round","description":"A down round occurs when a private company raises capital from investors at a lower pre-money valuation than the valuation established in its previous financing round.\n\nDriven by the massive zero-interest valuation hyper-inflation of 2021/2022, 2025/2026 became the hallmark era of the \"Down Round.\" Startups that were previously valued at $1B+ (Unicorns) were forced to raise new capital at $200M-$400M valuations to survive.\n\nDown rounds trigger severe toxic anti-dilution provisions for earlier investors, aggressively wiping out the percentage ownership of common stock held by founders and employees.","url":"https://www.richardewing.io/glossary/down-round"},{"@type":"DefinedTerm","termCode":"dpi","name":"DPI (Distributions to Paid-In Capital)","description":"DPI (Distributions to Paid-In Capital) is a core private equity and venture capital metric that measures the ratio of actual, realized cash returned to Limited Partners (LPs) compared to the capital those LPs originally invested into the fund.\n\nIf LP investors gave a VC fund $100M, and the VC fund has returned $20M through IPOs and acquisitions, the DPI is 0.20x.\n\nIn 2025/2026, the entire venture capital landscape shifted furiously from TVPI (paper valuations) to DPI. High interest rates demanded that VCs prove they could return actual cash to investors instead of simply marking up illiquid SaaS valuations on a spreadsheet.","url":"https://www.richardewing.io/glossary/dpi"},{"@type":"DefinedTerm","termCode":"ai-assisted-development","name":"AI-Assisted Development","description":"AI-Assisted Development encompasses the integration of advanced Large Language Models, coding agents, and generative copilots directly into the software development lifecycle (SDLC).\n\nBy 2025/2026, tools like Cursor, GitHub Copilot, Devin, and SWE-Agent evolved from simple autocomplete engines to autonomous architectural reasoning systems. The paradigm shifted developers away from \"writing code\" and towards \"prompt supervision, structural review, and security verification.\"\n\nWhile AI Dev tools radically boost individual throughput, they create significant systemic risks around codebase vastness (software entropy), undocumented context fragmentation, and the unprecedented generation of undetectable AI Technical Debt.","url":"https://www.richardewing.io/glossary/ai-assisted-development"},{"@type":"DefinedTerm","termCode":"agentic-workflows","name":"Agentic Workflows","description":"Agentic Workflows refer to multi-step, autonomous processes where AI agents dynamically plan, execute, and course-correct to achieve a high-level goal without human intervention at every step.\n\nContrasted with simple direct-prompting, agentic workflows use tools, browse the web, verify sub-tasks, and orchestrate other specialized agents to synthesize an outcome. In 2026, agentic workflows represent the final shift from AI as a \"Co-Pilot\" (assistant) to AI as an \"Auto-Pilot\" (executor).","url":"https://www.richardewing.io/glossary/agentic-workflows"},{"@type":"DefinedTerm","termCode":"sovereign-ai","name":"Sovereign AI","description":"Sovereign AI refers to artificial intelligence capabilities—including physical infrastructure, foundation models, and training datasets—that are entirely owned, governed, and localized by a specific nation-state, enterprise, or coalition to protect intellectual property and national security.\n\nBy 2026, regulatory pressures and data privacy mandates have forced governments and Fortune 500 enterprises to abandon multi-tenant cloud AI models in favor of sovereign architectures hosted physically within their own borders or Virtual Private Clouds.","url":"https://www.richardewing.io/glossary/sovereign-ai"},{"@type":"DefinedTerm","termCode":"model-routing","name":"Model Routing","description":"Model Routing is a dynamic architectural capability where incoming API requests are algorithmically distributed to different AI models (e.g., GPT-4, Claude 3 Haiku, Llama 3 8B) based on the specific intent, complexity, latency requirement, and cost-profile of the prompt.\n\nInstead of hardcoding a single LLM, an enterprise routing gateway assesses the task. Simple summarization is routed to an ultra-cheap, fast SLM. Complex reasoning is routed to an expensive frontier model.","url":"https://www.richardewing.io/glossary/model-routing"},{"@type":"DefinedTerm","termCode":"internal-developer-platforms","name":"Internal Developer Platforms (IDPs)","description":"An Internal Developer Platform (IDP) is a self-service paved road built by Platform Engineering teams that allows developers to spin up environments, deploy code, and manage cloud resources without waiting for DevOps or infrastructure teams.\n\nBy 2026, constructing an IDP is mandatory for engineering scale. It abstracts away the massive underlying complexities of Kubernetes, CI/CD, and Terraform into a unified Golden Path, significantly reducing developer cognitive load.","url":"https://www.richardewing.io/glossary/internal-developer-platforms"},{"@type":"DefinedTerm","termCode":"synthetic-data","name":"Synthetic Data","description":"Synthetic Data is information that is artificially generated by AI algorithms rather than collected from real-world events or users. It is designed to perfectly mimic the statistical properties of production data without containing any personally identifiable information (PII).\n\nIn 2026, the AI industry hit the \"Data Wall\" (running out of high-quality human text to train on). Synthetic data became the primary fuel for fine-tuning models, testing edge cases safely, and sharing datasets across borders without violating GDPR or HIPAA.","url":"https://www.richardewing.io/glossary/synthetic-data"},{"@type":"DefinedTerm","termCode":"ai-explainability-mandate","name":"AI Explainability Mandate","description":"An AI Explainability Mandate is a formal regulatory or corporate policy requiring that any decision made, influenced, or routed by an Artificial Intelligence system can be transparently audited, reasoned, and understood by a human operator.\n\nHistorically, neural networks were \"black boxes\". By 2026, aggressive consumer protection laws and enterprise risk committees mandated that if an AI denies a loan, flags a transaction, or routes a critical workflow, the engineering team must be able to prove exactly 'Why' mathematically.","url":"https://www.richardewing.io/glossary/ai-explainability-mandate"}]}

Technology & AI Glossary.

Technical Debt & Code Quality

Technical Debt

Legacy Code

Refactoring

Code Smell

DORA Metrics

Monolith to Microservices

Dependency Hell

Code Coverage

Cyclomatic Complexity

Technical Debt Quadrant

Dead Code

Spaghetti Code

Coupling & Cohesion

Test-Driven Development (TDD)

Code Review

Technical Debt Ratio (TDR)

Boy Scout Rule

Strangler Fig Pattern

Static Code Analysis

Code Documentation

Broken Windows Theory (Software)

Feature Flags

Code Duplication

Software Entropy

Technical Debt Ratio

Technical Debt

Technical Debt Ratio

Technical Debt Quadrant

AI & Machine Learning

Artificial Intelligence (AI)

Large Language Model (LLM)

AI Hallucination

Agentic AI

Prompt Engineering

Retrieval-Augmented Generation (RAG)

AI Governance

Vibe Coding

AI Response Drift (LLM Inconsistency)

Agentic Process Automation (APA)

Model Collapse (Synthetic Data Exhaust)

Transformer Architecture

Fine-Tuning

AI Inference

Model Hallucination Rate

Embedding (Vector Embedding)

Vector Database

AI Alignment

MLOps (Machine Learning Operations)

Model Distillation

AI Safety

Natural Language Processing (NLP)

Computer Vision

Generative AI

AI Bias

Multimodal AI

AI Agent Framework

Synthetic Data

Context Window

AI Guardrails

AI Benchmarking

AI Product Business Test

AI Agent

Hallucination Debt

Model Right-Sizing

Agentic Workflow

Retrieval-Augmented Generation

LLM Fine-Tuning

AI Hallucination Debt

AI Unit Economics

AI Technical Debt

Model Debt

Orchestration Debt

AI Observability

RAG Architecture

AI Cost Attribution

Agentic Workflow

AI Agent

Fine-Tuning