Library / Organization Change Engineering Principles Framework
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 06:00:20 UTC

OCE.4:4.1 - Pattern-Use Unfolding

  1. Bind the design question. Name the organization, intended outside contribution, selected concept, decision subject, authority, horizon, affected Systems, and first receiving use of the result.
  2. Recover the current relation basis. Carry forward current Work and direct-relation evidence from OCE.2, plus constraints, participants, assumptions, and burdens from OCE.3. Record unavailable or incompatible inputs explicitly.
  3. Select structures by question. Choose contribution, Work, decision, information-use, material-transfer, service, access, coordination, legal-entity, or other structures only when each changes the design. Use process, project, and case viewpoints on the same Work to expose different Method, coordination, state, and authority constraints. Retain the account of obtaining occurrences unless new evidence warrants revision; keep proposed structures and crossings modal. Preserve differences among the selected structures when those differences matter to the decision.
  4. Set specialization boundaries. Group contribution or Work where shared knowledge, equipment, evidence, decision, locality, customer, product, service, or provider conditions justify it. State the condition and the burden moved by each boundary.
  5. Write contribution-relation specifications. For every decision-bearing crossing, name the intended direct relation kind or predicate, supplier and receiver Systems, result or preserved condition, applicability, acceptance or use condition, exception return, scope, horizon, and evidence need. Use “interface” only as an orientation label after this content is visible. Do not report an occurrence before its predicate is satisfied.
  6. Obtain participant corrections. Use participant-facing views to test actual Work, burden, accessibility, safety, provider, and service-continuity assumptions. Record whose contribution changed the design and which material voice is missing.
  7. Compare whole structures. Compare how each candidate handles intended contribution, coordination load, decision latency, evidence, scarce capability, resilience, provider dependence, affected Systems, reversibility, and change burden. Keep unlike characteristics separate unless a justified aggregation Method exists.
  8. Make the architecture decision. Use C.32.PAD, C.11, or the applicable decision pattern for the claim being made. State selected structures, accepted losses, fixed constraints, open refinements, rejected alternatives, and reopen observations. Preserve modal status.
  9. Return position and paired-architecture questions. Send stable expected-contribution and eligibility needs to OCE.5. Send organization/product-or-service correspondence pressure to OCE.7. Keep holder, authority, capability, and realization questions with their owners.
  10. Specify realization evidence. Name which later Work and observations can show that each specified relation obtains, fails, or remains unresolved. Supply design constraints to OCE.9 without reporting organization capability.
  11. Stop at contribution sufficiency. Return when affected practitioners can name the contribution path, boundaries, contribution-relation specifications, accepted burdens, open refinements, and observations that reopen the design.

The steps are a reasoning aid. Existing structures may be repaired, new boundaries may be tried, and participant evidence may reopen an earlier decision at any time.