Shared vocabulary
Shared vocabulary
Section titled “Shared vocabulary”The cohort should use these terms consistently during the course and in daily work. Facilitators should correct unclear or conflicting usage when it appears.
Core terms
Section titled “Core terms”Context
Section titled “Context”The information available to a person or AI agent for the current task. Context can include source code, requirements, architecture, prior decisions and operating constraints.
Context is not automatically true. Participants must distinguish verified facts from supplied claims and unknown information.
Compressed context
Section titled “Compressed context”A structured summary of a source that is not available in the current workspace. It helps an AI agent reason across a boundary, but it remains a set of claims until those claims are verified.
Specification
Section titled “Specification”The agreed description of the work, its boundaries and the conditions that determine whether the result is acceptable. A specification must be clear enough to support planning, tests and review.
Acceptance criterion
Section titled “Acceptance criterion”A specific and observable condition that the completed work must satisfy. A reviewer should be able to determine whether the condition passed or failed.
Non-negotiable
Section titled “Non-negotiable”A constraint that applies to every implementation choice. Convenience, speed and local improvements do not override it.
Boundary
Section titled “Boundary”The point where ownership, trust, data or system responsibility changes. Repository, service, API and authorization boundaries can require different controls.
A check that prevents work from advancing until a required condition is met. A gate is enforced by the workflow or system, not left as advice.
Evidence
Section titled “Evidence”Information that supports a claim. Tests, diffs, logs, specifications and review findings can provide evidence. Evidence informs a decision, but it does not make the decision.
Validation
Section titled “Validation”An evaluation of whether the implementation satisfies the specification. Validation is different from running tests because the tests themselves may be incomplete or based on the wrong requirement.
Fresh context
Section titled “Fresh context”An independent review context that does not contain the author’s prior reasoning or conclusions. It reduces the chance that a reviewer repeats the author’s assumptions.
Finding
Section titled “Finding”A specific concern identified during validation or review. A useful finding cites the affected requirement, rule or code location.
Disposition
Section titled “Disposition”The recorded decision about a finding:
- Fix: The finding identifies a violation of a binding requirement.
- Reject: The finding is incorrect or relies on text that does not support it.
- Record: The finding identifies a real gap, but the available requirements do not define the expected behavior.
Behavior change
Section titled “Behavior change”A consistent change in how participants perform real work after the course. Recall, confidence and course satisfaction do not prove behavior change.
Terms to avoid
Section titled “Terms to avoid”Avoid language that hides responsibility or overstates certainty:
| Avoid | Use instead |
|---|---|
| The AI decided | The AI recommended; the named person decided |
| The tests prove it works | The tests provide evidence for the behaviors they cover |
| The agent knows | The agent has access to, inferred or could not verify |
| The review passed everything | The review evaluated the listed scope and returned no findings |
| Best practice | The specific standard, rule or evidence that supports the choice |
| Human in the loop | The named role and the decision that role owns |
Vocabulary check
Section titled “Vocabulary check”Participants should be able to use each core term in a sentence about an unfamiliar engineering scenario. They should also be able to explain the difference between evidence and acceptance, tests and validation, and context and verified fact.