Institutional Purpose, Value & Public Outcomes

3.1 Purpose and decisions supported

An institution can deliver a new platform, train its staff and digitize every form while leaving its users no better served. Architecture must therefore distinguish delivery from value. This section connects institutional purpose to observable service outcomes and to the decisions that would justify changing a system. It does not choose infrastructure or declare that digitization is inherently beneficial.

Section 01 establishes the mandate and architecture authority. Section 02 identifies actors, concerns, constraints and evidence gaps. Section 03 asks which changes would matter to those actors, how the institution would recognize improvement and which harms or costs could invalidate a proposed intervention. The result is a reviewable value hypothesis, not a proven business case.

This chapter supports four decisions: whether a proposed outcome belongs within the mandate; whether its evidence is credible enough for a bounded experiment; whether an intervention merits investment; and whether observed results justify continuation, revision or withdrawal. Local adoption requires an accountable institutional owner. Publishing this draft creates no such authority.

3.2 Purpose, outputs, outcomes and impact

Purpose states why the institution exists and whom it is responsible to serve. A mandate supplies the authority and obligations within which it acts. An output is something the institution produces. An outcome is a change experienced by a defined stakeholder or service population. Impact concerns wider, longer-term effects to which the service may contribute. These terms are related, but they are not interchangeable.

A deployed API proves neither usability nor confidence. A shorter processing time does not by itself prove a correct decision. The architect records these distinctions before selecting measures, otherwise delivery statistics can quietly replace the institutional objective.

In a commercial institution, value may include retained customers, dependable fulfilment and sustainable cost. In a public institution, access, accountability and legitimate treatment may dominate. The method works in either setting; the mandate and stakeholders determine the relevant value, not the framework's vocabulary.

3.3 Establish the institutional value boundary

Use the scope register from Section 02 to define the service population, request type, offices, decision authority and observation period. A broad ambition such as “improve regional services” is insufficient to approve a platform investment. Identify the particular service experience and the institution's practical ability to influence it.

For this chapter, the fictional institution has headquarters, six regional offices and a small engineering team. The proposed assessment covers one operational request type and one candidate pilot office. Requests pass through submission, departmental review, finance approval, fulfilment and reconciliation. Current spreadsheets, email and exports are assumptions to investigate, not findings from a real institution.

The institution controls its request process, decision records and support arrangements. It may depend on connectivity providers, external rules and other institutions, but cannot claim to control them. Separate accountable outcomes from outcomes requiring partner commitments. Record an unresolved dependency rather than assigning an external organization responsibility without its agreement.

No baseline, target, user sample, financial benefit or production result has been measured for this example. Every proposed outcome and decision below remains illustrative. Cross-references such as ZAF-I-02 / C-01 refer to the local registers of Section 02; new identifiers beginning ZAF-I-03 belong only to this chapter.

3.4 Construct the contribution model

Start with an explicit hypothesis: if request states and decision authority are made understandable and verifiable, requesters and staff may resolve uncertainty with fewer avoidable handoffs. This depends on accurate state updates, understandable language, available assistance and an institution that actually acts on pending work. Software cannot compensate for an unresolved mandate or absent decision owner.

Arrows in the model express proposed contribution, not demonstrated causation. For each link, record what would disconfirm it. If users still need unofficial intermediaries to interpret a status, releasing the status page has not established the intended outcome. Revise the intervention or hypothesis rather than redefining success after the event.

3.5 Define a small, accountable outcome register

A useful outcome register connects stakeholder experience to ownership, measurement and unresolved evidence. An outcome owner is accountable for the service change; a measure steward maintains its definition and provenance. The architect helps make these responsibilities explicit and does not assume either role by default.

These outcomes address ZAF-I-02 / C-01, C-02, C-04 and C-03 respectively. They do not exhaust the concerns register. C-05, preserving original decisions during correction, and C-06, recovery evidence, remain explicit constraints and dependencies for the proposed interventions.

Do not merge incompatible accountabilities into a vague “IT owner.” For OUT-04, the finance authority approves the reporting meaning and the information owner governs its record contract. If no role accepts accountability, keep the outcome unapproved and record the escalation in the Section 01 mandate process.

3.6 Specify a measurement contract before collecting results

A metric name is not a measurement contract. “Requests completed successfully” leaves open what counts as a request, completion, success, duplication and missing data. Define a measure tightly enough that a different analyst can reproduce it from the same authorized evidence.

For OUT-01, a candidate user-task measure is the proportion of observed assessment tasks in which a participant correctly identifies the authoritative request state and next action without facilitator correction. This is a study measure, not a population-wide service rate. Its interpretation depends on recruitment, the task set and the conditions of observation.

If eligible tasks have no observable outcome, present the unknown count alongside the rate and explain how it affects interpretation. A zero denominator is “not evaluable,” never zero percent. Preserve the original result when correcting a dataset, identify the replacement and record why the decision needs reconsideration.

3.7 Establish baselines and targets responsibly

A baseline describes conditions before the intervention under an identified method. A target is a prospective decision threshold with an owner, population and time horizon. Neither should be invented to make the architecture look mature. “Reduce processing time by 40%” has no evidential value here because no reference distribution or acceptable trade-off has been established.

First sample authorized request histories and observe representative normal and exception tasks. Record unavailable evidence and selection bias. Compare like request types, treatment periods and operating conditions; a pilot office chosen for reliable connectivity cannot establish performance for all six offices.

Report elapsed-time distributions when relevant, including long waits and incomplete work. Define whether the clock includes time awaiting requester information or finance review. Preserve that distinction rather than excluding difficult requests to improve a headline. A better median with a worse tail can represent improvement for some users and harm for others.

Set targets only after the owner considers the baseline, service obligation, operating capacity and consequences of failure. Record the target's rationale and review date. Keep a target separate from a contractual commitment and from an engineering service objective. This draft sets no numeric service commitment.

3.8 Relate value to the complete service journey

Follow the requester through the service rather than treating the online submission as the entire value stream. The normal path, correction, rejection, withdrawal, interruption and authorized challenge route can expose different ownership and information needs. Section 04 will develop capability and value-stream decomposition; this section establishes the outcome boundary it must preserve.

In the example, an interrupted local draft is not an accepted institutional request. The institution should evaluate a way to resume it, or an assisted route, without implying an approval that has not occurred. A correction after review must identify whether a new decision is needed; it must not silently rewrite the content already approved.

A rejected request still needs an authoritative state, understandable explanation within the authorized disclosure boundary, and a route for correction or challenge where the institution's rules provide one. These are proposed service requirements subject to policy-owner review, not a claim that every jurisdiction mandates the same procedure.

3.9 Examine value across stakeholders

Speed for the requester can increase verification work for staff. Stronger evidence can increase collection and retention burdens. A design that works for headquarters can shift cost to a regional office or exclude people who need assistance. Record who benefits, who carries the work and who can contest an adverse service experience.

Collect only the information justified by the assessment. Do not create sensitive demographic profiles merely to decorate a dashboard. Where different user conditions matter, agree a proportionate, authorized research method and explain its limitations. A small convenience sample cannot support claims of equitable outcomes across a region.

3.10 Separate service outcomes from engineering indicators

Engineering indicators help explain whether an implementation can support an outcome. Availability, latency, freshness and recovery checks do not establish institutional value on their own. A reachable service can display an obsolete state. A fast response can expose the wrong person's request.

For OUT-01, state correctness and comprehension are direct evidence needs. Request latency may be a supporting indicator, but its acceptable threshold depends on the task and operating conditions. For OUT-03, a successful restore exercise supports continuity; it does not prove that requesters resumed work without confusion or duplicated acceptance.

Book II will translate approved needs into engineering responsibilities. Book VIII will develop service objectives, indicators, error budgets and reliability practices where applicable. Their later specification must retain the institutional outcome and the evidence boundary, rather than turning every objective into a generic availability percentage.

3.11 Compare intervention options and their trade-offs

Evaluate a process change before assuming a new platform is required. For the fictional case, consider a clarified manual register, a bounded status service, and wider workflow automation. Keep the same outcome boundary when comparing options; otherwise a larger proposal can appear superior simply because it claims more benefits.

No option is selected in this draft. A narrow pilot is a candidate means of reducing uncertainty, not an automatic recommendation to build. If process ownership remains unresolved, a prototype can test comprehension but cannot validate institutional adoption.

Record each material trade-off as a decision with alternatives, expected outcome, evidence, uncertainty, owner and revisit trigger. Link a proposed version-bound approval to ZAF-I-02 / DEC-02 rather than asserting that the earlier decision has already been adopted.

3.12 Test investment viability without invented returns

A value hypothesis becomes useful for investment when it includes the work needed to sustain the service. Record discovery, delivery, migration, training, support, connectivity, reconciliation, recovery and retirement costs. Identify who bears them and which budget or capacity decision is required. Do not express unpriced effort as a precise financial return.

Avoid double counting: fewer status enquiries and staff time released may describe the same mechanism. Time released does not automatically become cash saved; it may be reallocated to unresolved requests. A plausible benefit is not a measured saving, and an approved budget is not proof of value.

Use a qualitative decision gate while estimates remain uncertain: mandate fit, expected stakeholder value, credible evidence, manageable risk and sustainable ownership. Record any condition that must be resolved before a pilot, such as staff availability or authority over the source record. A proposal that fails a non-negotiable mandate constraint cannot be rescued by a high weighted score.

Where financial estimates are later used, state currency, period, source, assumptions, ranges and sensitivity. Finance validates the institutional interpretation. This chapter contains no revenue forecast, quantified return or claim of cost reduction.

3.13 Learn, challenge and stop

An improvement observed after release is not necessarily caused by the release. Staffing changes, revised policy, seasonal volume and different request complexity can affect results. Record these factors and choose a proportionate comparison method before making a causal claim. Where no credible comparator exists, describe observed change and plausible contribution with explicit limits.

The outcome owner reviews evidence with user representatives, operational owners and the relevant decision authorities. Engineering explains implementation behavior; it does not decide alone whether the service meets its purpose. Record disagreement and unresolved evidence in the review decision.

Proposed triggers include repeated misunderstanding of accepted versus pending states, unexplained discrepancies between approved and executed versions, missing study evidence, and support work exceeding the agreed pilot capacity. These trigger investigation or a pause, not an automatic finding of failure. Define the owner, action and restart conditions before the pilot.

A useful review can conclude “do not expand.” Preserve the learning, explain which assumption failed and identify whether to change the process, redesign the intervention or withdraw it. Do not revise the measure retrospectively simply to make a completed release successful.

3.14 Required artifacts and review gate

The following are proposed work products for an institution adopting this chapter. Their presence in this public draft is not evidence that an assessment has been conducted. Each artifact needs an actual author, owner, version, evidence references and unresolved questions.

Before authorizing a pilot, review the mandate, scope, outcome owners, evidence permissions, measurement method and operating capacity. Before authorizing expansion, review actual pilot results and their limits. These are different gates: a plan can justify learning without justifying regional rollout. Acceptance of this ZAF chapter itself remains a separate editorial decision under the publication rules.

3.15 Verification checklist and next section

• Separate mandate, outputs, outcomes and wider impact in the written proposal.
• Link each proposed outcome to a stakeholder concern, an accountable role and a bounded population.
• Identify the assumptions that could break the contribution model.
• Define measurement eligibility, missing evidence, cut-offs and correction rules before observation.
• Keep baseline and target fields unresolved until evidence and owner decisions exist.
• Include interruption, correction, rejection and assisted journeys in the value boundary.
• Compare process and technology options against the same intended outcomes.
• Record full operating work, adverse effects and conditions for stopping or revisiting.
• Preserve a trace from evidence to review decision without claiming unsupported causation.
• Keep this document marked draft until its editorial review is recorded.

Section 04, Business Capabilities & Value Streams, will translate the approved value boundary into capability ownership and end-to-end flows. It should inherit the outcome register and concern links, then show which capabilities contribute to which outcomes. It must not begin with a technology catalog or a Kubernetes topology: those are downstream engineering choices, conditional on institutional need.