Custom Program is a parent Program for assessment methods that an organization defines. A Custom Library is one reusable standard inside that Program. This distinction matters: Custom Program provides the common project and finding workflow, while each Custom Library supplies the requirement set that gives a particular method its structure.
Canonical data model
- Custom Program: the fixed parent Program for organization-defined methods.
- Custom Library: an organization-owned library with a name, purpose, finding prefix, workflow options, fields, and canonical standard references.
- Standard definition: the record that identifies the method represented by the library.
- Standard version: the current version boundary used to connect the library to its requirements.
- Standard requirement: a stable ID, title, description, order, and internal key for one assessable rule.
- Requirement mapping: the canonical connection that makes the requirement available to projects, findings, defaults, imports, coverage, and reports.
- Default finding: optional reusable Summary, Description, and Remediation language associated with one standard requirement.
- Project: an independent assessment with its own scope, owner, dates, findings, evidence, comments, history, table settings, and export snapshots.
Admin-first authoring boundary
Custom Libraries are created and edited only in Admin under Default Findings Engine. Project creation does not author standards. The New Project form only selects an existing, available Custom Library. This boundary prevents an accidental project setup from creating a second standard with similar labels, and it gives team leaders one place to govern requirement identity and reusable defaults.
Creation sequence
- A team leader or Team admin opens Admin.
- The user chooses + New Custom Library in the Custom Program section.
- The client validates the name, prefix, requirement IDs, titles, descriptions, and duplicate references beside the relevant field.
- The server verifies the authenticated user, organization role, plan capacity, payload limits, and required universal finding fields.
- voiqq creates the standard, standard version, organization library, workflow options, universal fields, requirement options, canonical requirements, version requirements, and library mappings.
- The library becomes available in Admin, Libraries, imports, and the Custom Program New Project selector.
- Reusable default findings can then be added requirement by requirement.
Requirement identity and editing
The visible Standard ID is not merely a label. It connects defaults and finding mappings to the intended rule. Editing a title or description preserves that relationship when the meaning remains the same. A materially different obligation should receive a new requirement. When a requirement is removed from the editor, voiqq archives its selectable option and excludes its current library mapping instead of rewriting historical findings.
Local default findings
The Default Findings Engine resolves Custom Library requirements through the same canonical requirement model used by system libraries. Team leaders and Team admins can add local Summary, Description, Remediation, and Severity starting points. Status and Validation begin as Open and Pending. These defaults remain local to the workspace and do not become platform-wide defaults. Using one creates an ordinary editable project finding; it never records an observation automatically.
Fields and table presentation
Every Custom Library receives the universal voiqq finding fields required for assignment, status, validation, evidence, history, reporting, and import normalization. The custom requirement field carries the library's standard mappings. Edit Table controls project-level labels, order, widths, and Compact or Full visibility. Those presentation changes do not rename the global import mapper or alter another project. Additional imported columns remain project data under Additional Details when no standard mapping is reliable.
Project creation and reports
A Custom Program project stores the selected Custom Library and its canonical requirement IDs. Findings can then be mapped to those requirements, assigned, discussed, validated, and included in the shared professional report engine. Coverage is calculated from the saved requirement mappings and project findings. The report remains a reviewed project snapshot and does not claim certification unless the organization's method and professional conclusion independently support that claim.
Spreadsheet normalization
The import engine keeps an original-grid snapshot and creates normalized voiqq records. The selected Custom Library supplies the valid target requirements and standard fields. Header aliases and representative row values inform mapping. Uncertain values are left for review, and unmatched source columns remain Additional Details. This prevents an unfamiliar column from being forced into an unrelated field simply to fill the table.
Permissions and plan limits
Custom Libraries belong to one organization. Team leaders and Team admins manage them under existing workspace permissions. The plan limit counts non-sample Custom Libraries. On downgrade, the oldest libraries within the new limit remain enabled; newer over-limit libraries remain stored but cannot be selected or edited until the plan supports them. Project access, findings, and historical exports are not deleted. Public project links expose only the selected project's configured View only, Commenter, or Editor permission and never expose library administration.
Governance checklist
- Record who owns the method and when its requirements were last reviewed.
- Use stable IDs and add a new requirement when meaning changes materially.
- Keep requirement descriptions focused on what should be assessed, not a current test result.
- Use default findings only for reusable issue patterns and require project-specific review.
- Review spreadsheet mappings and preserve unmatched source data.
- Restrict library administration to accountable workspace roles.
- Review every report for scope, evidence, limitations, and professional claims.
Custom Program is voiqq's flexible parent program. Your organization creates a Custom Library inside it, defines its durable standard requirements, and then reuses that library for separate projects. A requirement describes what the team assesses; a default finding is optional reusable drafting help; an actual finding remains project-specific.