BELA65 — Glossary

Every term, translated once, reused everywhere

This is the only place jargon gets defined. When any asset uses a technical term, it links or copies the "Plain-language translation" from here — it does not re-explain in its own words. Consistency of language is a feature of the brand.

House rule: the first time any asset uses a term, it immediately follows with the italic plain-language line below. Example: "BELA builds a Business Reality Model — think of it as BELA's blueprint of your business before any software is built."

---

How to read this glossary

Each entry has three parts:

• Term — the exact words we use (spelling and capitalization are fixed).
• Plain-language translation — the everyday sentence that always accompanies it.
• Say / Don't say — the approved phrasing and the trap to avoid.

---

The Pipeline Terms

Business Requirement

Plain-language translation: What you want the software to do, described in your own words.

• Say: "your business need," "what you want built."
• Don't say: "spec" or "ticket" (too technical, too small).

Business Understanding

Plain-language translation: The step where BELA actually reads and understands what your business does — before building anything.

• Say: "BELA understands your business first."
• Don't say: "requirements gathering" (sounds like paperwork; this is comprehension).

Clarification

Plain-language translation: When something is unclear, BELA asks you a question — just like a good engineer would — instead of guessing.

• Say: "BELA asks smart questions when something's unclear."
• Don't say: "prompt refinement."

Business Reality Model (BRM)

Plain-language translation: BELA's blueprint of your business before any software is built — the people, things, and rules your software will need to handle.

• Say: "a clear model of your business," "BELA's blueprint of your business."
• Don't say: "schema" or "ontology" in customer-facing copy (fine in the CTO layer only).

Architecture

Plain-language translation: The design of the software — how all the pieces fit together and why.

• Say: "the design of your software."
• Don't say: "the codebase" (architecture is the plan, not the code).

Engineering Reality

Plain-language translation: BELA's honest picture of what actually has to be built to make the design real.

• Say: "what it really takes to build it."
• Don't say: leave undefined — always pair with the translation; this term is unfamiliar to everyone.

Technology Provider Selection

Plain-language translation: BELA choosing the right technologies for the job — the way an architect chooses the right materials.

• Say: "BELA picks the right technology for the job."
• Don't say: "framework config."
• Note: reinforces that BELA is provider-neutral — it isn't locked to one technology.

Project Assembly

Plain-language translation: BELA putting the whole application together into one working piece of software.

• Say: "BELA assembles the actual application."
• Don't say: "code generation" (this is assembly of a designed system, not spitting out files).

Testing

Plain-language translation: BELA checking that the software actually works.

• Say: "BELA tests what it built."

Self Review

Plain-language translation: BELA reviewing its own work — before you do.

• Say: "BELA reviews its own work first."
• This is a signature wow moment. Use it.

Self Repair

Plain-language translation: When BELA finds a problem in its own work, it fixes it itself.

• Say: "BELA fixes its own mistakes."

Qualification

Plain-language translation: BELA making sure the software meets the standard it's supposed to meet — like a final exam.

• Say: "the software has to pass BELA's exam."

Certification

Plain-language translation: BELA's stamp of approval that the software is genuinely ready.

• Say: "BELA certifies it's ready."

Deployment

Plain-language translation: Getting the finished software running where people can actually use it.

• Say: "putting it live."

Production-Ready Software

Plain-language translation: Software that's genuinely ready to be used for real, not just a demo.

• Say: "ready to run in the real world."
• Don't say: "MVP" or "prototype" (those are the opposite of the claim).

---

The Signature Concepts

Autonomous Engineering Operating System

Plain-language translation: One piece of software that does the whole job of an engineering team — understanding, designing, building, and proving software on its own.

• Say: "an operating system for engineering."
• Don't say: "AI developer tool," "code generator," "copilot" — these are the categories we explicitly are NOT (see 00_messaging-house.md).

Engineering Passport

Plain-language translation: A plain record that ships with every application, showing how it was built and why you can trust it — like a passport that proves where something has been and that it's genuine.

• Say: "every app gets its own Engineering Passport."
• This is a brand signature. Give it a recurring visual (a clean document/booklet).

Provider-Neutral

Plain-language translation: BELA isn't tied to one technology — it can build the same understanding using different tools, choosing what fits best.

• Say: "not locked to any one technology."

Autonomous

Plain-language translation: It does the work itself, without a person driving each step.

• Say: "it owns the whole job."
• Careful: "autonomous" must always be true for the stage described. If a stage still needs a human, describe it honestly (see 03_claims-ledger.md).

---

Words We Ban (and what to say instead)

---

Future Improvements

• Add pronunciation and translation notes per term for localization.
• Add a "customer-facing vs. investor-facing vs. engineer-facing" tag to each term so writers pick the right register automatically.
• Expand with capability-specific terms as Phase 4 defines them (keep all new terms flowing back into this one file).

---

Version History