Glossary
Entity
Section titled “Entity”A core object: person, role, value stream, project, OKR, etc. More under Entity Types.
Relationship
Section titled “Relationship”A directed link between two entities — e.g. “person executes role”. See Understanding Relationships and Relationship Types.
A change that has not yet been published. Others see the change only after approval. More under Drafts.
Approval Mode
Section titled “Approval Mode”Determines who may publish a draft — from “anyone in the tenant” to “only configured persons”. See Approval Modes.
Scenario
Section titled “Scenario”A bundle of related drafts that is planned and published together. See Scenarios and Collective Proposals.
Collective proposal
Section titled “Collective proposal”A scenario submitted for decision as one proposal: one set of affected people, one vote, one outcome for every change it contains. A single objection brings the whole proposal down. See Scenarios and Collective Proposals.
Quorum
Section titled “Quorum”The share of affected people that must have responded before a draft or a collective proposal may be decided at all. See Approval Modes.
Customer ID
Section titled “Customer ID”An optional, freely chosen identifier per entity. Details under Customer ID.
Realm / Tenant
Section titled “Realm / Tenant”The realm is the physical database. Multiple logical tenants can live within it.
Mention
Section titled “Mention”An @-reference to another entity inside a description text. More under @-Mentions.
Governance conformance
Section titled “Governance conformance”The comparison between the described organisational model and what can actually be evidenced: is anybody accountable for this value stream? Did the change go through the agreed approval mode? Do the permissions match a role? The subject is accountability, not the individual case. More under Governance Mining.
Process mining
Section titled “Process mining”A different discipline: it assesses the case — an order, an invoice, a ticket — from an event log out of a transactional system, and optimises cycle times and automation rates. roleALPHA does not offer this: no control-flow conformance, no BPMN or XES import, no desktop capture, no statement about cycle times. The two complement each other — see Suitability check — is my case log fit for a process analysis?.
Conformance
Section titled “Conformance”A statement about whether something runs as agreed. In roleALPHA it covers three things: sequence, actor and rule. It expressly does not cover the control flow of a business process (token replay, alignments, fitness/precision) — the step model and activity vocabulary for that are missing, and that is a deliberate boundary, not an open task.
Case log (event log)
Section titled “Case log (event log)”A list of events from an operational system, each with a case identifier, an activity, a timestamp and an actor. It is the basis of every statement about a value stream flow — and in practice often unfit, because the identifier is missing or the timestamps are rounded to the day. Whether it holds up is what the Suitability check — is my case log fit for a process analysis? says, before anything is stored.
Demand
Section titled “Demand”A homogeneous requirement: amount + time span + activity + skill. It states what an initiative or ongoing operations needs in terms of capacity — the target side. If a project needs backend and UX, those are two demands on the same source; that keeps partial coverage expressible. See Demand & Resource Planning.
Run and change
Section titled “Run and change”The two quantity forms of the same demand, not two concepts. Change names a total across a from–to span, run an amount per period from a date onwards and usually without an end. Run is the larger share in most organisations and is nonetheless the one most often forgotten — and then the same capacity is planned twice. See Running operations and initiatives.
Member
Section titled “Member”Whoever can cover a demand: a human or an AI agent. For planning the two are structurally the same — they perform roles, carry competences and have limits. A human has one (time), an agent has two (throughput and budget). See AI agents have limits.
Baseline and available capacity
Section titled “Baseline and available capacity”The baseline is the contractually agreed working time. Available capacity is what remains after absences and non-working days are deducted. Planning runs against the available figure, not the contractual one — reading only the baseline means overplanning systematically. See Capacity — baseline, deductions, available.
Coverage
Section titled “Coverage”Demand minus plan, per period. It is calculated and never stored: the result depends on two sides, and a stored value would be the first one nobody keeps up to date.
Planning horizon
Section titled “Planning horizon”How far a run demand is planned ahead (default: twelve periods). It never ends by itself, so “covered” needs a boundary here: it means covered for the foreseeable future. A coverage statement for “three years from now” would be made up.