Capabilities & profiles

Port60 separates content, reusable capabilities, organisation profiles and visual templates. A template can present a capability, but it cannot enable that capability or grant an entitlement.

Declare requirements honestly

Use requiresCapabilities for capabilities the design needs in order to work as intended. The validator requires each declaration to have a corresponding section, page template or island:

{
  "requiresCapabilities": ["worship", "giving", "newsletter"],
  "suitsProfiles": ["mosque"]
}

If a decorative region merely looks good when a capability exists, but the template still works without it, do not call that capability required. Optional contexts are always sparse, so branch and omit when their data is absent.

requiresCapabilities is catalogue metadata. The Appearance picker compares it with the tenant’s enabled features, labels missing requirements and prevents a misleading recommendation. It never turns a feature on.

Profile recommendations

suitsProfiles accepts general, mosque, church, appeal-charity, pta, community and training. An empty list means general purpose. An exact profile match sorts ahead of a general template in the picker, but profile metadata never hides a template and never changes permissions.

Profiles describe design intent, not fixed content. A mosque template can use worship and giving surfaces without inventing prayer times or appeals. The organisation supplies the data.

Capability surfaces

Capability	Template-facing surface	Platform boundary
Giving and appeals	donation_widget; appealGrid and emergency with causes[]	Payment, Gift Aid and processor data stay in the platform
Worship	worship layout context and next_prayer	The platform supplies times and owns the ticking clock
Events and courses	Listing data or page templates; transaction islands	RSVP, tickets, enrolment and payment remain islands
Articles	articles, article, categories and engagement islands	Comments and engagement behaviour remain platform owned
Services	programmes with services[]	Templates receive display projections, not service internals
Forms	form island	Field rendering, human checks and submissions remain platform owned
Resources	resources with resources[]	Only public documents are exposed
Locations	locations with locations[]	Provider references and private notes are excluded
Newsletter	newsletter_signup	Explicit consent, evidence and unsubscribe handling stay in the platform
Internationalisation	locale context and language_switch	The platform owns locale switching and document direction
Search	search	Searches public article, service, event and resource projections only

Current module depth

The first capability release is intentionally narrow at its public boundary. Forms provide text, email, long text, choice and checkbox fields with privacy-recorded submissions. Form responses contain personal data. Organisations should collect only what they need and apply their own retention policy; the initial inbox does not claim automated retention, export or case-management workflows.

Those surfaces do not turn a template into an operational CRM. Forms do not provide workflow automation or payment collection. Template authors should not imply functionality beyond the published contract.

Design for more than one sector

Prefer reusable structures over organisation-specific assumptions. locations works for branches, community halls and campuses. programmes works for services, classes and projects. resources works for policies, lesson materials and community guides. Profile-specific character should come from composition, typography and content hierarchy, while the underlying capability surfaces stay consistent.