Boards & Sessions

Governance in Albumi is split across two entities that people routinely confuse. A Review Board is a standing committee — the same people, the same scope, set up once. A Review Session is a specific meeting that board holds — a date, an agenda, a set of change requests worked through to decisions. One board runs many sessions over time.

Keep them separate in your head. The board answers who reviews. The session answers when they review, and what they decided in that one meeting.

Section 1 — Review Boards

What a board is

A Review Board is a named group of people responsible for reviewing change requests of a particular kind. You configure a board once — its name, its scope, its members — and then every session of that board reuses the same composition. If the board is your Data Architecture Board, then every Data Architecture Board session is staffed by the same roster, unless membership is explicitly changed on the board itself.

A board is not a calendar. It has no schedule and no agenda of its own. Those are session concerns. A board sitting with no sessions is a board waiting to be convened.

Composition

A board has three member roles:

Chair. The person accountable for the board as a whole. The chair sets scope, maintains membership, and is the fallback owner for sessions that do not have a specific owner. There is one chair per board.
Voting members. Reviewers whose approvals and rejections count toward decisions made in session. This is the core of the board — the people whose judgement the organization is relying on.
Advisory members. People who attend and contribute opinions but do not cast votes. Advisory members are there for context and expertise — a security lead consulted on data-related changes, a finance lead consulted on capitalizable spend — without burdening them with decision accountability. Use this role rather than omitting the people entirely.

Membership is stored on the board and reused every time a session is created. Changes to board membership take effect on future sessions; sessions already underway keep the roster they were created with.

Status

A board carries one of two statuses:

Active — the board is in use. New sessions can be created against it.
Archived — the board is retired. It remains visible for historical context, but no new sessions attach to it.

There is no workflow state between Active and Archived. If a board’s scope is temporarily off the table, archive it and recreate or reactivate later; do not leave a dormant Active board in the list.

When to have multiple boards

One board per organization is almost always wrong. The whole point of the board abstraction is routing: a change request is reviewed by the board whose scope fits the change, not by a single generic committee that has to sit through everything.

Typical splits that work:

Technology Board — changes affecting IT Components and the platform landscape (runtimes, databases, message brokers, identity providers).
Data Architecture Board — changes affecting Data Objects, integrations that move sensitive data, and data classification decisions.
Application Portfolio Board — lifecycle and TIME-classification decisions on applications (new go-lives, migrations, retirements).
Security Review Board — changes that touch authentication, authorization, or data protection boundaries.

You do not need all of these. You need as many boards as you have distinct reviewer populations. Two boards with identical memberships and overlapping scope are one board.

Board versus session

Internalize this distinction:

	Board	Session
Lifecycle	Permanent	A single meeting
Scope	Defined once	Inherited from board
Members	Configured centrally	Auto-populated from the board
Agenda	None	The change requests being reviewed in this meeting
Decisions	None	Per-change-request outcomes recorded here

If you find yourself creating a new board for each meeting, you have conflated the two. Create one board, then create sessions against it.

Section 2 — Review Sessions

What a session is

A Review Session is a scheduled meeting bound to exactly one board. It has a date, a chair, a participant list, an agenda, and — once it concludes — a record of what was decided. The session is where change requests are actually reviewed and moved to an outcome.

A session exists only in the context of a board. You cannot create a free-standing session, and you cannot change a session’s board after the fact. If reviewers from the wrong board are needed, the right response is a new session on the right board, not reparenting the existing one.

States

A session moves through five states:

Draft. The session has been created but is not yet on the calendar. The chair is still assembling the agenda or confirming attendance. Not visible as a commitment to reviewers.
Scheduled. A date has been set and the session is published to participants. The agenda can still be adjusted up to the start of the meeting.
InProgress. The meeting is live. Change requests on the agenda are actively being reviewed, and any listed change request is treated as under review for the duration.
Completed. The meeting finished normally. Outcomes for agenda items are final. The session record is preserved as an audit trail.
Cancelled. The meeting was called off. This is distinct from Completed — no decisions were recorded, and any change requests that had moved into review release back to their pre-session status.

Completed and Cancelled are terminal. A session does not return from either to an earlier state.

One live session per board

A board can have at most one session in InProgress at a time. This is an invariant, not a convention — the product enforces it. The reasoning is simple: InProgress means the board’s members are in the room deciding things. Two sessions of the same board running in parallel would mean the same voters are voting on two things at once, which is not a useful concept.

If you need a second meeting with the same committee running at the same time, you either need two boards (different scopes, different reviewer populations) or you need one of the sessions to wait. Usually the first. A board that routinely needs parallel sessions is really two boards.

Different boards can each have their own InProgress session simultaneously. The constraint is per-board, not workspace-wide.

Agenda

A session’s agenda is the list of change requests to be reviewed in that meeting. The chair assembles it — picking which submitted change requests go to which session based on scope, urgency, and the reviewers needed.

The agenda is how a batch of reviews gets committed to a meeting, not how review authority is granted. A board chair can approve or reject a change request without placing it on any session’s agenda — small changes often move asynchronously this way. Sessions and agendas exist for the cases where a committee decision is needed in the room: multiple reviewers in the conversation, a vote recorded, a discussion attached to the decision. See Change Requests — Who can do what for the exact authorization rules.

Pulling an agenda together is the chair’s ongoing work between sessions. The signal that this work is breaking down is a session that starts with a surprise agenda, or a session that starts with no agenda and spends the first thirty minutes picking one.

Participants

When a session is created, its participant list is auto-populated from the board’s composition — the chair, every voting member, every advisory member. Participants can be added or removed on the session itself when a specific meeting needs a guest or needs to skip someone, but the default is “the board, minus the people who said they cannot make it”.

The session’s chair defaults to the board’s chair but can be overridden on the session. This matters when the board’s chair is absent for a given meeting — the session gets its own chair for that one meeting, without changing who chairs the board overall. The session chair cannot be removed from the participant list.

”Under review” is a derived state

There is no “Under Review” status on a change request. Instead, a change request is considered under review while it sits on the agenda of an InProgress session. As soon as the session moves to Completed or Cancelled, or the change request is removed from the agenda, it ceases to be under review.

This means “under review” is computed, not stored, and it is always accurate: a change request cannot be incorrectly stuck in a review state because the board is not actually meeting. See Change Requests for the full set of states a change request moves through and how session decisions feed into them.

Concluding a session

A session ends when its agenda items have been worked through. Each agenda item drives its change request to one of the outcomes the change request model supports — approve, reject, request revision. An item that cannot be decided in this meeting is deferred back to the backlog to be re-agendaed on a later session.

The decisions belong to the change request, not the session. The session records who voted for what and when, but the state that matters downstream — “this change is approved” — lives on the change request itself. See Change Requests for the state transitions that agenda outcomes trigger.

Once every agenda item has an outcome, the session moves to Completed. If the meeting is abandoned for any reason — cancelled last minute, quorum not reached, scope misjudged — the session is Cancelled instead. Cancelling a session that was already InProgress releases the agenda’s change requests: any change request that had moved into review reverts to its submitted status, to be picked up by a later session, so nothing is left stranded in a review state for a meeting that never concluded.

Section 3 — Common modeling mistakes

One giant “All Architecture” board. Every change request is routed to the same committee, which is expected to review everything from a new database engine to a new CRM lifecycle. The committee cannot be expert in all of it, the agenda grows unmanageable, and reviewers disengage. Split the board by scope along the lines of the reviewer populations you actually have — Technology, Data, Application Portfolio — and route each change request to exactly one.
Treating a session as a board. A board is created for every meeting, so “March Data Review” and “April Data Review” are two boards with identical memberships. This breaks the history — you cannot see the trajectory of the Data Architecture Board over time, because the product sees unrelated boards meeting once each. Create one board and hold recurring sessions against it.
Letting agendas go stale. Change requests are submitted and sit in the backlog while the chair does not assemble agendas between sessions. The effect is a queue that grows, authors who never hear back, and sessions that end up rubber-stamping whatever happens to be top of the list. Agenda curation is ongoing work, not a meeting-day activity.
No advisory members. Every board is all-voting. People whose expertise is valued in discussion but who should not carry decision accountability — a security lead, a finance lead, a compliance lead — are either omitted entirely (and consulted informally outside the record) or made voting members (and now jointly accountable for decisions they were only advising on). Use the advisory role for exactly this case.

Governance Overview — how boards and sessions fit the broader governance model
Change Requests — what an agenda item actually is, and the state transitions session decisions drive
Permissions & Roles — who can create a board, who can chair a session, who can vote
Initiatives — the project-management counterpart that change requests often accompany
Entities Overview — the full entity map