Terminology used in the book "Dark Code".
AI Bill of Intent (ABOI): A proposed structured record that explains what an AI-generated change was meant to do, under what constraints it was created, and how that intent should be reviewed.
AI Psychology: The practical study of how language models behave under prompts, constraints, context, and feedback so teams can manage them more effectively.
AI Systems Architect: The senior technical role responsible for defining intent, constraints, verification expectations, and integration boundaries for AI-assisted software work.
Anchor Pattern: A context design technique that repeats stable key facts or rules so the model stays oriented around the same governing constraints across a long task.
Architect of the Invisible: The human role that governs systems whose internal implementation is increasingly generated, opaque, or too large for direct line-by-line ownership.
Behavioral Coverage: Evidence that tests meaningfully exercise the behaviors the system must satisfy, rather than merely executing lines of code.
Behavioral Validation: The process of checking whether a system behaves correctly under realistic conditions, independent of whether its internals look understandable.
Business Goal: The explicit outcome the system exists to achieve, stated in operational terms before generation begins.
Canary Deployments: A release strategy that exposes a new system version to a limited slice of production traffic so behavior can be observed before full rollout.
Chain of Custody: The documented sequence showing who requested, approved, generated, modified, and shipped an AI-produced change.
Code Archaeology: The forensic reconstruction of why code exists and how it evolved when intent is no longer obvious from the implementation alone.
Code Forensics: Targeted investigation of code after a failure, anomaly, or risk signal to diagnose what happened and why.
Code Labels: Metadata attached to generated code to indicate origin, risk, intent, or verification status and improve later review and tracing.
Configuration Drift: The silent divergence of environments, settings, or dependencies that causes systems to behave differently from what teams think they deployed.
Consensus Checking: A support technique that compares multiple model interpretations or analyses to see where they agree, diverge, or expose uncertainty.
Context Architecture: The overall design of how prompts, retrieved materials, instructions, examples, and constraints are organized for generation.
Context Engineering: The deliberate work of selecting, structuring, versioning, and delivering the right context to the model for a given task.
Context Manager: The function or role responsible for maintaining the quality, freshness, and structure of the context systems that shape AI output.
Context Store: The governed repository of reusable prompt materials, rules, examples, and reference artifacts supplied to models as working context.
Context Window: The limited amount of information a model can actively consider in a single interaction.
Context Window Budget: The practical limit on how much context can be included before signal is crowded out, degraded, or made too expensive to manage well.
Contract First Generation: A generation approach that defines interfaces, requirements, and expected behavior before asking the model to produce implementation details.
Contract Testing: A verification method that checks whether a system obeys the explicit interface and behavior promises it is expected to satisfy.
Cognitive Load: The amount of mental effort required to understand, review, or safely operate a system or workflow.
Curation: The disciplined human selection, refinement, and approval of prompts, context, artifacts, and outputs rather than blind acceptance of generated material.
Dark Code: Software whose behavior may be operationally useful but whose full internal reasoning, authorship path, or implementation logic is not directly possessed by the humans deploying it.
Dead Context: Context that is stale, irrelevant, contradictory, or present only as noise and therefore weakens generation quality.
Declarative Intent: A description of what the system must achieve and what constraints it must obey, without prescribing the step-by-step implementation.
Declarative Programming: A style of specifying desired outcomes and constraints rather than manually detailing every procedural step.
Distributed Tracing: Runtime instrumentation that follows requests across services and components so teams can see how work actually flowed through the system.
Explainable AI Code: Generated software accompanied by tools or artifacts that make its purpose, structure, and behavior easier for humans to interpret.
Glass Box: A system state in which the governing rules, intent, evidence, and operational behavior are made more legible even if the implementation is still partly opaque.
Governance Stack: The layered control model of intent, generation constraints, verification, runtime observability, provenance, and human accountability working together.
Governed Asymmetry: The principle that not all generated code requires the same depth of control, evidence, or oversight, because governance should scale with risk.
Green Paradox: The false confidence created when builds, tests, or lint checks pass even though the underlying system may still be semantically wrong or unsafe.
Grey Code: Code that is not fully transparent yet is made more navigable through labels, explanations, mappings, and other legibility aids.
Guardian AI: An AI system used to monitor, check, or constrain the output or behavior of another AI-driven system.
Guardrails Pattern: The practice of embedding constraints, diagnostics, and guidance into generation so outputs are easier to verify, trace, and operate safely.
Hallucination: A model output that is syntactically plausible but factually invented, semantically wrong, or unsupported by reality.
Hallucination Loop: A failure pattern in which generated explanations or follow-on outputs reinforce earlier false assumptions instead of correcting them.
Hallucinogenic Misinformation: What happens when AI models communicate hallucinated information that is then assumed accurate by a human.
Hidden Compiler: The idea that human intent is increasingly transformed into systems through prompt-driven or model-mediated generation rather than only through manual coding.
High Fidelity Telemetry: Rich, precise runtime data that captures what a system actually did with enough detail to support diagnosis, accountability, and response.
Hierarchical Prompting: A prompt structure that organizes instructions in layers so higher-order rules and lower-level task details do not compete chaotically.
Human-in-the-Loop: A system design in which human judgment remains part of approval, escalation, or correction rather than being removed from the control path.
Hybrid Sprint: A delivery cycle in which human and AI work are intentionally combined, with governance and review adapted to the mixed workflow.
Illusion of Competence: The mistaken belief that a system is reliable because it produces polished outputs, even when its actual reasoning or correctness is weak.
Illusion of Familiarity: The false sense that code is understood merely because it looks like familiar software patterns or resembles human-written structure.
Imperative Trap: The habit of over-specifying implementation steps instead of defining goals and constraints at the level the model can better work from.
Inline Why Comment: A short comment that explains the reason for a design decision or constraint, preserving intent that would otherwise disappear into generated code.
Integration: The work of making generated components fit coherently with existing systems, contracts, workflows, and operational realities.
Integration Requirements: The explicit technical, workflow, and dependency conditions a generated system must satisfy to fit into the surrounding environment.
Intent: The governing description of desired outcome, constraints, boundaries, and success conditions that should exist before generation begins.
Intent Based Engineering: An engineering approach that treats reviewed intent, not raw implementation detail, as the primary control surface for software generation.
Intent Management: The practice of storing, reviewing, versioning, and governing intent artifacts as first-class engineering assets.
Intent Specification Framework: The structured schema for defining what a generated system must do, including its goals, constraints, boundaries, and required integrations.
Intent and Evidence Package: The review artifact that combines declared intent with the proof, tests, and supporting material needed for approval.
Intellectual Ownership: The human responsibility for understanding the purpose, risk, and operational consequences of a system even when much of its code was generated.
Interpreter Models: Models or tools used to analyze, summarize, or explain generated code so humans can navigate it more effectively.
Invariants: Properties or rules that must remain true across all valid executions of a system.
Large Language Model (LLM): A machine learning system trained on large text corpora that predicts and generates language-like outputs, including code and analysis.
Ledger of Intents: A durable record of the prompts, goals, approvals, and declared purposes behind generated artifacts.
Living Context: Actively maintained context that stays current with system rules, priorities, and operational reality.
Logic Linter: A proposed tool or review layer that checks whether generated logic aligns with declared intent and constraints, not just syntax rules.
Macro Delegation: Assigning larger bounded outcomes or system-level work to an AI rather than only isolated implementation fragments.
Micro Delegation: Assigning small scoped tasks to an AI while retaining tight human control over the surrounding workflow.
Observability: The ability to understand system behavior through its emitted signals, logs, traces, metrics, and runtime evidence.
Observability by Design: Building diagnostic visibility into the system from the start so operational truth is available when behavior must be explained or repaired.
Operational Risk: The chance that a system will fail, misbehave, or create harm in real use, especially under production conditions.
Outcome Based Governance: Governing software by the quality of verified behavior and runtime results rather than by assumptions about how readable the code looks.
Performance Constraints: The speed, scale, efficiency, or resource limits the generated system must respect.
Prompt Audit: The review and recordkeeping discipline that treats prompts as governed artifacts tied to intent, approval, and accountability.
Prompt Components: The structured parts of a prompt, such as instructions, context, examples, rules, and output requirements.
Prompt Gatekeeper: The role or control point that approves, restricts, or monitors prompts used for significant generation tasks.
Prompt Management System (PMS): A system for storing, versioning, approving, and tracing prompts as controlled engineering artifacts.
Prompt Reverse Engineering: The attempt to infer what prompt or intent produced a generated artifact after the fact.
Prompt Review: The upstream evaluation of prompts, intent, and constraints before generation is accepted as legitimate engineering work.
Property-Based Testing: A testing method that checks whether general properties remain true across many generated inputs rather than only fixed example cases.
Provenance: The documented origin and lineage of a generated artifact, including what produced it and under whose authority.
Provenance Trails: The linked records that show how intent, prompts, outputs, approvals, and deployments connect across the lifecycle of a change.
Pull Request (PR): A proposed code change package used for review, discussion, and approval before merging into a shared codebase.
Red Team: A deliberate adversarial review function that stress-tests systems, prompts, or controls by looking for failure modes and exploit paths.
Rubber Stamping: Superficial approval that preserves the ritual of review without supplying real scrutiny or evidence.
Runtime Observability: The discipline of watching deployed systems through telemetry, traces, logs, and signals to understand real behavior after release.
Runtime Truth: The principle that deployed behavior, not generated appearance or claimed intent alone, is the final operational evidence of what the system did.
Security Boundaries: The explicit limits on access, privilege, data handling, and trust zones the system must not violate.
Selective Inspection: Targeted reading of code or artifacts when risk, failure, regulation, or forensic need justifies it, rather than as the primary review method for everything.
Semantic Drift: The gradual movement of generated output away from the intended meaning, constraints, or domain logic over time.
Semantic Mapping Interfaces: Tools or views that connect code structure to higher-level meaning, intent, or behavior so humans can navigate opaque systems more effectively.
Semantic Naming: Naming functions, types, modules, and components according to purpose and meaning rather than local implementation trivia.
Semantic Summary: A condensed explanation of the meaning and role of a large body of material so it can be carried forward as context without full repetition.
Shadow Prompting: Unapproved or hidden prompt usage that bypasses formal governance, review, or traceability.
Smart Chunking: Breaking context into meaningful units so relevant material can be supplied to the model without flooding the context window.
Syntactic Mimicry: The production of code that looks structurally correct and familiar while still missing the intended semantics or real-world correctness.
System Prompt: The high-level instruction layer that defines enduring rules, posture, and constraints for the model within a task or environment.
Technical Debt: The future cost created by expedient engineering choices that make systems harder to understand, change, or operate.
Telemetry: The signals emitted by a system about its internal activity and external behavior during operation.
Trust Ladder: A staged adoption model in which organizations earn confidence in AI-assisted systems through bounded rollout, evidence, and progressive exposure.
Trusted Black Box: A component accepted primarily on verified behavior and controlled evidence rather than on full internal human comprehension.
User Prompt: The task-specific instruction provided by the human to direct the model within a given interaction.
Vendor Mindset: The discipline of treating generated code like externally supplied software that must earn trust through contracts, tests, and evidence.
Verbal Precision: The skill of expressing goals, constraints, and desired behavior clearly enough that generated systems can be governed reliably.
Verification: Independent proof that a system behaves correctly enough for its intended use and risk level.
Verification Over Inspection: The doctrine that approval should rest primarily on behavioral evidence and independent testing rather than on line-by-line reading alone.
Watchdog AI: An advanced pattern in which one AI observes runtime signals or outputs from another system to detect anomalies, policy violations, or risk conditions.