Inputs, outputs
& the operator.

First decide whether your system covers registration or the whole workshop. Here we study the processing of this round of applications through to providing the results to the organiser and applicants. Attendance, teaching and learning at the workshop lie outside that boundary.

Within that boundary, two outputs account for the stated task:

• O1 — Individual registration results: each applicant can access their own result, such as “place confirmed” or “no place,” with the relevant reason.
• O2 — A confirmed participant list: the organiser receives a list linking each allocated place to an identified student. Each student occupies at most one place.

A list of everyone who submitted the form is not yet a confirmed participant list. The status of an application has to be determined.

A narrower place-allocation system could end with the allocation list and leave notification outside its boundary. That is a possible model, but it would cover only part of the activity described here. We will carry forward the wider registration boundary.

One useful model defines the following four inputs. Your labels may differ; their meanings need to be clear.

I1 is a collection of submission records, not yet a list of distinct applicants. One student may have submitted several records. A name alone may not reliably identify repeats; an ID links submissions to the same student. Contact details are needed to provide each result, and submission times support the closing-time rule.

Keep the other definitions equally precise. I2 is the total offered, not the number of places still unallocated. I3 is the registration cut-off, not the notification time. I4 is the assigned headcount, not an individual's working speed.

This model studies the registration operation with those arrangements supplied to it. The process of deciding the arrangements is outside the chosen operating boundary. Other facilities, such as the form software, are held in the background.

The system turns submitted requests into determined and communicated registration outcomes. The transformation concerns information and registration status, rather than changing the students themselves.

“No place” can be an intended result produced by the rules. The purpose is to process applications and provide clear outcomes; the number of applicants may exceed the number of places.

Making a result available also differs from the student actually reading it. In this model, the registration process completes its communication task when the result is available to the intended applicant.

The three activity names leave several decisions unspecified. Does a repeated submission count as another applicant? Which submission time is retained? How are places allocated when demand exceeds the available places?

For the rest of this reading, use this first-come procedure:

• One student ID may receive at most one place.
• For repeated submissions, retain the earliest submission time and its receipt order.
• A request is on time if it was submitted no later than I3.
• Allocate places to the first I2 distinct, on-time applicants in receipt order, or all of them if fewer than I2 qualify.
• Keep each student's identity and contact details linked to the result.

Assume that identities and contact details are valid and unchanged across repeated submissions. When displayed times are identical, use the order retained by the form.

1. Consolidate submissions.

   Create one record per student ID, keeping the earliest submission, its receipt order and the student's contact details.

2. Check the closing time.

   Compare each retained submission time with I3. Keep a record for every applicant, including late applicants.

3. Allocate places.

   Order the on-time applicants and assign up to I2 places. Attach an outcome to every applicant; distinguish “late application” from “no place remaining.”

4. Prepare the outputs.

   Make the organiser's confirmed list and each applicant's result message, retaining the identity-to-result link.

5. Provide the results.

   Give the organiser the confirmed list and make each result available to the corresponding applicant.

The rules specify the basis for processing. The steps specify the activities that carry out that processing. Together with their required precedence relationships, they describe the operator.

First-come allocation is the reference rule used here. A different allocation rule would require a correspondingly clear description of its procedure and information needs.

The volunteers are the people who execute the procedure and provide labour. In our definition, the operator is the structured rules, steps and precedence relationships they follow.

Replacing the people can leave the operator unchanged. Keeping the same people but changing the repeated-submission rule changes the operator.

In everyday English, “operator” can also mean a person who operates something. In this reading, it has the specific meaning given in the definition above.

Taking the first 30 rows includes the repeated submission in row 30. Removing that repeat leaves 29 different students. The new student in row 31 has been excluded even though that student is among the first 30 distinct applicants.

Consolidating the repeated submissions first gives 30 distinct, on-time applicants. Applying the 30-place limit then includes all 30.

Each square represents a place, not a submission row. The numbers identify the distinct students in receipt order.

A volunteer could also read one record at a time, checking whether the student has already appeared before counting that student towards the limit. That can implement the same rule. Batch consolidation is one method; the essential requirement is that a repeat must not consume another person's place.

Before completing allocation, establish which distinct applicants are on time and their receipt order. Before preparing a list or a result message, determine each person's outcome.

With a suitable staffing arrangement, the list and messages can be prepared independently once the required outcomes exist. One person may still carry out those tasks in sequence; that scheduling choice does not create a necessary dependency between them.

Consolidation and time checks can also be arranged differently if the procedure retains all necessary records and identifies the same distinct, eligible applicants. Do not assume that every numbered step establishes the only possible execution order.

I2 is the total number of places offered. The volunteer has no authority to change it. Allocating an existing place under the rules is different from deciding that the total number offered will be 40.

The organiser has explicitly been given feasible options and the authority to choose among them. I2 is therefore controllable for the organiser and uncontrollable for the processing volunteer in this situation.

Control does not require unlimited choice. Being able to choose between the feasible values 30 and 40 is enough for this comparison.

A known value can still be uncontrollable. Wednesday at 18:00 may be completely certain, yet the volunteer cannot set a different cut-off. Uncontrollable does not mean unknown, random or disrupted by an external shock.

For I1, both people must work with what students actually submit. A volunteer can create consolidated records from those submissions, but cannot thereby decide what the students originally submitted or when they did so. Consolidated records are a new intermediate result of the operator.

It is possible for every listed input to be uncontrollable for one role. There is no need to add another item just to make both categories appear.

A changes I2. The rule can remain “allocate places to the first I2 distinct, on-time applicants.”

B changes the operator. It replaces the rule for handling repeated submissions; it does not change a value of I1–I4.

Likewise, “Wednesday at 18:00” is a value of I3. “Treat submissions no later than I3 as on time” is a rule describing how to use that value.

First define an item's role in the model, then classify the inputs. An outcome such as the confirmed list does not become a controllable input merely because somebody could edit it.

The following is a functional decomposition. A different division can also work if each part has a clear transformation and the handovers support the whole process.

Staffing is shared across functions. One volunteer may perform several functions, or several volunteers may divide the work. Decomposition does not create a separate copy of the staffing resource for each box.

The record does not have one permanent label. Its role depends on which system boundary you are using.

Also notice that B needs I2 directly from outside the operation. The preceding subsystem's output is an input to B, but it is not all that B needs.

C needs to know whose outcome each word describes and where to send it. The link between identity, contact details and result must survive the handover. Drawing an arrow alone does not establish that the next subsystem has enough information to work.

B producing O2 does not automatically produce O1. Individual notification is still needed to complete the wider task we defined.

Not every output from B must pass through C: the confirmed list goes to the organiser outside the system. An overall output can emerge from an intermediate subsystem.

Finally, two volunteers do not automatically mean two subsystems. A useful decomposition identifies functions and transformations; the same person may perform several of them.

Output: two complete sets of pages matching the specified PDF, handed to the requesting student. “Printing is finished” and “the student has received the pages” specify different endpoints; choose the one matching your boundary.

Possible inputs: the submitted PDF and its contents; requested copy count, here 2; supplied blank paper and its quantity; and the service window, here 09:00–18:00. You could also explicitly model provided staffing or equipment capacity.

One operator: accept the request during the service window; record the file and copy count; print according to that record; check content, pages and number of copies; hand the checked pages to the corresponding student.

The file and requested quantity must be available before printing can fulfil that request. Checking the printed pages requires those pages to exist. The printer's internal mechanical process can remain outside the detail of this model.

Controllability: if your inputs include the service window, it is uncontrollable for the staff member and controllable for the owner under the given authority. If you choose the customer's submitted PDF, both may need to take that actual submission as given. Keep the same definition rather than switching inputs to force different classifications.

• Inputs and outputs: have you specified the information, quantity, identity or state, rather than only naming a broad object?
• Operator: could another person execute your rules without inventing an essential decision? Can you justify the dependencies?
• Controllability: have you kept the input definition fixed while naming the person and their authority?
• Subsystems: is each handover sufficient for the next part, and do the connected parts still produce the original outputs?

For example, “students” could become “the submitted application records, each linking a student ID to contact details and a submission time.” The revised definition says what the operation actually receives and uses.