Views

A view is an abstract category of resources, the second global vocabulary of the model (the first is activities). Views are deliberately decoupled from tables: prescriptions may cover one table today and three tomorrow while the rules do not change. Like activities, they are global, not org-scoped.

INSERT INTO morbac.views (name, description) VALUES
    ('patients',      'Patient records'),
    ('prescriptions', 'Prescriptions'),
    ('lab-results',   'Laboratory results')
ON CONFLICT (name) DO NOTHING;

View hierarchy

morbac.view_hierarchy works like the activity hierarchy: a senior view is a more specific category. Declare confidential-patients senior to patients and a rule on patients also covers confidential-patients checks in the junior direction of resolution.

Which activities may touch a view

By default any activity can be paired with any view in a rule. To constrain a view to a fixed set of actions, populate morbac.activity_view_bindings; once at least one binding exists for a view, a trigger rejects rules that pair it with an undeclared activity:

INSERT INTO morbac.activity_view_bindings (activity, view) VALUES
    ('prescribe', 'prescriptions'),
    ('read',      'prescriptions');
-- a rule pairing (dispense, prescriptions) is now rejected until declared

This catches typos and nonsense pairs (dispense on invoices) at write time instead of letting them silently never match. The same table is described from the action side under activities.

Naming guidance

Views name categories users reason about, not storage: lab-results, not lab_results_v2_table. A view is a promise to your rules that stays stable even as the tables behind it change.