Why proposals stay isolated until approval

Why proposals stay isolated until approval

This article explains why a curriculum change in Kenii lives as a self-contained
proposal, entirely separate from the published catalog, and why nothing that a
committee is still debating ever appears in the catalog a student reads. It is
about the reasoning behind that separation and the mechanics that enforce it. It
does not cover how to create or route a proposal; the how-to guides handle those
tasks, and the workflow itself is described in the reference material.

The problem the separation solves

A community-college catalog carries weight that an ordinary web page does not.
Students plan a degree against it, advisors quote it, and accreditors and state
agencies treat the published year as a record of what the institution actually
offered. If a half-finished revision could leak into that record, the catalog
would stop being trustworthy. A dean reviewing a proposed course change needs to
know that the change is not live yet, and a student reading the catalog needs to
know that everything in it has already been decided.

The tension is that curriculum work is slow and deliberative. A single course
revision might sit in review for weeks, move between a department, a curriculum
committee, and a dean, and change several times before anyone approves it.
Something has to hold that in-progress work somewhere it can be edited, argued
over, and even abandoned, without ever touching the catalog. In Kenii that
somewhere is the proposal.

A proposal is a separate object, not a draft of a course

A proposal is its own record type, distinct from the course records that make up
the catalog. When someone drafts a new course, a revision, or a discontinuation,
the details go into the proposal’s own stored payload. They are not written onto
a course. This is the heart of the isolation: the catalog’s course records and
the proposals that want to change them are different kinds of thing, kept in
different places, and the front end that students see reads only the former.

This is a deliberate choice, and it is worth naming the alternative. Some systems
model a pending change as a draft revision of the live record itself, the way a
word processor tracks changes inside one document. That approach keeps everything
in one place, which is appealing, but it means the live record now carries
unapproved content, and every part of the system that reads it has to remember to
filter that content out. Kenii takes the opposite position: the live record stays
clean, and the unapproved work lives elsewhere until a decision is made. The cost
is that the change has to be copied into the catalog at the end. The benefit is
that the published catalog can never accidentally show a draft, because a draft is
not stored there in the first place.

Because the proposal is a separate object, it can also carry things a course
record has no place for: a rationale, a review history, committee votes, reviewer
comments, and the decision trail. These belong to the act of changing the
curriculum, not to the course, and keeping them on the proposal is what lets the
proposal double as a governance record.

Editing is only possible while the proposal is a draft

A proposal moves through a small set of states. It begins as a draft. When it is
submitted it enters review, where it may be advanced, returned, or placed on hold
and later resumed. When it clears the last step it becomes approved. Only at that
final point does anything reach the catalog.

The draft state is the only one in which the proposal’s content can change. Once a
proposal has been submitted, the system refuses to edit it, and it refuses to
delete a proposal that has left draft or that has recorded votes, on the grounds
that a submitted proposal is part of the governance record. This is why the
isolation runs in both directions. The catalog is protected from the proposal
while the proposal is being decided, and the record of the decision is protected
from quiet after-the-fact editing once it has begun.

Submitting freezes a snapshot of what is being reviewed

Something subtle happens at the moment of submission that reinforces the
isolation. The proposal captures a snapshot. For a revision or a discontinuation,
Kenii records a copy of the target course’s fields as they stand at submission,
so the redline the committee reviews compares the proposal against the course as
it was when review began, not against a course that some unrelated edit might
change underneath them. At the same time, the proposal resolves and freezes its
route: the ordered list of review steps drawn from the active workflow, stored on
the proposal itself. Even if an administrator later revises the workflow, an
in-flight proposal keeps following the path it was given when it was submitted.

The effect is that a proposal under review is sealed off from moving parts on both
sides. The catalog cannot leak into it, because it is reviewing a snapshot. And a
later change to the institution’s workflow cannot silently reroute it, because it
carries its own route. Reviewers are always looking at a stable thing.

Approval is the single moment a change enters the catalog

Nothing writes to the catalog until the proposal has passed every step of its
route and reached the approved state. That final approval, and only that, triggers
what Kenii calls materialization: the point where the decided change is written
into a catalog year as a real course record. A proposal that is still in review,
on hold, or returned to its author has written nothing. There is no partial
state in which some of the change is live and the rest is pending.

How the change lands depends on the state of the catalog year it targets, and this
is where the “never a draft” promise is most visible.

• If the target year is still a working year (a draft or the active year being
  built), the approved proposal writes directly into it: a new course is created,
  a revision updates the year’s copy of the course, a discontinuation removes it.
• If the target year has already been published, Kenii does not rewrite the
  published record in place. Instead it records the change as an addendum attached
  to that year. A published catalog is a fixed historical record, and the addendum
  model lets an institution acknowledge a mid-year change without editing the
  document students were already given.
• If the target year is offline, nothing is written at all, and the proposal
  reports why.

This branching is the reason a proposal cannot quietly overwrite a live catalog.
The published year is treated as immutable; the only way to change it after the
fact is an addition that is visible as an addition. The relationship between these
year states and what “published” means for the front end is the subject of the
catalog-year lifecycle explanation, which is worth reading alongside this one if
the addendum behavior is what matters to you.

Materialization also records that it happened. Once a proposal has been
materialized it is stamped, and asking it to materialize again returns the record
of the write that already occurred rather than performing it a second time. The
one-way door from proposal to catalog is meant to be crossed exactly once.

Where judgment still lives

It would be a misreading to conclude that the isolation makes the process
automatic. The separation is about protecting the catalog, not about removing
people from the decision. Every advance through the route is a human action by an
assigned reviewer or a committee vote, and the validation rules an institution
sets can block a submission before it ever enters review. The system also flags
proposals that may amount to a substantive change under accreditor rules, but that
flag informs the committee rather than deciding anything; see
About substantive change flagging for how
that judgment is supported and left in human hands. The isolation guarantees only
that the catalog reflects decisions, never deliberations.

Scope and boundaries

This explanation is limited to why proposals are kept apart from the catalog and
how that separation is enforced up to the moment of approval. It does not describe
the shape of the review workflow, the committee-voting rules, or the exact fields
a proposal carries; those live in the reference material, including the
REST API reference and the
post types and taxonomies reference.
The steps for drafting, submitting, and materializing a proposal belong to the
curriculum how-to guides.