PMFA Standardization

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:

  1. Writing database schema (SQL migrations)
  2. Writing backend validation logic
  3. Writing API endpoints (create, read, update, delete)
  4. Writing frontend forms and tables
  5. 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.