Help

Glossary

Every term and id prefix used in Alara Code, defined in a line.

The words and ids used across Alara Code, each defined in a line or two. Ids come first, because they are what you meet inside the documents; product terms follow. Both lists are alphabetical.

Id prefixes

Every document cites the ids of the items it owns, and later documents cite earlier ones, which is what makes the set traceable from requirement to test. The bridge checks that a document cites every id its step owns.

Id	Example	What it identifies	Where it is created
`BR-NN`	`BR-01`	A business rule, in the SRS business-rules table	SRS
`DC-NNN`	`DC-003`	A design component: one part of the system's design, such as a service, module, API or database. On the board, an epic.	SDS
`DC-NNN-NN`	`DC-003-02`	An implementation unit: a ticket-sized piece of a design component (a table, an endpoint, a worker, an event handler, a UI component or a module). Shown as "Unit" on a board ticket.	SDS
`FEAT-NN`	`FEAT-02`	A system feature in the SRS; each functional requirement is owned by exactly one feature	SRS
Framework id	`GDPR`, `ISO-27001`	A regulatory framework the compliance checks use: `AAOIFI`, `CBUAE-2024`, `GDPR`, `ISO-27001`, `PCI-DSS-4`, `PPRA-2024`, `SAMA-2024`, `SBP-2024`	Built in
Framework control id	`GDPR-ART6-001`, `PCI-REQ-01`	One control within a framework, cited by a compliance flag	Built in
`REQ-CON-NNN`	`REQ-CON-002`	A constraint requirement	SRS
`REQ-FUNC-NNN`	`REQ-FUNC-014`	A functional requirement ("The system shall ..."), with a MoSCoW priority and acceptance criteria	SRS
`REQ-NFUNC-NNN`	`REQ-NFUNC-005`	A non-functional requirement: performance, security, availability and similar qualities	SRS
`RISK-NNN`	`RISK-002`	A project risk, with likelihood, impact and mitigation	Scope
`SCOPE-NNN`	`SCOPE-004`	An in-scope item: a feature or capability the project will deliver	Scope
`T1`, `T2`, ...	`T3`	An implementation step inside one ticket, with a check that verifies it	Tasks
`TC-NNN`	`TC-042`	A test case, numbered across the whole project from `TC-001`; ids are never reused	STS
Ticket key	`FO-007`	A ticket on the board: a two-letter prefix from the project name and a number that runs across the whole project	Tasks
`UC-NN`	`UC-05`	A use case in the SRS, tied to one feature	SRS

NNN means a zero-padded three-digit number (001), NN a two-digit one (01).

Terms

Term	Definition
Abort	Stopping a running step with Stop. The run is recorded as `aborted` ("Cancelled" in the conversation). Needs the Projects › Abort grant.
Acceptance criteria	The testable conditions a requirement or ticket must meet, usually in Given/When/Then form.
Agent	The Alara reasoning agent bound to a project. Every step and every chat reply runs on it, as the person who started the step or sent the message. Chosen in Settings › Agent.
Alara	The platform that hosts the agents Alara Code runs on. Your organization's Alara administrator decides which agents are shared with Alara Code.
Approval	A person's acceptance of a document awaiting review. It is tied to that exact version: regenerating the document re-opens it. Approving unlocks the next step.
Approval gate	The human review after the RFP, Scope, SRS, SDS, STS and Proposal steps. The next step stays locked until the document is approved.
Artifact	A file a step produced. The Artifacts tab is the document reader for all of a project's documents.
Awaiting your review	The state of a document that has been produced and not yet approved (`pending_review` in Run History).
Board	The project's Board tab: the Tasks step's tickets laid out in To Do, In Progress, Review and Done. See The delivery board.
Bridge	Alara Code's API server. It runs the steps, checks documents, enforces permissions and stores the project.
Brownfield	A project for an existing system ("Existing system" when creating a project), connected to an existing repository.
Build plan	The readable document the Tasks step writes: "Build Plan — Epics and Tickets".
Check agent	The readiness check in Settings › Agent: it asks the bound agent which skill files it can see and lists any that are missing.
SDLC Studio	The project's main view (formerly Commands): the step rail on the left, one conversation holding the project chat and every step run in the middle, the composer at its foot, and the open document on the right.
Step rail	The list of steps beside the conversation in SDLC Studio: each step's state, its document version, and the button that runs or re-runs it.
Version (of the pipeline)	A pass through the documents. Version 1.0 is the first; once every document is approved you can start the next, which revises Scope → Proposal with the changes you describe.
Compliance	The step that checks requirements against the built-in regulatory frameworks and flags gaps. Not approvable. See Compliance.
Compliance flag	A requirement that matches a framework control, recorded with the control's severity and the evidence it requires. The SRS step raises the first flags.
Composer	The box at the bottom of the conversation in SDLC Studio: type a message to the agent, type `/step` to run a step, or press the round button to run the next step.
Contract	Two meanings. For a step: the fixed JSON shape the agent must reply in. For a ticket: the interface the unit exposes, copied from the design.
Correction	The agent's own reply sent back with each problem the checks found — where, expected, found, how to fix — asking it to fix only those. A step makes up to three attempts and keeps the best reply.
Design component	A part of the system's design in the SDS, with an id `DC-NNN`, its responsibilities, interfaces, data stores and implementation units.
Document	The Markdown file a step produces, with a title block (project, client, version, date) added by the bridge.
Draft	A document that has been produced and is awaiting review.
Epic	A group of tickets on the board: one per design component.
Generate RFP	The button the chat offers when the agent has enough to draft your RFP. It runs the RFP step from the conversation.
Greenfield	A project for a new system ("New system" when creating a project), for which Alara Code can create the repository.
Implementation unit	A ticket-sized piece of a design component, id `DC-NNN-NN`. Each becomes one ticket.
Integrations	The permission module for connecting repositories and pushing documentation.
Lock	The per-project guard that lets only one step run at a time. A second start gets "Another command is already running for this project."
Locked	A step whose prerequisites are not met. Hover it to see what it is waiting for.
Manifest	The Tasks step's machine-readable ticket list (`tasks-vN.json`). The board is filled from it.
Markdown checks	The bridge's checks on every document: required headings, cited ids, closed and typed diagram blocks, minimum diagram count, and size.
Mermaid	The text format the documents use for diagrams. The reader draws them in your browser.
Module permission	A grant in your PolyX organization role, such as Projects › Run › create, that allows an action. See Members and permissions.
MoSCoW priority	A requirement's priority: must, should, could or won't.
Organization	Your PolyX organization. Every project, document and run belongs to one, and you only ever see your own.
Organization administrator	A member with the administrator role in PolyX. Sees every project in the organization; gets no extra action rights.
PAT	A personal access token for Azure DevOps, used to connect a repository.
Pipeline	The ordered steps from RFP to Proposal. See How the pipeline works.
PolyX	The sign-in and organization service Alara Code uses. Roles and module permissions are managed there.
Preview / Markdown	The reader's switch between the formatted document and its Markdown source.
Project	One engagement: its RFP, documents, board, team access, agent and repository.
Proposal	The client-facing proposal drawn from the approved documents. Approvable.
Request changes	Asking for specific changes to a document awaiting review. Only that step is regenerated, then it comes back for review.
RFP	Request for Proposal: the pipeline's starting document, uploaded or drafted from the chat.
Run	One execution of a step, from start to its outcome. Listed in Run History.
Run budget	The longest a single run may take (25 minutes by default) before it is stopped.
Run History	The project tab listing the last 20 runs, and the sidebar page listing runs across projects. See Run history and costs.
Scope	The step that turns the RFP into objectives, in- and out-of-scope items, stakeholders, constraints, risks and deliverables.
SDS	Software Design Specification: the design components, architecture decisions, data design and interfaces.
Skill	One of the reference files the agent carries, each telling it how to do one job (write the scope, author test cases, answer the chat, ...).
Skill pack	The set of skill files a project agent needs, available under Settings › Organization agents.
SRS	Software Requirements Specification: the requirements, features, use cases, business rules and analysis models.
Stale	An approved step built on an older version of a step before it. Its button reads "re-run, upstream changed".
Step	One stage of the pipeline, run as a command such as `/scope`.
Story points	A ticket's size estimate, shared out from its design component's complexity.
STS	Software Test Specification: the test cases and the test plan around them.
Tasks	The step that turns the design into epics and tickets for the board. Not approvable.
Team	A PolyX team attached to a project to give its members (all of them, or selected ones) access.
Ticket	One implementation unit on the board, with its specification, criteria, steps, requirements and test cases.
Traceability	The step that builds the matrix from requirement to feature, design component and test case, and shows where coverage is missing. It runs without the agent. Not approvable.
Version	Each run of a step writes a new numbered version of its document (`scope-v2.md`). Approval applies to one version.
Working branch	The repository branch the project works on: `development` for a new repository, the base branch for an existing one.