Registry-driven design
PMFA uses registries to define schemas, enforce consistency, and automate UI generation — eliminating manual coding for routine operations.
The problem with traditional software
In most systems, adding a new entity (e.g., "product category") requires:
- Writing database schema (SQL migrations)
- Writing backend validation logic
- Writing API endpoints (create, read, update, delete)
- Writing frontend forms and tables
- Writing tests for all of the above
This is slow, error-prone, and creates inconsistencies between layers.
The PMFA approach: Registries
In PMFA, you define the entity once in a registry. The system generates everything else automatically.
Example: Defining a "Material" entity
{
"entity": "material",
"label": "Material",
"description": "Raw materials or components used in production",
"fields": [
{
"name": "name",
"type": "text",
"label": "Material Name",
"required": true,
"max_length": 100
},
{
"name": "supplier",
"type": "ref:supplier",
"label": "Supplier",
"required": true
},
{
"name": "batch_number",
"type": "text",
"label": "Batch/Lot Number",
"required": false
},
{
"name": "quantity",
"type": "decimal",
"label": "Quantity in Stock",
"required": true,
"min": 0
},
{
"name": "unit",
"type": "enum",
"label": "Unit of Measure",
"options": ["kg", "liter", "piece", "meter"],
"required": true
}
],
"authority_required": "warehouse.create_material"
}
What happens automatically
From this single definition, PMFA generates:
- Database schema: Fact storage with correct types
- Validation logic: Required fields, min/max, enum checks
- API endpoints: Create, read, query, mutate, revoke
- UI forms: Input fields with labels and validation
- UI tables: List views with sorting and filtering
- Authority checks: Only users with "warehouse.create_material" can create
Zero manual coding.
Registry as source of truth
The registry isn't documentation. It is the system.
If you change the registry (e.g., add a field, change a label), the entire system adapts:
- Forms update automatically
- API schema updates
- Validation rules change
- Evidence exports include the new field
This eliminates the drift between "what the docs say" and "what the code does."
Registry versioning
Registries themselves are stored as immutable facts. When a schema changes:
- A new version of the registry is created
- Old facts remain valid under their original schema
- New facts use the new schema
- Evidence exports include schema version information
This ensures that old data remains interpretable even as schemas evolve.
Why this matters
Speed
Adding a new entity takes minutes, not days. No need to coordinate backend, frontend, and database changes.
Consistency
All layers (database, API, UI) are guaranteed to be in sync because they're generated from the same source.
Auditability
Schema changes are tracked as facts. You can see when a field was added, by whom, and why.
Correctness
Validation logic is derived from schema, not manually written. Reduces bugs and edge cases.
Real-world example: WorkshopOS
WorkshopOS defines ~20 entities in its registry:
- Work orders, clients, materials, suppliers
- Invoices, payments, credit notes
- Users, roles, permissions
The entire UI (forms, tables, filters) is generated from these registries. When a field is added (e.g., "delivery address" on work orders), the form updates automatically across all screens.
Limitations
Registry-driven design works best for:
- CRUD operations (create, read, update, delete)
- Standard validations (required, min/max, enums)
- Straightforward relationships (one-to-many, many-to-one)
Complex business logic (e.g., multi-step approval workflows, custom calculations) still requires code. But 80% of routine operations can be registry-driven.