/
Hyku Decision Log

Hyku Documentation Wiki Space

Hyku Decision Log

The Hyku Decision Log serves as the source of truth for major community decisions, with a clear record of outcomes and links to relevant documents and discussions. It is maintained by the Product Owner to give the community a shared and reliable reference point

6/30/2026 Decision update: Hyku community priority poll follow-up

Status: In process

Context: The follow-up Hyku priority poll received responses from 12 institutions. Controlled vocabulary work received the strongest support. The results were discussed at the Hyku Interest Group meeting.

Update: The Sustaining Hyku grant team will ask Notch8 for a specification describing what initial buildout of controlled vocabulary improvements can be completed with the available grant funds. The request should prioritize work that is broadly useful to the Hyku community, while recognizing that this would be a foundation for future development rather than a complete solution.

Rationale: The poll results provide enough community signal to justify exploring controlled vocabulary work as the next investment. A specification from Notch8 will clarify what can realistically be built within the available funding and whether that work would provide broad community value.

Next step: Review the Notch8 specification when received. After review, the Sustaining Hyku grant team will either approve the controlled vocabulary work or contribute the funds toward the already identified broad community need in the third phase of Bulkrax work.

6/2/2026 Decision to be made: How should Hyku run the next stage of community priority-setting for future development work?

Status: In process

Context: As part of the final IMLS grant work, Hyku is testing a process for identifying future development priorities. The initial priority poll received 11 responses, though 21 people attended the meeting where results were discussed, and some responses came from multiple people at the same institution. The leading priorities at this stage were authority control vocabulary improvements, bulk import improvements, and export/import of tenant configurations. Bulkrax and aliases work were noted as connected to work already underway.

Current direction: Run a narrower follow-up poll focused only on the highest-ranked possibilities from the initial poll. To avoid over-weighting institutions with multiple respondents, collect one response per institution. Limit participation to current Samvera users or institutions actively working toward adoption.

Rationale: The first poll gave useful directional information, but the response count was low and unevenly distributed. A narrower follow-up poll would test whether the leading priorities hold when the community is asked to choose among the strongest candidates. Limiting to one response per institution makes the result more representative of institutional priorities rather than meeting attendance or Slack visibility.

Next step: Nic Don will draft and distribute a follow-up poll with only the highest-ranked options, clear eligibility language, and one submitted response per institution.

5/7/2026 Controlled Vocabulary Validation for Backend Ingests

Decision: Add server-side validation for local controlled vocabulary terms (via Questioning Authority lookups), gated behind a per-tenant Feature Flipper flag (opt-in). Future work will enable per-field configuration allowing both controlled and non-controlled versions of a field.

Date: May 6, 2026 (Samvera Tech Call)

Who: Samvera Tech Call attendees, with Tech Lead, Hyrax and Hyku Product Owners

Why: The only existing defense against invalid controlled vocabulary data is the frontend dropdown on deposit forms. Backend ingest paths — Bulkrax imports, API ingests, and any direct interaction with the backend — can bypass this and insert arbitrary values into CV fields. In current releases this can cause errors when works with invalid CV content are displayed. The UI and backend should enforce the same rules; deviations from controlled vocabularies should be managed through configuration, not through the accident of which ingest path was used.

Follow-up:

  • Future work to move CV validation control into the M3 profile (e.g., a controlled_values.validate: true/false key per property), which would allow per-field granularity rather than a tenant-wide toggle.

  • Future work to support both controlled and non-controlled versions of a field for cases where administrators want a suggested vocabulary (dropdown populated from a CV source) without strict enforcement.

  • A script should be made available to correct past entries where non-conforming terms were used in Controlled fields, moving the content to a non-CV field (e.g., Rights Statement to Rights Notes or Additional Rights Information)

References: