Why published years are read-only

Why published years are read-only

When a catalog year reaches the published state, Kenii stops accepting edits to the
programs, credentials, courses, and policies that belong to it. An attempt to save a
change to an item in a published year is refused, and the system returns a message
explaining that the year is published and locked. This can feel surprising the first
time it happens, especially to staff used to content management systems where
anything is editable at any time. This article explains the reasoning behind the
lock, what exactly it prevents, and where the deliberate escape hatch sits.

The scope here is the rationale and the boundary of the read-only rule. It does not
cover how to unlock a year or how to make a correction to a past edition; those are
tasks with their own procedures, referenced at the end.

A catalog is a promise, not just content

The reason a published catalog is treated differently from ordinary web content is
that it is not really content in the marketing sense. A college catalog is a
statement of what the institution offered and required during a defined period. It
tells a student who enrolled under the 2024 edition which courses satisfied their
degree, how many credits they needed, and what the institution committed to provide.
That statement carries weight long after the year ends. Accreditors examine it,
students rely on it under catalog rights that often let them graduate under the
edition they entered, and disputes about “what the catalog said” are settled by
reading the edition that was in effect at the time.

If a published edition could be quietly edited after the fact, that record would
lose its meaning. A course requirement changed today would rewrite history for every
student who enrolled believing the old requirement applied. The point of locking a
published year is to preserve the integrity of the edition as it stood: to guarantee
that “the 2024 catalog” means the same thing next year that it means today. The lock
is less a restriction on staff than a protection of a commitment the institution
already made.

This is why the behavior is enforced by the system rather than left to policy and
good intentions. A written rule that says “do not edit last year’s catalog” depends
on everyone remembering it and no automated process overstepping it. A lock in the
software makes the guarantee structural, so the record’s integrity does not rest on
vigilance.

What the lock actually checks

The rule is narrower and more considered than “old years cannot change.” When a save
is attempted, Kenii looks at the catalog year the item belongs to and asks a short
series of questions, and a change is allowed if any one of them says yes.

An item is editable if the site has no active catalog year configured at all, which
keeps a freshly set up or single-edition site fully open. It is editable if the item
carries no catalog year, since there is no edition to protect. It is editable if its
year is the active edition, because the institution must always be able to maintain
the catalog it is currently operating under. It is editable if its year is still a
draft, since a draft is a workspace that was never public. And it is editable if the
year has been explicitly unlocked, which is the intentional exception described
below. Only when none of these hold, meaning the item lives in a genuinely published,
locked edition, is the save refused.

The refusal itself is a clean, deliberate stop rather than a silent failure. The
system returns a permission error and a message stating that the year is published
and locked and pointing toward where it can be unlocked. That specificity matters:
the aim is to protect the record while making the reason obvious, so that staff
understand they have hit a safeguard, not a bug.

It is worth noting what the lock does not do. It does not hide the year or take it
offline; a published year is still fully public and readable, and locking is about
editing, not visibility. That separation between visibility and editability is the
same one that runs through the whole
catalog year lifecycle: published means public and
closed to edits, which is a different combination from offline (private and closed)
or active (public and open).

The unlock exception, and why it is the exception

Real catalogs sometimes need correcting after publication. A typo in a course
description, a phone number that changed, a genuine error that predates publication:
these are legitimate reasons to touch a past edition. Kenii accommodates them not by
weakening the lock but by making the unlock an explicit, per-year act. A published
year can be marked as unlocked, and while it is, its items become editable again as
if the lock were lifted for that edition alone.

The design choice here is that unlocking is deliberate and visible rather than
automatic. The default state of a published year is locked, and returning to an
editable state is something a person does on purpose, for a known reason, and can
undo afterward. This keeps the common case safe (a past edition stays frozen) while
leaving a clear, auditable path for the uncommon case. An alternative design would
have been to allow edits freely but track a change history instead, letting anyone
revise a past year on the understanding that the revisions are logged. That approach
trades prevention for accountability. Kenii leans the other way, toward prevention,
on the view that for a document with accreditation weight it is better to make an
after-the-fact change a conscious step than to make it easy and merely record that
it happened. Reasonable institutions could prefer the other balance; this is the
position the product takes.

Because unlocking is meant to be temporary, the natural discipline around it is to
unlock, make the specific correction, and lock again, rather than leaving an old
edition open. The lock is the resting state precisely so that a past catalog is
trustworthy by default.

Related reading

• About the catalog year lifecycle sets out the four
  states a year passes through; the read-only rule described here is the editability
  half of the published state.
• The roles and capabilities reference
  describes who can manage the catalog, which is the access layer that sits alongside
  the year lock.
• The settings reference documents the active catalog
  year option that the lock check reads when deciding whether an edit is allowed.