CONSISTENT TERMS
Glossary
Short explanations of the terms used in this guide. Each term links to a related lesson.
Terms: 46
- Acceptance criteria
Conditions that a change must satisfy. Define them before implementation so a reviewer can assess the result.
Read lesson →- Agent
A system that uses a model and tools to act toward a goal. Its permissions determine which actions it can perform.
Read lesson →- AI software factory
An operating model that connects AI-assisted software work across the lifecycle. Assess its responsibilities, controls, and evidence beyond code generation.
Read lesson →- Authentication
Verification of an identity. Authentication does not by itself grant permission to access a record or perform an action.
Read lesson →- Autonomy
The scope of actions a system can perform without another human decision. Define boundaries by action and consequence.
Read lesson →- Build vs buy
A decision about which capabilities to create internally and which to obtain from suppliers. Compare responsibilities as well as costs.
Read lesson →- CI/CD
Continuous integration and continuous delivery or deployment. Automated workflows build, check, and prepare or release software under defined policies.
Read lesson →- Cloud native
Practices for repeatable development and operation in dynamic environments. Assess automation, state, resilience, and observability beyond container packaging.
Read lesson →- Code review
Inspection of a proposed code change. A reviewer checks behavior, scope, risks, and supporting evidence before acceptance.
Read lesson →- Context
Information available to a model for the current task. It can include instructions, files, conversation, and tool results.
Read lesson →- Data boundary
A defined limit on where data can move, who can access it, and which purposes are permitted.
Read lesson →- Deployment
Placement of a software version in an environment. Deployment and release to users can be separate decisions.
Read lesson →- Diff
A comparison that shows changes between versions. Review the actual diff, including configuration and dependency changes.
Read lesson →- Disaster recovery (DR)
Restoration of useful service and recoverable data after a disruptive event. The plan includes dependencies, decisions, and tested procedures.
Read lesson →- DORA research
Research on software delivery and organizational performance. This research is separate from the EU Digital Operational Resilience Act.
Read lesson →- DPIA
Data protection impact assessment. A structured assessment of processing risks to people and the measures used to address them.
Read lesson →- Evaluation
A defined method for assessing a model or workflow against representative tasks and acceptance criteria.
Read lesson →- Evidence
An inspectable record that supports a claim. Examples include test results, configuration, approvals, and release identifiers.
Read lesson →- Frontier model
A model described as being near the current capability boundary. The label does not guarantee correctness for a specific task.
Read lesson →- Governance
The decision rights, policies, controls, and evidence used to direct work and assign accountability.
Read lesson →- Hallucination
Generated content that is incorrect or unsupported but can appear credible. Verify consequential claims against independent evidence.
Read lesson →- High availability (HA)
Design for continued useful service despite defined component failures. Verify the complete request path and surviving capacity.
Read lesson →- Infrastructure as code
Version-controlled definitions of infrastructure resources and configuration. A reviewed plan shows the proposed resource changes.
Read lesson →- Least privilege
Grant only the permissions needed for a defined task. Restrict resources, actions, and duration where possible.
Read lesson →- Multi-AZ
Deployment across Availability Zones within an AWS Region. It can reduce exposure to an AZ failure, depending on the complete design.
Read lesson →- Multi-region
Deployment across cloud Regions. Define routing, data consistency, recovery, and operational responsibilities for the required failure scenario.
Read lesson →- Observability
The ability to investigate system behavior through signals such as logs, metrics, and traces. Useful signals support a specific operational question.
Read lesson →- Prompt injection
An attempt to make a model treat untrusted content as instructions. Tool permissions affect the possible consequences.
Read lesson →- Pull request
A proposal to merge a branch into another branch. It collects the diff, discussion, review, and check results.
Read lesson →- RAG
Retrieval-augmented generation. A system retrieves information and supplies it to a model as context. Retrieval does not make content trustworthy.
Read lesson →- Regression test
A test intended to detect the return of a known defect or an unwanted change in existing behavior.
Read lesson →- Rollback
Restoration of a previous software or configuration version. Data compatibility can limit whether rollback is safe.
Read lesson →- RPO
Recovery Point Objective: the maximum acceptable data loss measured as time. Compare the usable recovery point with the interruption time.
Read lesson →- RTO
Recovery Time Objective: the maximum acceptable interruption before useful service returns. Include detection, decisions, restoration, and validation.
Read lesson →- SBOM
Software bill of materials. An inventory of software components. It supports investigation but does not prove the absence of vulnerabilities.
Read lesson →- SCA
Software composition analysis. Analysis of identified software dependencies, often against known vulnerability information. Coverage depends on the tools and scanned inputs.
Read lesson →- SDLC
Software development lifecycle. The activities required to define, build, release, operate, change, and retire software.
Read lesson →- Self-healing
Automated recovery from a defined failure using authorized actions, verification, and stop conditions. It does not necessarily fix the underlying software defect.
Read lesson →- Self-improvement
Using feedback to change a system and verify a better outcome. Specify whether code, configuration, instructions, workflow, or model parameters change.
Read lesson →- SIRT / CSIRT
A security incident response team. It coordinates incident investigation and response within defined authority and organizational responsibilities.
Read lesson →- SLO
Service level objective. A target for a defined measure of service behavior over a specified period.
Read lesson →- SOC
Security operations center. A function that commonly monitors security signals, investigates alerts, and escalates suspected incidents. Its actual scope must be agreed.
Read lesson →- Threat model
A structured description of assets, trust boundaries, threats, and controls for a system or workflow.
Read lesson →- Traceability
The ability to connect a requirement to its implementation, checks, approval, and released version.
Read lesson →- Vibe coding
An exploratory approach that directs generated code through prompts and visible behavior, often without inspecting every implementation choice.
Read lesson →
No term found. Try a different spelling.