Let the model propose a concept before it governs one

A document mentions “release,” and the extractor adds a new concept to the knowledge base. Another document uses the same word for a software version. A third describes releasing a room booking. If every extracted noun becomes an accepted concept, the application will gradually acquire a vocabulary whose apparent precision conceals several unrelated meanings.

The proposed audio-to-knowledge architecture separates a concept candidate from a governed concept. A candidate records something worth considering. A governed concept has an established identity and a defined place in the application’s vocabulary. That separation creates room to inspect the proposal before later searches and automated actions depend on it.

Governance does not require a large committee. For a personal collection, one person may make the decision. The essential requirement is that a proposed interpretation remain visibly provisional until someone, or an explicitly authorized validation procedure, applies the rules for accepting it.

What the candidate should contain

Preserve the extracted label with the source passage that produced it. Include the relevant domain and the surrounding context, because the same word can carry different meanings in different collections. Record any suggested existing match without silently merging the candidate into that concept.

The model can propose a definition and possible relationships, but those suggestions need evidence or an explicit designation as interpretation so that a reviewer can distinguish recorded usage from a suggested way of organizing the collection. A fluent definition is not proof that a community uses the term in that way, and a broad relationship such as “related to” should not substitute for deciding whether the intended relation is membership, dependency, or simple co-occurrence.

A governed concept needs a stable identifier independent of its preferred label. Labels change. A spelling correction or a clearer display name should not sever every relationship that points to the concept. Preserve aliases and scope notes so that an older term can still help a reader find the accepted meaning, even after the preferred label changes and the vocabulary begins to reflect decisions made by different reviewers.

An illustrative review queue

Imagine a hypothetical archive for a small performance venue. An extractor proposes “release” from a rehearsal schedule, a software maintenance note, and a booking email. The reviewer opens each supporting passage. The booking email concerns giving up a reservation; the maintenance note concerns a software version. The rehearsal passage remains ambiguous.

The reviewer accepts two separate concepts with clear scope notes and leaves the rehearsal candidate unresolved. Each accepted concept retains its own identifier. The unresolved candidate remains searchable as source language without being presented as an established category. No success rate or completed deployment is implied by this example.

Later, someone renames the booking concept to “reservation cancellation” for clarity. Its identifier stays the same, and “release” becomes an alias within the relevant scope. Searching that word may still return both concepts, but the interface now gives the reader enough context to choose deliberately.

Test a merge as carefully as a creation. Two labels may describe the same concept, but similar wording alone is insufficient evidence. Preserve both original identities in the merge history, record the decision, and check dependent claims before redirecting references. A mistaken merge can change the meaning of many records at once.

Validation and judgment do different work

A mechanical validator can reject a missing identifier, an invalid relationship type, or a reference to a nonexistent concept. It can check whether required evidence exists and whether a proposed hierarchy contains a prohibited cycle. These checks are valuable because they are repeatable and inexpensive to inspect.

The same validator cannot establish that a category is useful for a particular reader merely because its structure is valid. That question requires a task. Can the venue coordinator distinguish reservation changes from software changes? Can a new volunteer find the procedure under the terms they actually use? An accepted vocabulary needs testing against those questions as well.

Record why a candidate was rejected or deferred. Otherwise, the next extraction run may present the same proposal as new work, and the reviewer will repeatedly solve the same ambiguity. A rejected candidate can still preserve useful language from a source without entering the governed vocabulary.

Start with a small review queue containing synonyms, ambiguous labels, and deliberately misleading near-matches. Verify that accepted concepts receive stable identities, deferred candidates remain provisional, and rejected proposals do not return unchanged on every import. Then rename one accepted concept and inspect its dependent claims before allowing automatic promotion under broader rules.

Source notes

Based on the proposed audio-to-knowledge architecture and the public essay “An AI Still Needs to Know What You Mean.” The venue archive is illustrative.