The authoring flow accepts requirements, bug reports, and change requests as governed inputs that update the managed application model over time.
Governance Control Catalog
Governed change from request to promoted output
Keewo controls how requirements, bug reports, and change requests become generated applications. The public control story is simple: review the model, materialize output, collect quality evidence, require human approval, promote the baseline, and keep provenance.
Platform Capabilities
What the governance layer does today
These capabilities are built into the current platform and enforced across every governed delivery path.
Provenance records connect generated output to governed source material, approval state, and outcome.
Sample internal operations applications exercise workflows, boards, dashboards, business rules, reporting, integration surfaces, and controlled evolution.
Managed Project Governance
The public lifecycle
Each governed change follows a reviewable lifecycle before it can become the promoted baseline.
01
Status and diff
Review what changed in the managed model before approval.
02
Quality evidence
Validate the change with checks for model correctness, business rules, workflow behavior, migration safety, tests, and release readiness.
03
Prepare approval
Package the reviewed change and its evidence for a human approval decision.
04
Promote and hand off
Promote the accepted baseline and hand it off to source control with provenance.
AI-Assisted Draft Guardrails
Controls that constrain AI-assisted drafts
AI participates in one bounded step: drafting a structured plan. The plan must preserve required model coverage and reviewability before it can become governed source material.
AI-assisted entity fields must meet a required overlap threshold with the deterministic baseline. Prevents unsupported entity structures or removal of required fields.
Enforcement: draft validation
Field identifiers are normalized and checked before acceptance. Prevents descriptive words from becoming invalid identifiers.
Enforcement: draft validation
AI drafts cannot remove required language locales. Prevents the AI from dropping internationalization support during draft enhancement.
Enforcement: draft validation
Dashboard and widget contribution IDs are deduplicated against existing contributions. Prevents duplicate or conflicting contribution registrations.
Enforcement: draft validation
Dashboard card structure is compared with expected semantic cards. Prevents draft changes from producing misleading operational metrics.
Enforcement: draft validation
Cross-module navigation and interoperability functions defined in the baseline cannot be removed by the AI draft. Prevents loss of existing cross-module integrations.
Enforcement: draft validation
List function inputs (filters, sort fields, paging) defined in the baseline are preserved. Prevents the AI from simplifying list behavior below the required level.
Enforcement: draft validation
The AI-produced plan must conform to the ContractDraftPlan JSON schema. Prevents malformed or structurally invalid AI output from entering the pipeline.
Enforcement: draft validation
Pattern Contract Rules
Structural constraints per application pattern
Each of the 16 application patterns defines required paths, types, and conditions that specs must satisfy. Specs violating pattern rules are rejected before generation.
Requires list outputs, filter actions, toolbar configuration, and entity CRUD operations with proper field type declarations.
Enforcement: spec validation
Extends CRUD Standard with popup or drawer container configuration, including create-after behavior and host/target wiring.
Enforcement: spec validation
Requires state machine definition with named transitions, permitted status flows, and status-driven UI filtering.
Enforcement: spec validation
Requires column definitions, card field mappings, drag-drop status transitions, and board-specific data queries.
Enforcement: spec validation
Requires date field mappings, view configurations, event rendering rules, and calendar-specific data queries.
Enforcement: spec validation
Requires widget host configuration, contribution slots, card layout definitions, and metric data sources.
Enforcement: spec validation
Requires data aggregation queries, output column definitions, filter parameters, and export format configuration.
Enforcement: spec validation
Requires navigation structure with route declarations, menu hierarchy, and integration points for contributed content.
Enforcement: spec validation
Composition Validation
Cross-module integrity checks
When multiple feature packs compose into an application, these controls validate the integration points.
No two packs may register the same route path. Prevents runtime routing conflicts in the generated application.
Enforcement: composition validation
Every cross-module anchor contribution must reference an anchor that exists in the target pack. Prevents broken navigation and widget integration.
Enforcement: composition validation
Packs declaring shell integration must reference a valid shell module and widget. Prevents orphaned navigation entries.
Enforcement: composition validation
Widget host and contributor declarations must have matching interfaces. Prevents runtime widget rendering failures.
Enforcement: composition validation
Certification Scenarios
Scenario-based testing for generated code
Certification packs validate generated modules against representative scenarios. One test per category scales linearly with module count.
Validates that the create flow produces a valid record with required fields, validation enforcement, and correct persistence.
Validates that the edit flow loads existing data, applies changes, enforces validation, and persists correctly.
Validates that the list view loads, displays data, supports filtering, sorting, and pagination.
Validates that records can be deactivated (soft delete) with proper status change and UI feedback.
Validates that foreign-key lookup fields display related records and persist the selected reference correctly.
Validates that users without the required capability see appropriate access-denied behavior, not broken UI.
Quality Evidence
Readiness checks with compliance scoring
Governed changes carry evidence that reviewers can inspect before approval. The public catalog summarizes the check categories without exposing project-internal execution details.
Provenance exists and contains the fields required for review.
Generated file content matches the hash recorded in the manifest.
Source spec has not changed since generation (no undeclared drift).
All 6 expected module files are present (Data, Security, Lang, Logic, Tests, UI).
Generated XML validates against the module schema.
Security file defines required capabilities and access control rules.
Tests file contains at least one test per CRUD operation.
Language file covers all required locales declared in the spec.
UI screens declare valid routes that match the composition plan.
Data entities match the spec's entity definitions (fields, types, relations).
All module imports reference valid, existing modules.
Logic functions match the governed model's declared inputs and outputs.
UI bindings reference variables and functions that exist in scope.
Module has a passing certification pack result within the cache window.
Generated output was produced by a supported generation path.
How to read this catalog
Each control has an ID, a name, a description of what it prevents, and an enforcement point. Enforcement points are:
- Draft validation — checked when AI produces structured source material
- Spec validation — checked when a spec is processed for generation
- Composition validation — checked when packs are composed into an application
- Release gate — checked before a promoted baseline is accepted
Enterprise compliance teams can map these controls to SOC 2, ISO 27001, or internal governance frameworks.