When Every Site Chooses “Other”: Govern Exception Codes Before You Compare the Portfolio

By Jared Mastroianni

• October 26, 2026
• 10
• Business Storage, Guides, Self Storage

Portfolio metrics become useful only after the operating team agrees on what each category means, where it applies and what evidence supports it. Editorial image; source metadata and non-documentary-use limits are recorded in the package.

A portfolio report shows that one facility logged 42 access exceptions last month. Another logged nine. A third logged none.

The easy conclusion is that the first property has a problem. The harder and more useful question is whether the three sites classified the same conditions the same way.

At one site, “access exception” may mean a gate controller was unavailable. At another, it may include a customer entering the wrong code. A third manager may record only events that required a vendor visit. If each system also offers an “Other” option, the report can look precise while hiding several incompatible definitions.

This is not a dashboard problem. It is a reason-code governance problem.

Before comparing facilities, the operating team needs a controlled definition for each portfolio concept, a versioned mapping from local codes, an evidence rule and a place to put records that do not map cleanly. The purpose is not to force every property into identical language. It is to make the differences visible enough that a comparison can be defended.

A label is not a definition

Two systems can display “Gate issue” and mean different things. One may use it for physical gate-equipment failure. Another may use it for any unsuccessful access attempt, including a customer authorization state that worked exactly as configured.

The reverse is also true. “Controller offline,” “access hardware unavailable” and “gate communications lost” may describe the same portfolio concept, depending on the local definitions and evidence.

Comparability therefore starts with a stable concept identifier, not the wording shown to a manager. Each portfolio code should have:

• a unique identifier;
• one preferred label;
• a plain-language definition;
• explicit inclusion and exclusion rules;
• required supporting evidence;
• a semantic owner who controls meaning;
• an operational owner who controls use;
• a version and effective period;
• a parent category, if hierarchy is useful; and
• separate fields for severity, suspected cause, customer state and outcome.

Those last separations matter. “High priority” is not a reason. “Power outage” may be a suspected cause rather than an observed condition. “Resolved on site” is an outcome. “Delinquent account” is a customer authorization state. If they all compete in one reason-code field, the portfolio loses the ability to distinguish what happened from why it may have happened and how it ended.

Preserve local language without surrendering portfolio meaning

A central taxonomy does not require every site to abandon the terms its team understands. Preserve the local code and label exactly as recorded. Then map that local record to a governed portfolio concept.

The mapping should state the relationship:

• Exact: The local definition and the portfolio definition match within the approved scope.
• Narrower: The local code describes a more specific case inside the portfolio concept.
• Broader: The local code includes cases outside the portfolio concept and cannot be counted without another filter.
• Related only: The concepts are associated but are not interchangeable.
• Ambiguous: The local label or definition supports more than one interpretation.
• Unmapped: No approved portfolio concept applies.

Do not turn broader, related, ambiguous or unmapped into exact because the dashboard needs a number. That decision creates false comparability.

The World Wide Web Consortium’s SKOS model is useful here as a design reference. It separates preferred and alternative labels, supports broader and narrower relationships, and distinguishes mapping relationships such as exact, close, broad and narrow matches. An operator does not need to implement RDF or publish a formal semantic-web vocabulary to use the lesson: labels, concepts, hierarchies and mappings are different objects.

“Other” is a queue, not a category

“Other” is sometimes necessary at the point of entry. A manager should not be forced to select a false reason just to close a form. But the portfolio should treat “Other” as a controlled exception state that requires review.

Every “Other” record should capture a short factual description, the source event, the person or system that classified it, and the review owner. The review can then produce one of four outcomes:

1. map the record to an existing code;
2. correct the source selection because the wrong code was used;
3. propose a new or revised code through change control; or
4. retain it as unmapped with a documented reason.

Set an operating threshold for review, not an invented industry benchmark. For example, the portfolio may choose to review when a facility’s “Other” share exceeds its approved internal limit or when the same free-text description repeats. That threshold is a management control, not proof that the facility is performing poorly.

An “Other” rate can reveal a weak code set, poor training, a recent system change or genuinely novel work. It does not identify the cause by itself.

Version the meaning, not just the menu

Reason codes change. A broad “Access problem” option may be replaced by separate equipment, communications and authorization concepts. A code may be retired because managers applied it inconsistently. A vendor migration may introduce new local labels.

Each change needs an effective date, a version identifier, a change note and a historical-treatment decision. The W3C Data Catalog Vocabulary, version 3, provides a general reference pattern for version identifiers, previous and current versions, version notes and resource status. It is designed for data catalogs, not self-storage reason-code governance, but the versioning principle transfers cleanly.

Do not overwrite the old definition in place and pretend the meaning was always the same. Preserve the old version. Identify its replacement. State whether old records remain under the original definition, can be mechanically remapped, require sampled review or must be excluded from trend comparison.

Historical restatement is a separate decision. A new mapping may improve future comparability without authorizing anyone to rewrite prior reports. Record who can approve a backfill, which periods are affected and how the revised series will be labeled.

Put three owners around every change

Reason-code governance often fails because one person owns the dropdown but no one owns the meaning.

Use three named responsibilities:

• Semantic owner: Defines the concept, boundaries, relationships and version changes.
• Operational owner: Confirms that the code can be applied consistently in the facility workflow and that the evidence is practical.
• Reporting owner: Controls when the mapped data becomes eligible for comparison and how changes affect dashboards and historical series.

One person may hold more than one role in a small organization, but the decisions should remain distinct. Editing a menu is not the same as approving a portfolio definition. Approving a definition is not the same as releasing a revised trend line.

The NIST Cybersecurity Framework 2.0 is not a taxonomy standard for self-storage. Its governance and improvement outcomes do, however, reinforce a general control principle: roles, responsibilities, authorities, policies and improvement activity should be established and communicated. Here, that means every code change has an owner, an approval path and a review cycle.

A fictional portfolio example

The following portfolio, facilities, systems, codes, records and outcomes are fictional teaching material.

Fictional Northline Storage Group receives three local labels from three properties:

• Pine Cross uses GATE-ISSUE for both gate-equipment unavailability and customer authorization denials.
• Mill Yard uses CTRL-OFFLINE only when a controller-health source reports the device unavailable.
• Harbor Annex uses OTHER with free text reading “code would not work.”

The portfolio team does not map all three to FACILITY_ACCESS_DEVICE_UNAVAILABLE.

Mill Yard’s definition is narrower and has the required equipment-state evidence, so the mapping is approved as exact for portfolio reporting. Pine Cross’s code is broader because it mixes an equipment condition with customer authorization. It is marked broader — not comparison eligible until the local workflow separates those cases or another governed field can distinguish them. Harbor Annex remains ambiguous — review required because the free text does not establish whether the device was unavailable, the credential was entered incorrectly or the customer was not authorized.

The dashboard counts only the Mill Yard record in the equipment-unavailability measure. Pine Cross and Harbor Annex remain visible in the mapping-quality queue. No facility is scored as better or worse from these three rows.

This is slower than forcing all three records into one bucket. It is also honest.

Use the register as a release gate

The accompanying Portfolio Exception-Code Definition, Mapping and Retirement Register gives the team one place to manage concepts, local mappings, change decisions and historical treatment.

Before a code enters a cross-facility report, confirm:

1. the portfolio definition is active for the reporting period;
2. the local definition and version are known;
3. the mapping relationship is approved;
4. required evidence exists;
5. severity, cause, customer state and outcome are not being smuggled into the reason field;
6. ambiguous and unmapped records remain outside the comparable count; and
7. any historical change has an explicit backfill or no-restatement decision.

Then monitor mapping quality alongside the operating metric. Report the share of records that are exact, narrower with an approved roll-up, ambiguous, unmapped and “Other.” A portfolio total without mapping coverage tells leadership less than it appears to.

Comparable data starts before the chart

The most dangerous reporting errors are not always arithmetic. They are semantic: the numbers add correctly, but the rows do not mean the same thing.

A governed reason-code system prevents that error by keeping local evidence, portfolio meaning, mapping confidence and version history together. It gives managers a safe “unknown” path instead of rewarding guesses. It also gives reporting teams a clear rule for what may enter a comparison.

If every site chooses “Other,” the answer is not to delete the option. The answer is to inspect what the portfolio has failed to define.

Sources

• SKOS Simple Knowledge Organization System Reference, World Wide Web Consortium.
• Data Catalog Vocabulary (DCAT) — Version 3, World Wide Web Consortium.
• The NIST Cybersecurity Framework (CSF) 2.0, National Institute of Standards and Technology.

Disclosure

Northline Storage Group, Pine Cross, Mill Yard, Harbor Annex and every code, system, record, definition, owner, threshold and outcome in the article and dataset are fictional. The article proposes an operating method. It does not claim an industry standard, customer deployment, software feature, measured performance result, certification, legal conclusion or compliance outcome.