verifywise-ai/verifywise

Summary There is no dedicated intended use / purpose field on a model. The intended purpose of an AI model/solution is a standard governance data point (it frames how the model should and shouldn't be used), but today it can only be squeezed into free-text capabilities / limitations or the use-case goal/description, none of which is a distinctly-labeled "intended purpose" field. Current state model_inventories (Servers/domain.layer/models/modelInventory/modelInventory.model.ts) has capabilities, limitations, biases (all STRING) but no intended-use/purpose field. projects (use case) has goal and description (both required STRING) — general-purpose text, not a labeled intended-purpose statement. Proposed change Add a nullable intended_use TEXT column, following the established add-column pattern: Migration: ALTER TABLE verifywise.model_inventories ADD COLUMN intended_use TEXT; (multi-tenant verifywise. prefix per existing convention). Model: @Column({ type: DataType.TEXT, allowNull:

Summary AI incident status only supports the linear lifecycle Open → Investigating → Mitigated → Closed. There's no way to express that a system has been suspended or that an emergency action is in effect while an incident is active. Adding these states lets responders reflect real containment actions on the incident record. Current state AIIncidentManagementStatus (Servers/domain.layer/enums/ai-incident-management.enum.ts): export enum AIIncidentManagementStatus { OPEN = "Open", INVESTIGATING = "Investigating", MITIGATED = "Mitigated", CLOSED = "Closed", } The backing column is a plain VARCHAR(20) on ai_incident_managements (status VARCHAR(20) DEFAULT 'Open', migration 20260226234302-tenant-tables.js) — not a Postgres enum type. So new values do not require an ALTER TYPE migration. Proposed change Add value(s) to the TS enum, e.g.: SUSPENDED = "Suspended", EMERGENCY_ACTION = "Emergency action", (Exact wording/set open to discussion.) Update the incident status dropdow

Summary The model inventory has no field describing the architecture / solution type of a registered model or solution — e.g. traditional ML, GenAI, RAG, or Agentic AI. This classification is a common governance need: it drives how a model is reviewed and which controls/assessments are relevant, and it's a natural filter/grouping dimension in the inventory. Current state model_inventories (Servers/domain.layer/models/modelInventory/modelInventory.model.ts) has no type, category, model_type, or equivalent column. Confirmed columns today: id, provider_model, provider, model, version, approver, capabilities, security_assessment, status, status_date, reference_link, biases, limitations, hosting_provider, security_assessment_data, is_demo, external_key, mrm_tier, mrm_materiality_drivers, mrm_tiered_at, mrm_tiered_by, mrm_revalidation_flagged, mrm_revalidation_flagged_at, mrm_revalidation_reason, created_at, updated_at. Proposed change New enum, following the one-file-per-enum convention

Summary Model inventory tracks a model's operational status but has no terminal Retired state. A model that has been decommissioned / taken out of service can only be marked Restricted, Blocked, or Rejected — none of which correctly express "this model has reached end-of-life and is retired." Adding a Retired status closes the model lifecycle (initiation → operation → retirement). Current state ModelInventoryStatus today (Servers/domain.layer/enums/model-inventory-status.enum.ts): export enum ModelInventoryStatus { APPROVED = "Approved", RESTRICTED = "Restricted", PENDING = "Pending", BLOCKED = "Blocked", REJECTED = "Rejected", } The status column on model_inventories uses the Postgres enum type verifywise.enum_model_inventories_status (created in migration 20260226234300-base-enums-and-roles.js), defaulting to Pending. Proposed change Add RETIRED = "Retired" to ModelInventoryStatus. New migration to extend the DB enum: ALTER TYPE verifywise.enum_model_inventories_stat

What happened? Check deployment documentation for any gaps. Deployment should be fully repeatable and executable end-to-end without blockers or undocumented manual steps. Sub-tasks Go over deployment phases — Reproduce the deployment from scratch, validate the build, CI/CD pipeline, environment variables, infra dependencies, and post-deploy verification. Check deployment documentation — Compare documented steps vs actual steps, update the deployment guide, and remove anything outdated or missing. Definition of Done Deployment runs end-to-end without blockers Documentation matches the actual flow Verified in a clean environment