Pattern Languages without sufficient structure cannot become languages.

What follows is a description of a particular structure, as a generic - specific domains may find different terminology/content character more useful - but the functional intent of each section would remain.

The elements of the classic 'Alexandrian' pattern are:

NAME: as memetic as possible - conjures an archetypal ‘thing’ in the mind - even if only for demain insiders.

DEGREE OF CERTAINTY: Since Patterns are in some sense analogous to hypotheses, they may be more-or less well-founded / proven .

IMAGE: As memetic / archetypical as possible - ideally, you don’t need to read more than the name and look at the image to know that you want to know how to do this well, and you’re hooked…

CONTEXT: Short paragraph with just enough text to link this pattern in with the ‘story’ in which it can play a part - by way of links to patterns that form the context in which this one finds a viable place.

PROBLEM / PROPOSITION: Very short para that conveys the forces in operation at the site of the pattern, as an introduction to why it is needed / what it resolves.

DISCUSSION / EXEGESIS: Text, images, diagrams, references - a tendentious article as to the reasoning behind the recommendations that are to come next (on a slide, perhaps a couple of bullet points, no more - the speaker does this job)

THEREFORE / SOLUTION / HYPOTHESIS: short paragraph with a parametric outline of the recommended characteristics of an effective implementation of the pattern. (This is sometimes extended if necessary, with diagram or whatever is needed to be clear). NB the term ‘parametric’ - the aim here is to set out the key variables that need to be considered for an implementation - and some idea as to the ‘bounds’ within which the pattern will work - the scope of application.

CONSTITUENCY: Very similar to the Context section, excpet that here we are talking about patterns for which this one is the context. These may be mandatory or optional.

It is important to note that the content character of each element will also change across the ‘Hierarchy of Scope’ in the Language: Emergent Patterns (of wide scope) will be necessarily hand-wavy - ‘proofs’ and specifics do not strongly apply to emergence. Buildable Patterns (intermediate scope) - are typically complicated and involved. These will be more defintive than emergent patterns, but still rather descritptive - the parametric approach is strongest here. Do-able Patterns (tight scope) are generally more specific - fairly clear recommendations (and even in some cases automation) is practical here..