Skip to content
Paula Livingstone writing · projects · tools

Attestable Methodology: First Draft (superseded)

How the Artefact Is Built: The Method Governing Design Decisions

Design science's central activity is making the artefact, and a methodology that describes only how the result is judged has described the smaller half of its subject. This section states the method the design work follows, and derives it from a property of the artefact: its parts are rigid against each other, so they must be fixed in dependency order, each minimal, each settled before the next is built on it. Five commitments follow: draft the smallest thing that could work; publish requirements before structure; name every fork and settle it on evidence rather than preference; read a neighbouring formalism only against a stated lack; and record what the reading returned, including when it contradicts the design. Two are inherited rather than invented. The section closes on what a design method can and cannot do: it makes decisions checkable, not correct.

Superseded. This is an earlier draft of the methodology chapter, retained as a record of what the work believed at the time. It is not current: the composition it describes includes constrained elevation, which the design chapter withdrew after implementation established that no axis of a basis is elevatable. The current chapter is the one published under the methodology category.

The previous section said what is to be built and in what categories. It did not say how the building proceeds, and that omission would be a real one, because design science's central activity is the making of the artefact and a methodology that describes only how the result will be judged has described the smaller half of its subject. The paradigm places design and development third among its six activities, between the definition of objectives and the demonstration (Peffers et al., 2007), and this section states the method that occupies that place here.

The method is not general. It was arrived at because the artefact has a particular property that constrains how it can be built, and the property is worth naming first, because everything below follows from it.

Why the artefact constrains its own construction

The parts of this artefact are not independent. The basis model is a structure; the inheritance method operates on that structure; the admissibility method reads its fields; the instantiation enforces what those methods decide; and the evaluation defines its error over the verdicts that result. Each part is rigid against the one before it. A field added to the record is a field the methods must handle, and a field removed after the methods are written is a rewrite of everything downstream.

That rigidity is not a problem to be solved but a fact to be worked with, and the engineering literature on sequencing coupled work says what to do with it. The first step in organising interdependent tasks is to seek a sequence in which each can be executed only after it receives all the information it requires from its predecessors, at which point no coupling remains in the problem (Eppinger et al., 1994). So the parts are fixed in dependency order, each one minimal, and each one settled before the next is built on it.

The same source supplies the correction that keeps this honest. A fully sequential ordering rarely happens; real problems partition into a block form in which some groups remain coupled and must be worked simultaneously, with iteration between them (Eppinger et al., 1994). This artefact is no exception. The record, the methods that read it, and the instantiation are largely sequential, but the record and the admissibility method have proved coupled in practice: reading the delegation literature added a validity status to the record after the admissibility requirements had been written, and reading decision theory changed what a verdict may be after the record was fixed. What follows is therefore sequence where sequence is available and iteration where it is not, which the method must be able to say rather than treat as a departure from itself. Building the admissibility method first, and inferring the record it would need, would fix the record to suit a weighing that had not yet been argued. Building all parts together, adjusting each as the others shift, would produce a design no reader could check, because no commitment would ever have been made in a state where it could be wrong.

The method in three stages

The method has three stages, and each does a different kind of work. The first orders the parts. The second produces a candidate for the part in hand. The third tests whether that candidate is settled. They are stated separately because confusing them is how a design method becomes a description: an ordering rule cannot decide a structure, and a test cannot generate one.

Stage one: order the parts

Two rules fix the order in which parts are built, and both follow from the rigidity established above.

Each part is drafted at the minimum that lets the next part operate, and no further. Where the downstream is rigid, an oversized part is not a trim to undo in revision but a structure the rest would have to be rebuilt around. This has a stopping condition rather than a feeling: a part is finished when the part that depends on it has something to operate on and the evaluation has something to measure.

Each part is stated as requirements before it is stated as structure, and the requirements are published first. The purpose is that the hardest commitments are exposed while changing them is still cheap, and that a reader can see what a part was required to achieve independently of how it eventually achieved it. A structure published without its requirements can only be judged against itself.

Stage two: how a candidate is produced

The commitments above govern how the work proceeds and the three questions test whether a decision is settled. Neither says how a decision is arrived at. A test applied to a candidate presupposes a candidate, and a methodology that specifies only the test has left the generative step unstated. This section states it.

The four steps

Four steps produce a candidate structure from a requirement.

State what the part must answer, as a question about a specific object. Not what the part is for in general, but the question it must be able to answer and about what. For the independence problem this was: given two claims, can the model say whether they are genuinely separate supports or one source counted twice. The object is a pair of claims, and the answer is required to be derivable from what the model holds. A requirement stated at any looser grain admits every candidate and eliminates none.

Ask where the answer must be available. This is the step that does the eliminating, and it is the one most easily skipped. A question the artefact must answer is always a question it must answer somewhere, and the somewhere is fixed by the setting rather than chosen. For independence the location is the handover boundary, where a consumer holds the crossing record and does not reliably hold the records of its ancestors, since the parents were the producer's inputs and the grandparents almost certainly did not travel.

Enumerate the resolutions exhaustively at the level of what is held where. Not designs, but positions on the one axis that the location makes decisive. For independence the axis was where ancestry lives, and it admits exactly three positions: the record holds its ancestry, the record holds a reference into a graph held elsewhere, or the record holds something between the two that is sufficient for the test. Enumerating at this level matters because it is finite and checkable. A reader can see there is no fourth position, which they cannot see about a list of designs.

Apply the location to each resolution and keep what survives. Ancestry held wholly in the record answers at the boundary and grows without bound. Ancestry held wholly elsewhere cannot answer at the boundary once the record is separated from the store. What survives is the middle position: the record carries what the test needs and not the ancestry itself, which is the origin set. The candidate is produced by elimination rather than proposed and then defended, and this is what the three questions of the previous section are then applied to.

What the procedure does not do

It does not produce the middle position where the extremes both survive, and it does not name what the middle position should contain. That the surviving candidate is a set of evidential origins tested by intersection, rather than some other sufficient summary, is not derived by this procedure. It was chosen as the smallest structure answering the question and then tested. Where elimination leaves more than one survivor the choice is made by the minimality commitment and recorded as a choice, not presented as forced.

Where it has and has not been followed

The procedure was reconstructed from decisions already made, and it fits them unevenly. The independence decision followed all four steps and is the case the description is drawn from. The separation of authority from means followed the first and fourth: the question was stated and a distinguishing case eliminated the merged candidate, but no location was involved and no exhaustive enumeration was made, because the axis was binary. The conjunctive combination rule followed the first, third and fourth, with elimination doing the work and no location step, since the question was not about where an answer is available.

So the location step applies where the artefact must answer somewhere specific, and not otherwise. That is a limit on the procedure rather than a failure of the decisions, and stating it is what keeps the procedure honest: a four-step description that claimed to have governed three-step decisions would be describing work that did not happen.

Reading a neighbouring formalism

Producing a candidate sometimes requires knowing whether an outside field has already solved the problem, and that reading is bounded by two rules. Before any field is opened, the specific thing the artefact lacks is written in one sentence, drawn from the part as drafted; if that sentence cannot be written, the field is not opened, because reading a field to discover what in it might be relevant is unbounded by construction. And whatever the reading returns is written into the part it bears on, including when it contradicts the design. A field that supplies nothing is recorded as checked and not needed, which is an outcome rather than a gap, and a reading whose results are reported only when convenient is not a check.

Stage three: what a design decision has to clear

The commitments above say how the work proceeds. They do not say what makes any particular decision adequate, and without that they describe a procedure rather than impose a standard. Three questions decide a design decision here, and a decision that cannot answer all three is not settled, whatever process produced it.

What case forces it? A decision is admitted when a specific case can be named that the artefact must handle, and on which the chosen option succeeds and the rejected option fails. The case does the work, not the reasoning about it. Three forms have proved sufficient so far and are named because they are what a reader should look for. A distinguishing case shows two candidates cannot be merged, as a measurement from a calibrated instrument and one from an uncalibrated instrument share a means and differ in authority, so the two cannot be one field. A constraint case shows an option fails somewhere the artefact must work, as an independence test requiring a walk through ancestor records fails at a boundary where the consumer holds only the crossing record. An elimination case shows every alternative to the chosen option introduces something the work has already ruled out, as a weighted combination requires an exchange rate between axes that does not exist and a scored combination rebuilds the scalar the review refused.

What would falsify it? A decision must come with the observation that would show it wrong. If none can be stated, the decision is not a design choice but a preference, and it is recorded as open rather than presented as settled. This is the question most likely to fail a decision that feels obvious.

What does it cost? Every decision closes options, and the closure is stated where it is known. A decision whose costs are not named has not been examined, only made.

These are demanding enough to fail work in this chapter, which is the point of stating them. Two examples are already on the record. The number of fields the basis record carries is fixed at five, and no case is offered that forces five rather than four or six; each field is separately argued but the set is not, so by this standard the cardinality is a preference presented as a decision. And the claim that origin identity is implied by the means field rather than needing a field of its own is recorded in the structure as left to later reading, which is the correct treatment under the second question, but it sits in a section otherwise written as settled. Both are defects this standard exposes and neither is repaired by the standard existing.

When this standard was written

This section was written after the basis model, its structure, and the admissibility method had been drafted, and before the inheritance rule and the instantiation. That order matters to how it should be read. The three questions were arrived at by examining what the decisions already made were actually resting on, so they describe those decisions rather than having governed them, and a standard extracted from a body of work cannot then be used to vindicate it. What the standard can do is expose where that work does not meet it, which is why the two failures above are named rather than smoothed over, and govern what is built after it. A reader is entitled to test the earlier parts against these three questions and to find more that fall short.

What this method is answerable to

Two of these commitments are not this work's inventions and are stated as inherited so that they cannot be quietly relaxed. Publishing requirements before structure is the same ordering the paradigm already imposes between objectives and design (Peffers et al., 2007), applied one level down, to the parts of the artefact rather than to the project. Reading only against a stated lack is the sequence the register of claims under pressure fixed when it recorded the neighbouring formalisms as owed: draft the smallest model, find it wanting on a specific question, then read the field for that question.

The other three answer the trap this chapter opened with. A design method matters here for the same reason the evaluation method does, because both are places where the designer's judgement could quietly become the evidence. Settling forks on evidence rather than preference, recording open forks as open, and writing in the corrections a reading returns are each a way of making a design decision checkable by someone who did not make it. They do not remove the designer's judgement, which no method can, and they are not offered as doing so. They make the points at which it was exercised visible, which is a weaker claim and the one this work can support.

The limits of stating a method this way

Two things should be said plainly rather than left for a reader to notice. The first is that a method stated in the middle of the work it governs is partly a description and partly an intention. The commitments above were followed in the parts of the artefact already built, and they are stated here so that the parts not yet built are governed by them rather than measured against them afterwards. A reader is entitled to check the earlier parts against these commitments and to find where they were not kept.

The second is that this method makes design decisions checkable but does not make them correct. A fork settled on evidence is settled on the evidence available at the time, and the evidence is drawn from an artefact the same designer built. What the method provides is that the case supporting a decision is stated, so that a reader who thinks the case is wrong knows precisely what to attack. That is the honest description of what a design method can do here, and claiming more of it would repeat the failure this chapter exists to avoid.

References

Eppinger, S. D., Whitney, D. E., Smith, R. P. and Gebala, D. A. (1994). A Model-Based Method for Organizing Tasks in Product Development. Research in Engineering Design, 6, pp. 1-13. doi.org/10.1007/BF01588087

Peffers, K., Tuunanen, T., Rothenberger, M. A. and Chatterjee, S. (2007). A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 24(3), pp. 45-77. doi.org/10.2753/MIS0742-1222240302