DPFs
42 publications. Open a title to read, or expand its contents below.
Read the Suite introduction — Domain Principle Frameworks
Community Management Principles Framework
Use this framework when people need useful participation, relationships or joint contributions: help one another, take part in a valued activity, keep shared work feasible, or make their experience useful elsewhere. A community organiser, participant, practitioner, sponsor or assisting agent can enter at the difficulty already present. When the proposed community is meant to support a wider cultural purpose, CB.1 also helps decide whether that purpose needs a community contribution at all.
Contents · 16 patterns in Community Management Principles Framework
- Table of Contents
Community Management Principles Framework Architectural Reference
- CB.Reference:1 - Useful participation and its wider contributions
- CB.Reference:2 - What makes the choice difficult
- CB.Reference:3 - Connect the methods through the contribution needed next
- CB.Reference:4 - Two ways to carry a practice, and why the distinction matters
- CB.Reference:5 - The work being performed, and the support it needs
- CB.Reference:6 - Recognise the problem, then establish the result
- CB.Reference:7 - What this publication preserves and where to return
- CB.Reference:8 - Actual supplier returns
- CB.Reference:9 - Renew the affected contribution
- CB.Reference:End
Applications
- CB.Application:1 - Application 1 - Obtain useful professional help and develop what recurs
- CB.Application:2 - Application 2 - Keep a voluntary garden workable through conflict and succession
- CB.Application:3 - Application 3 - Extend a practice without a discussion group
- CB.Application:4 - Application 4 - Separate customer help, learning and provider commitments
- CB.Application:5 - Connect an external development community with independent workplaces
- CB.Application:End
Computational Thinking DPF
A pattern language for constructing, understanding, analyzing and transforming algorithms, including their interpretation and interaction.
Contents · 15 patterns in Computational Thinking DPF
- Table of Contents
Computational Thinking - Readme
Practical entries
- CP-INDEPENDENT-EXTENSIONS - A new data form and a new operation must work together
- CP-TRANSLATION-SCOPE - A translation works on test inputs; which executions does it preserve?
- CP-ANSWER-UNDER-LIMITS - Obtain the answer the work needs within available resources
- CP-RETRY-AND-RECOVER - Share calculations without merging requests or repeating their effects
Computational Thinking DPF Architectural Reference
- CMP.Reference:1 - Problem frame and the algorithmic difficulty
- CMP.Reference:2 - Forces that shape the construction
- CMP.Reference:4 - Worked connection - One best selection becomes every best selection
- CMP.Reference:5 - Use checks, assumptions and recurring failures
- CMP.Reference:6 - Consequences and Architectural Rationale
- CMP.Reference:7 - Shared sources, alternatives and relations
- CMP.Reference:End
Part A - Construct an algorithm
- CMP.1 - Solve One Problem through Another or Transfer a Limit (Computational Reduction)
- CMP.2 - Derive a Recursive Procedure from a Problem Decomposition
- CMP.3 - Share and Schedule Repeated Subcomputations
- CMP.4 - Construct Computational Search with Justified Exclusions
- CMP.5 - Bound an Optimum or Recover a Feasible Candidate through a Relaxed Problem
- CMP.6 - Derive an Iterative Computational Update from Local Information
- CMP.7 - Construct a Learner from Examples and Feedback
Corporate Finance Principles Framework
Methods for valuing investments, arranging finance, preserving liquidity, managing financial exposure and making corporate-finance decisions.
Contents · 22 patterns in Corporate Finance Principles Framework
- Table of Contents
Corporate Finance Principles Framework Architectural Reference
- FIN.Reference:1 - Problem frame
- FIN.Reference:2 - Problem
- FIN.Reference:3 - Forces
- FIN.Reference:4 - Solution
- FIN.Reference:5 - Archetypal Grounding
- FIN.Reference:6 - Bias-Annotation
- FIN.Reference:7 - Conformance Checklist
- FIN.Reference:8 - Common Anti-Patterns and How to Avoid Them
- FIN.Reference:9 - Consequences
- FIN.Reference:10 - Architectural Rationale
- FIN.Reference:11 - SoTA-Echoing
- FIN.Reference:12 - Relations
- FIN.Reference:End
Part E - Advice, renewal and continuing practice
- FIN.16 - Prepare a Finance Recommendation and Return It for a Decision
- FIN.17 - Refresh Financial Models and Data
- FIN.18 - Choose Whether and How to Change Corporate-Finance Methods
- FIN.19 - Reconcile Simultaneous Corporate-Finance Work Across Claims and Horizons
- FIN.20 - Deliberately Continue and Change Corporate-Finance Culture
Corporate Governance Principles Framework
A pattern language for making corporate decisions, arranging governing contributions, protecting rights and improving the ways these works are performed.
Contents · 17 patterns in Corporate Governance Principles Framework
- Table of Contents
Corporate Governance Principles Framework Architectural Reference
- CGOV.Reference:1 - Problem frame - Governing a corporation through particular acts
- CGOV.Reference:2 - Problem and forces - Joining competent contributions into an effective act
- CGOV.Reference:4 - Archetypal grounding - A bounded pilot commitment
- CGOV.Reference:5 - Bias, limitations and consequences
- CGOV.Reference:6 - Questions for use and recurrent failures
- CGOV.Reference:7 - Architectural Rationale
- CGOV.Reference:8 - SoTA-Echoing - Source contributions and their limits
- CGOV.Reference:9 - Relations, dependency and refresh
- CGOV.Reference:End
Part IV - Rights, consequences and renewal
- CGOV.12 - Protect Corporate Minority Holders’ Rights and Enable Contest or Exit
- CGOV.13 - Monitor Corporate Performance and Require an Account
- CGOV.14 - Decide Whether and How to Change Corporate Governing Instruments and Arrangements
- CGOV.15 - Decide Whether and How to Change Corporate-Governance Methods
- CGOV.16 - Reconcile Constituent and Encompassing Corporate Governance Work
- CGOV.17 - Deliberately Continue and Change Corporate-Governance Culture
Customization and Productization Management Principles Framework
Make customer-specific results and repeatable offerings supportable together.
Contents · 8 patterns in Customization and Productization Management Principles Framework
- Table of Contents
Customization and Productization Management Principles Framework Architectural Reference
- CUST.Reference:1 - Field and Use
- CUST.Reference:2 - Boundaries and the Meaning of the Name
- CUST.Reference:3 - Methods and Their Connections
- CUST.Reference:4 - Make the Whole Arrangement Work
- CUST.Reference:6 - Learn from Practice without Confusing the Result Levels
- CUST.Reference:7 - Recognition, Assurance and Correct Use
- CUST.Reference:8 - Consequences
- CUST.Reference:9 - Architectural Rationale
- CUST.Reference:11 - Supplying Methods and Reader Returns
- CUST.Reference:12 - Use and Refresh
- CUST.Reference:End
Customization and Productization Management Patterns
- CUST.1 - Manage Client Variation and Develop Repeatable Offerings
- CUST.2 - Recover Client Deltas and Choose Their Disposition
- CUST.3 - Develop a Repeatable Offering Family
- CUST.4 - Configure a Customer Solution and Place Differentiation
- CUST.5 - Run Field Learning and Return a Productization Candidate
- CUST.6 - Establish Repeatable Deployment and Service Delivery
- CUST.7 - Evaluate Growth and Customization with Full Resource Obligations
- CUST.8 - Change the Offering Family with Compatible Customer Transitions
Decision Design Principles Framework
A domain pattern language for constructing problem formulations, decision alternatives and models, and qualifying their interpretation and use in bounded inquiry, including professional participation and advice.
Contents · 18 patterns in Decision Design Principles Framework
- Table of Contents
Decision Design Principles Framework Architectural Reference
- PSDA.Reference:1 - The field and its useful result
- PSDA.Reference:3 - Formulation, professional support and choice
- PSDA.Reference:4 - Qualify the result and its combination
- PSDA.Reference:6 - Continue and change the practice
- PSDA.Reference:7 - Whose conditions and evidence shape the answer
- PSDA.Reference:8 - Questions before relying on a combined return
- PSDA.Reference:9 - Direct neighboring contributions
- PSDA.Reference:10 - What this framework covers
- PSDA.Reference:11 - Change only what the new basis changes
- PSDA.Reference:12 - Obtain the result needed for the developing subject
- PSDA.Reference:13 - Keep source changes and case changes distinct
- PSDA.Reference:14 - Direct frameworks, predecessor sources, and honest omissions
- PSDA.Reference:15 - Development-direction advising within a wider undertaking
- PSDA.Reference:End
Patterns
- PSDA.1 - Generate Plural Problem Formulations
- PSDA.2 - Set and Reopen the Problem Boundary
- PSDA.3 - Construct Complementary Situation and Option Models
- PSDA.4 - Select Problem-Structuring Methods and Combine Them When Needed
- PSDA.5 - Generate Decision Alternatives
- PSDA.6 - Represent Values and Trade-Offs
- PSDA.7 - Represent Decision-Relevant Uncertainty and Evidence Limits
- PSDA.8 - Compare Consequences of Decision Alternatives
- PSDA.9 - Test Robustness and Sensitivity of Decision Alternatives and Their Comparison
- PSDA.11 - Bound the Decision-Support Engagement and Authority Boundary
- PSDA.12 - Recover Participants, Concerns, and Affected Systems for a Decision-Support Inquiry
- PSDA.13 - Facilitate Decision-Support Inquiry and Preserve Material Dissent
- PSDA.14 - Prepare and Return a Decision-Support Recommendation
- PSDA.15 - Arrange Decision Follow-up or Reassess Advice After a Change
- PSDA.16 - Decide Whether and How to Change Problem-Structuring and Decision-Support Methods
- PSDA.17 - Reconcile Simultaneous Problem-Structuring and Decision-Support Work
- PSDA.18 - Deliberately Continue and Change Problem-Structuring and Decision-Support Culture
- PSDA.19 - Bound the Development-Direction Advising Engagement
Development-direction advising
- PSDA.Advising:1 - Use this when
- PSDA.Advising:2 - Enter at the missing result
- PSDA.Advising:3 - Bound the advising engagement
- PSDA.Advising:4 - Recover only the relevant holder premises
- PSDA.Advising:5 - Use the direct result-acquisition Method
- PSDA.Advising:6 - Keep a qualified live candidate set
- PSDA.Advising:7 - Compare for this receiving use
- PSDA.Advising:8 - Compose the bounded recommendation
- PSDA.Advising:9 - Return it for the agreed use
- PSDA.Advising:10 - Reconsider only affected advice
- PSDA.Advising:12 - Recognition, assurance and practical gain
- PSDA.Advising:End
Cross-pattern applications
PSDA.Application:1 - APP-PSD-01 — A flood-pump calculation is not the whole investment answer
- PSDA.Application:1.1 - The question and the people who need the answer
- PSDA.Application:1.2 - Preserve the differences that can change an intervention
- PSDA.Application:1.3 - Join inquiry and analysis without making one speak for the other
- PSDA.Application:1.4 - Use a numerical slice at its actual scope
- PSDA.Application:1.5 - Return the useful comparison and the whole-question blocker together
- PSDA.Application:1.6 - A changed premise changes the right claim
- PSDA.Application:1.7 - Continue the professional practice only when that is the question
PSDA.Application:2 - APP-PSD-02 — Development-direction advice with unlike holder premises
- PSDA.Application:2.1 - Two useful entries, not one compulsory advising process
- PSDA.Application:2.2 - Begin before the target contribution is settled
- PSDA.Application:2.3 - A person exploring four months of engineering development
- PSDA.Application:2.4 - An organization needs a ninety-day reliability recommendation
- PSDA.Application:2.5 - An AI configuration changes while independent advice survives
- PSDA.Application:2.6 - A population without a recipient, and a separate research question
- PSDA.Application:2.7 - What remains the same across the branches
PSDA.Application:3 - APP-PSD-03 — An on-time report that cannot yet be used
- PSDA.Application:3.1 - Recover the difficulty before naming a solution
- PSDA.Application:3.2 - Construct alternatives only where their consequences matter
- PSDA.Application:3.3 - Match the proposed action and the evidence to the question
- PSDA.Application:3.4 - Give a usable answer while uncertainty remains
- PSDA.Application:3.5 - Reconsider the affected claim after action
- PSDA.Application:3.6 - Make a usable aid for your own inquiry
PSDA.Application:4 - APP-PSD-04 — Mira’s development direction, programme comparison, and Guide
- PSDA.Application:4.1 - The working difficulty and the first bounded return
- PSDA.Application:4.2 - A complete pattern contribution, not “learn A.15.9”
- PSDA.Application:4.3 - Finite directions and a conditional later step
- PSDA.Application:4.4 - Advice and the two distinct choices
- PSDA.Application:4.5 - Guide realization, performed attempts, and evidence
- PSDA.Application:4.6 - A direct programme-level entry
PSDA.Application:6 - APP-PSD-06 — Unlike subjects, exact recipients, and an anti-case
- PSDA.Application:6.1 - Community and governance
- PSDA.Application:6.2 - AI/model or composite arrangement
- PSDA.Application:6.3 - Engineered platform or facility
- PSDA.Application:6.4 - Research programme or body of knowledge
- PSDA.Application:6.5 - Non-cultural population or lineage
- PSDA.Application:6.6 - What the contrast preserves
- PSDA.Application:7 - Choose development support without assuming an office
- PSDA.Application:End
Defense and Transmission Modeling DPF
A pattern language for explaining how practices continue and spread, how they help or impair work, and how protective action changes those outcomes.
Contents · 9 patterns in Defense and Transmission Modeling DPF
- Table of Contents
Defense and Transmission Modeling DPF Architectural Reference
- DTM.Reference:1 - The working problem and field
- DTM.Reference:2 - How the language holds the problem together
- DTM.Reference:3 - A connected worked inquiry
- DTM.Reference:4 - Protection and the simultaneous method vertical
- DTM.Reference:5 - What counts as a useful result
- DTM.Reference:6 - Rationale, synthesis and alternatives
- DTM.Reference:7 - External methods and publication use
- DTM.Reference:End
Economic Reasoning and Coordination Principles Framework
A pattern language for connecting different plans and knowledge with scarce means through calculation, exchange, commitments and economic arrangements.
Contents · 10 patterns in Economic Reasoning and Coordination Principles Framework
- Table of Contents
Economic Reasoning and Coordination Principles Framework Architectural Reference
- ECO.Reference:1 - Problem frame - Make an economically workable contribution
- ECO.Reference:2 - Problem and forces - Locally sound contributions can fail together
- ECO.Reference:4 - Archetypal grounding - From a proposed service to a viable arrangement
- ECO.Reference:5 - Consequences and limits
- ECO.Reference:6 - Common failures and useful returns
- ECO.Reference:7 - Architectural Rationale
- ECO.Reference:8 - Source use and currentness
- ECO.Reference:9 - External contributions and entry
- ECO.Reference:End
Embodied Rhythmics Principles Framework
A pattern language for recognizing, representing, shaping, performing, learning and observing rhythmic relations.
Contents · 14 patterns in Embodied Rhythmics Principles Framework
- Table of Contents
Embodied Rhythmics Principles Framework Architectural Reference
- RHY.Reference:1 - Problem frame - Work with performed rhythm
- RHY.Reference:2 - Problem - The useful relation disappears between descriptions and actions
- RHY.Reference:3 - Forces - Preserve the relation at an affordable cost
- RHY.Reference:4 - Solution - Connect the contributions through their results
- RHY.Reference:6 - Bias-Annotation - What the examples and sources do not travel with
- RHY.Reference:7 - Conformance Checklist - Check the combination that is being used
- RHY.Reference:8 - Common Anti-Patterns and How to Avoid Them
- RHY.Reference:9 - Consequences - Useful corrections with bounded conclusions
- RHY.Reference:10 - Architectural Rationale - Why the methods are divided this way
- RHY.Reference:11 - SoTA-Echoing - Source contributions and their limits
- RHY.Reference:12 - Relations, source return and renewal
- RHY.Reference:End
Engineering Asset Management Principles Framework
A domain pattern language for making and revising value-oriented decisions about engineered assets over their lives, for one asset, an interacting asset System or a portfolio.
Contents · 16 patterns in Engineering Asset Management Principles Framework
- Table of Contents
Engineering Asset Management Principles Framework Architectural Reference
- EAM.Reference:1 - The working problem and practical gain
- EAM.Reference:2 - Forces and working distinctions
- EAM.Reference:3 - Architectural Rationale
- EAM.Reference:4 - Recognition, assurance and ordinary stops
- EAM.Reference:5 - Predictable mistakes, consequences and bias
- EAM.Reference:6 - Current sources and what they support
- EAM.Reference:7 - Qualified returns from related practice
- EAM.Reference:8 - Framework boundary and revision
- EAM.Reference:End
Part C - Alternatives, Conflicts, Combinations, and Timing
- EAM.7 - Generate Ways to Supply an Asset-Dependent Service
- EAM.8 - Generate Maintenance, Renewal, and Retirement Alternatives
- EAM.9 - Compare Asset Alternatives and Reconcile Decisions When They Conflict
- EAM.10 - Compare Engineered-Asset Portfolio Combinations
- EAM.11 - Time Asset Interventions and Manage Dependencies
Part D - Decisions, Outcomes, and Continuing Practice
- EAM.12 - Integrate Specialist Results for an Asset Recommendation or Decision
- EAM.13 - Track Realized Outcomes and Reconsider Asset Plans
- EAM.14 - Decide Whether and How to Change the Asset-Management System
- EAM.15 - Decide Whether and How to Change Engineering Asset-Management Methods
- EAM.16 - Deliberately Continue and Change Engineering Asset-Management Culture
Explanation Design Principles Framework
Help a recipient recover and use a warranted connection by choosing the question, account, expression and support that the situation needs.
Contents · 6 patterns in Explanation Design Principles Framework
- Table of Contents
Explanation Design Principles Framework Architectural Reference
- EXD.Reference:1 - The practice and the problem it solves
- EXD.Reference:2 - The distinctions that change the work
- EXD.Reference:3 - Obtain and Carry the Subject Explanation
- EXD.Reference:4 - A worked exchange and its consequential returns
- EXD.Reference:5 - Why these Methods form a useful language
- EXD.Reference:6 - Assurance, limits and practical consequences
- EXD.Reference:7 - Framework and subject suppliers
- EXD.Reference:End
Patterns
- EXD.1 - Establish and Revise What a Recipient Needs Explained
- EXD.2 - Build and Bound an Explanatory Example
- EXD.3 - Coordinate the Expression of an Explanation
- EXD.4 - Co-Construct and Repair an Explanation in Dialogue
- EXD.5 - Guide a Recipient’s Own Explanation
- EXD.6 - Compare Explanations for the Recipient’s Use and Decide Whether a Repair Is Worthwhile
Financial Domain Modeling Principles Framework
Financial Domain Modeling helps a financial practitioner, business modeler or service designer establish whose financial position a model describes, what events can change it and how a service contributes to a participant's result. Its five methods connect parties, rights and obligations, contractual flows, actual effects and service use.
Contents · 5 patterns in Financial Domain Modeling Principles Framework
- Table of Contents
Financial Domain Modeling Principles Framework Architectural Reference
- FDM.Reference:1 - The working problem
- FDM.Reference:2 - How the methods connect
- FDM.Reference:3 - Connect models by the financial question
- FDM.Reference:4 - Parties, resources and several useful structures
- FDM.Reference:5 - Practical gain, cost and evidence
- FDM.Reference:6 - Source choices and alternatives
- FDM.Reference:7 - Using the connected account correctly
- FDM.Reference:End
- FDM.1 - Recover the Financial Position Behind a Record
- FDM.2 - Choose Party and Group Boundaries for Financial Modeling
- FDM.3 - Derive Events and Conditional Flows from Financial Contract Terms
- FDM.4 - Establish What a Financial Action Changed
- FDM.5 - Trace a Financial Service to a Participant’s Result
Human Capability Development Principles Framework
HCD is a pattern language for deriving human capability demand from later Work, designing and sustaining development arrangements, judging human contribution, transfer and retention, and evaluating instructional material under stated audience, task, support and time conditions.
Contents · 29 patterns in Human Capability Development Principles Framework
- Table of Contents
Human Capability Development Principles Framework Readme
Practical entries
- HCD-PRODUCT - Build a learning offer before the learners are known
- HCD-GROUP - Make joint activity develop the intended personal contribution
- HCD-FEASIBLE - Make a development proposal fit the work and available support
- HCD-EVIDENCE - Decide what a successful attempt permits you to rely on
- HCD-CONTINUATION - Keep a useful arrangement while its conditions change
- HCD-MATERIAL - Find what instructional material supports and what to repair
Human Capability Development Principles Framework Architectural Reference
- HCD.Reference:1 - Start from the contribution that later Work needs
- HCD.Reference:2 - What the framework connects
- HCD.Reference:3 - Human demand, capability evidence, development revision and transformation remain distinct
- HCD.Reference:4 - Several contributions can be simultaneous
- HCD.Reference:5 - Pattern relations do not prescribe a lifecycle
- HCD.Reference:7 - Architectural Rationale
- HCD.Reference:8 - Check the combination, learn from its result and revise
- HCD.Reference:9 - Intended use and ordinary non-use
- HCD.Reference:10 - PatternID and reader order
- HCD.Reference:11 - Available patterns
- HCD.Reference:12 - Direct result relations
- HCD.Reference:13 - FPF dependency and compatibility
- HCD.Reference:14 - External result and authority boundaries
- HCD.Reference:15 - Publication boundary and current full-body returns
- HCD.Reference:End
Part I — Human Capability Demand, Programme, Practice, Evidence, Continuation, Repertoire, Culture, Learning Products, and Shared Tasks
- HCD.1 — Derive Human Capability Demand from Representative Later Work
- HCD.3 — Diagnose Whether a Capability, Misconception, or Behaviour Limits Work
- HCD.4 — Architect a Balanced Human Capability Profile Across Simultaneous Work
- HCD.2 - Compose and Compare Human Capability-Development Programmes for Later Work
- HCD.5 - Select Human Capability-Development Methods
- HCD.6 - Design Representative Practice Tasks
- HCD.6.1 - Help a Learner Discern a Needed Distinction in Practice
- HCD.7 - Arrange Providers, Access, Tools, and AI Support for Human Capability Development
- HCD.8 - Obtain or Build Missing Human Capability-Development Support with Bounded Recursion
- HCD.9 - Perform Deliberate Practice with Feedback
- HCD.10 - Choose Whether and How to Vary, Space, Interleave, or Progress Practice
- HCD.11 — Assess Human Performance in Representative Work
- HCD.12 — Test Transfer to Unfamiliar Work or Learning from a New Source
- HCD.13 — Test Human Capability Retention and Dependence on Tools or Other Support
- HCD.14 — Revise the Human Capability-Development Arrangement from Evidence
- HCD.15 — Sustain Continuing Human Capability Development
- HCD.16 — Keep Human Capability-Development Method Claims Current
- HCD.17 — Deliberately Continue and Change Human Capability-Development Culture
- HCD.18 - Select or Construct a Characterization and Evaluation Specification for Instructional Material
- HCD.19 - Evaluate Instructional Material through Representative Reader Work and Diagnose Its Repair
- HCD.20 - Compose and Compare Arrangements for Individual and Group Learning
- HCD.21 - Form and Change Learning Work Groups
- HCD.22 - Design Shared Learning Tasks with Necessary Individual Contributions
- HCD.23 - Learn through Explanation and Comparison of Solutions
- HCD.24 - Learn Evaluation and Revision through Peer Review
- HCD.25 - Learn Transfer through Comparison of Projects
- HCD.26 - Regulate Shared Learning
- HCD.27 - Coordinate Personal Learning Routes with a Shared Rhythm
- HCD.28 - Construct and Revise a Whole Learning Product for a Future Audience
Cross-Pattern Application
HCD.Application:1 - Instructional-material evaluation profile
- HCD.Application:1.1 - Choose properties from the promised work
- HCD.Application:1.2 - Interpret material value separately from evidence and fit
- HCD.Application:1.3 - Use the two methods together without adding a lifecycle
- HCD.Application:1.4 - Why this profile is useful, and when a simpler alternative suffices
- HCD.Application:1.5 - Source-informed choices and limits
- HCD.Application:2 - APP-HCD-01 - Constructed ImpactReview-17 decision
- HCD.Application:3 - APP-HCD-02 - Constructed performance, transfer, retention and revision
- HCD.Application:4 - APP-HCD-03 - Constructed continuation, Method repertoire and culture
- HCD.Application:5 - APP-HCD-04 - Constructed whole learning product and shared task
- HCD.Application:6 - Application return to a programme and instrument designer
- HCD.Application:7 - ReleaseWork-R9 - Prospective demand and discriminated missing evidence
- HCD.Application:9 - Clinical unlike case - Return diagnosis and treatment to their owner
HCD.Application:10 - Combine explanation, experience and participation in a changing practice
- HCD.Application:10.1 - From a grammatical account to usable conversation
- HCD.Application:10.2 - Reconnect a perceptible cue, bodily coordination and a shared phrase
- HCD.Application:10.3 - Learn in a clerk’s actual queue and organize support around it
- HCD.Application:10.4 - Engineers learn through discussion and learn to coordinate across roles
- HCD.Application:10.5 - Use the construction without waiting for an unattainable experiment
- HCD.Application:End
Implementation Facilitation Principles Framework
Implementation Facilitation helps practitioners, organizations and affected people make an evidence-informed practice usable in its setting and develop their ability to conduct subsequent changes. Enter at the missing contribution; a sufficient local answer can be enough. The examples below show ordinary entries, not a catalogue or the field boundary. Use the pattern index for a different question.
Contents · 7 patterns in Implementation Facilitation Principles Framework
- Table of Contents
- IS.Readme - Find the first useful contribution
Implementation Facilitation Principles Framework Architectural Reference
- IS.Reference:1 - Implementation facilitation and the language that describes it
- IS.Reference:2 - Make useful practice obtainable in real work
- IS.Reference:3 - Keep the target, the help and their results distinct
- IS.Reference:4 - Use the connected Methods from the contribution that is missing
- IS.Reference:5 - One performer, several practices; several performers, one result
- IS.Reference:6 - Recognize a useful local result before claiming a larger one
- IS.Reference:7 - Sources, alternatives and limits
- IS.Reference:8 - Obtain the external contribution
- IS.Reference:9 - Reconsider only the contribution whose basis has changed
- IS.Reference:10 - What framework quality does and does not establish
- IS.Reference:11 - Supplier availability and independent changes
- IS.Reference:End
Patterns
- IS.1 - Agree a Useful Implementation-Support Undertaking
- IS.2 - Find the Implementation Difficulty and Obtain the Next Useful Contribution
- IS.3 - Construct and Adapt a Support Strategy with Its Recipients
- IS.5 - Sustain, Transfer, Extend or End Implementation Support
- IS.6 - Broker a Practice Change Across Unequal Influence
- IS.7 - Facilitate a Practice Change with Its Participants and Context
- IS.8 - Develop Recipients’ Ability to Facilitate Further Practice Changes
Knowledge-Corpus Access Engineering Principles Framework
Methods for designing, using and changing access to documentary knowledge.
Contents · 11 patterns in Knowledge-Corpus Access Engineering Principles Framework
- Table of Contents
Knowledge-Corpus Access Engineering Principles Framework Architectural Reference
- KCAE.Reference:1 - The working problem and the governed object
- KCAE.Reference:2 - Why changing questions defeat fixed representations
- KCAE.Reference:3 - The objects an engineer must keep distinct
- KCAE.Reference:4 - How the methods work together
- KCAE.Reference:5 - Alternatives and the cost of the whole arrangement
- KCAE.Reference:6 - Scope, preparation and evidence
- KCAE.Reference:7 - Relation to FPF and other frameworks
- KCAE.Reference:8 - Using and changing this account
- KCAE.Reference:9 - Source contributions and comparison boundaries
- KCAE.Reference:10 - FPF and DPF supplier returns
- KCAE.Reference:11 - Working vocabulary and result boundaries
- KCAE.Reference:12 - Conditions that change the framework and its uses
- KCAE.Reference:End
Patterns
- KCAE.USE - Choose an Access Arrangement for the Work
- KCAE.SOURCE - Prepare Addressable Sources without Losing Their Context
- KCAE.INDEX - Build Complementary Ways to Find Unknown Material
- KCAE.SEARCH - Continue a Search as the Question Develops
- KCAE.ASSESS - Determine What a Candidate Can Support
- KCAE.COMPOSE - Connect Contributions to a Feasible Whole Result
- KCAE.DELIVER - Put Sufficient Source Material within the Reader’s Reach
- KCAE.CHANGE - Keep Source Reading and Derived Views Coherent through Change
- KCAE.ENCOUNTER - Arrange a Useful Encounter with Knowledge during Work
- KCAE.MEMORY - Reuse Connections while Keeping Open Questions Revisable
- KCAE.EVAL - Compare Access Arrangements by Useful Results and Full Cost
Applications
KCAE.Application:1 - Constructing access for CedarBench support
- KCAE.Application:1.1 - The receiving work and source authority
- KCAE.Application:1.2 - The small source slice that decides this episode
- KCAE.Application:1.3 - Building the repeated retrieval arrangement
- KCAE.Application:1.4 - Assessment changes the next operation
- KCAE.Application:1.5 - Constructing and delivering the whole
- KCAE.Application:1.6 - A changed source and a failed view
- KCAE.Application:1.7 - Encounter, memory and evidence
- KCAE.Application:2 - A historical inquiry with no external processing
- KCAE.Application:End
Leadership Principles Framework
Helping participants act together, from a needed contribution to its useful performance and continuation.
Contents · 3 patterns in Leadership Principles Framework
- Table of Contents
Leadership Principles Framework Architectural Reference
- LDR.Reference:1 - The working situation and useful result
- LDR.Reference:2 - How the three leadership methods and their suppliers connect
- LDR.Reference:3 - What remains with other practices
- LDR.Reference:4 - Authority, cost and sufficient ordinary work
- LDR.Reference:5 - People, organizations and capable AI
- LDR.Reference:6 - How to use and question the result
- LDR.Reference:End
Connected use: a federation begins a joint evidence service
- LDR.Use:1 - A worthwhile proposal with incompatible contributions
- LDR.Use:2 - Advice changes the promise
- LDR.Use:3 - Agree a feasible first month
- LDR.Use:4 - Begin and complete a useful contribution
- LDR.Use:5 - Qualified autonomous AI changes the feasible whole
- LDR.Use:6 - Continuation after success is another substantive question
Maintenance Engineering and Management Principles Framework
Maintenance methods connect a condition or failure account with the result someone needs, such as advice, a selected intervention, functioning evidence, return to use or a programme decision. Each connection consumes a particular result. A suitable spare supports readiness; readiness and an operating allowance support a feasible intervention; performed work identifies the configuration to be tested; functioning evidence supports the receiving operating decision.
Contents · 16 patterns in Maintenance Engineering and Management Principles Framework
- Table of Contents
Maintenance Engineering and Management Principles Framework Architectural Reference
- MNT.Reference:1 - The working problem and practical gain
- MNT.Reference:2 - Organizing the Methods around different results
- MNT.Reference:3 - What the principal objects mean in practice
- MNT.Reference:4 - Competing values and the whole-use constraints
- MNT.Reference:5 - Architectural Rationale
- MNT.Reference:6 - Applying and checking the whole language
- MNT.Reference:7 - Assumptions, costs and limits
- MNT.Reference:8 - Shared source synthesis and useful neighbours
- MNT.Reference:9 - Returns to engineering and operating practice
- MNT.Reference:10 - Framework boundary and revision
- MNT.Reference:End
Part D - Information, Programme, Methods, Simultaneous Work, and Culture
- MNT.12 - Maintain Maintenance Information and Configuration Continuity
- MNT.13 - Coordinate the Maintenance Programme and Fleet Learning
- MNT.14 - Compare Maintenance Methods for Retention or Change
- MNT.15 - Reconcile Simultaneous Maintenance, Operation, and Support Work
- MNT.16 - Deliberately Continue and Change Maintenance Culture
Management Accounting Principles Framework
Management Accounting helps a controller, accountant or manager explain how work uses resources and how that use appears in money, forecasts and performance accounts. Begin with the decision or account that needs a better explanation. A small model of the relevant work can be sufficient.
Contents · 9 patterns in Management Accounting Principles Framework
- Table of Contents
Management Accounting Principles Framework Architectural Reference
- MA.Reference:1 - The working problem
- MA.Reference:2 - How the methods connect
- MA.Reference:3 - A model that changes the next decision
- MA.Reference:4 - Correct use, evidence and effort
- MA.Reference:5 - Why this organization of methods
- MA.Reference:6 - Sources, qualifications and changed conditions
- MA.Reference:End
- MA.1 - Build the Resource-Consumption and Cost Model
- MA.2 - Explain the Cost and Use of Capacity
- MA.3 - Assign Shared Costs for the Stated Use
- MA.4 - Reconcile Operating, Reporting and Cash Accounts
- MA.5 - Construct and Update an Operating Forecast
- MA.6 - Separate Forecasts, Targets and Resource Requests
- MA.7 - Explain a Cost or Margin Difference
- MA.8 - Account for Customer and Product Economics Over Time
- MA.9 - Examine the Behavioral Effects of Management Accounting Information
Marketing Principles Framework
Understand a customer's situation, develop an offer that can be delivered, and change commercial work in light of the result.
Contents · 14 patterns in Marketing Principles Framework
- Table of Contents
Marketing Principles Framework Readme
Practical entries
- MKT-ENTRY-QUESTION - Find out enough to make the next decision
- MKT-ENTRY-CHOICE - Make one customer’s next choice workable
- MKT-ENTRY-MEDIA - Keep the promise intact when an intermediary changes it
- MKT-ENTRY-PROGRAMME - Share preparation while keeping promises feasible
- MKT-ENTRY-LEARNING - Offer learning while preserving the learner’s purpose
- How to use the language
Marketing Principles Framework Architectural Reference
- MKT.Reference:1 - Problem frame - Useful offers in actual customer situations
- MKT.Reference:2 - Problem and forces - Connect usefulness, choice and provision
- MKT.Reference:3 - Solution - Enter through the result that is missing
- MKT.Reference:4 - Composition and performance - Preserve the conditions of the whole
- MKT.Reference:5 - Recognition and assurance - Know what the evidence establishes
- MKT.Reference:6 - Bias-Annotation - Recover whose result and whose burden
- MKT.Reference:7 - Conformance and common failures - Follow the intended use
- MKT.Reference:8 - Consequences - What changes in practice?
- MKT.Reference:9 - Architectural Rationale - A repertoire with connected results
- MKT.Reference:10 - SoTA-Echoing - Preserve distinct answers to distinct questions
- MKT.Reference:11 - Relations - Obtain the contribution the receiving decision needs
- MKT.Reference:12 - Edition and use
- MKT.Reference:13 - Direct framework returns
- MKT.Reference:14 - Refresh the affected use
- MKT.Reference:End
Marketing pattern language
- MKT.1 - Qualify a Market Problem and Differences between Customers
- MKT.2 - Construct and Test an Offer and Its Positioning
- MKT.3 - Reach a Suitable Audience and Obtain a Meaningful Response
- MKT.4 - Make Choice and Acquisition Meaningful and Feasible
- MKT.5 - Develop and Align a Customer Experience Concept
- MKT.6 - Jointly Shape a Useful Result and Help Achieve It
- MKT.7 - Continue, Restore or End a Customer Relationship
- MKT.8 - Construct a Journey Map for a Specific Decision
- MKT.9 - Select an Offer or Help for a Particular Customer
- MKT.10 - Evaluate the Contribution and Cost of a Marketing Intervention
- MKT.11 - Align Promises, Partners and Execution
- MKT.12 - Investigate a Customer or Market Question for a Decision
- MKT.13 - Test Commercial Model Repeatability and Deployment Limits
- MKT.14 - Develop and Change a Programme for Selected Customer Organisations
Cross-pattern applications
MKT.Application:2 - APP-MKT-MEDIA - Keep a supportable offer through a changing intermediary
- MKT.Application:2.1 - Start from the offer and the work that can receive a response
- MKT.Application:2.2 - Obtain the intermediary’s actual contribution
- MKT.Application:2.3 - Construct the permitted family of meanings
- MKT.Application:2.4 - Connect observable events to the receiving decision
- MKT.Application:2.5 - Make exposure compatible with actual provision
- MKT.Application:2.6 - Compare filtering and mistaken blocking from the affected purposes
- MKT.Application:2.7 - Revise the failed connection and preserve the useful remainder
MKT.Application:4 - APP-MKT-ACCOUNT - Carry a customer’s changing question from first contact into useful work
- MKT.Application:4.1 - Prepare an encounter that can change the work
- MKT.Application:4.2 - Obtain access and let the case travel
- MKT.Application:4.3 - Turn grounds for action into a usable comparison
- MKT.Application:4.4 - Investigate a concern and prepare an attainable agreement
- MKT.Application:4.5 - Make implementation a receiving part of the agreement
- MKT.Application:4.6 - Choose continuation and reopen only the affected work
MKT.Application:5 - APP-MKT-LEARNING - Connect a learning offer with personal development and voluntary exchange
- MKT.Application:5.1 - Recover the different purposes before building one arrangement
- MKT.Application:5.2 - Obtain the learning product and the personal programme
- MKT.Application:5.3 - Keep community participation workable alongside the offer
- MKT.Application:5.4 - Let a condition of the whole change the constituent action
- MKT.Application:5.5 - Judge and maintain the distinct results
- MKT.Application:End
Mathematical Modeling DPF
Methods for constructing mathematical representations of a question, connecting unknown relations, observations and available actions, and revising the resulting models.
Contents · 17 patterns in Mathematical Modeling DPF
- Table of Contents
Mathematical Modeling DPF Architectural Reference
- MMP.Reference:1 - Problem frame - Make a mathematical question useful
- MMP.Reference:2 - Problem and forces - Choose what the model must retain
MMP.Reference:3 - Solution - Connect the contributions the question needs
- MMP.Reference:3.1 - Form the first account and recover its interpretation
- MMP.Reference:3.2 - Represent admissible objects and construct missing relations
- MMP.Reference:3.3 - Construct change and observation together when they interact
- MMP.Reference:3.4 - Turn uncertainty into a question about available action
- MMP.Reference:3.5 - Simplify, diagnose and revise for the required consequence
- MMP.Reference:3.6 - Use the model-forming result across the Suite
- MMP.Reference:3.7 - Constituent actions in ongoing work
- MMP.Reference:3.8 - Compare or construct the way work is performed
- MMP.Reference:5 - Conformance Checklist - Can the result do its intended work?
- MMP.Reference:6 - Common Anti-Patterns and How to Avoid Them
- MMP.Reference:7 - Consequences, biases and limits
- MMP.Reference:8 - Architectural Rationale - Organize by model-forming operations
- MMP.Reference:9 - Source use and currentness
- MMP.Reference:10 - Relations to continued inquiry and work
- MMP.Reference:End
B. Infer, distinguish and revise
- MMP.7 - Construct a Probability Model of the Recorded Data
- MMP.12 - Formulate an Inverse Problem and Choose Whether and How to Use Regularization
- MMP.13 - Infer Unknowns Statistically under a Stated Observation Model
- MMP.14 - Find and Repair a Mathematical Model’s Failed Predictions
- MMP.15 - Identify an Intervention Effect from Available Data
- MMP.19 - Construct and Bound a Mathematical Counterfactual Comparison under a Causal Model
- MMP.16 - Design Observations to Separate Mathematical Model Alternatives
Mathematical Thinking DPF
A pattern language for constructing mathematical objects, operations and arguments, using their results, and developing the next useful question.
Contents · 20 patterns in Mathematical Thinking DPF
- Table of Contents
Mathematical Thinking DPF Architectural Reference
- MATH.Reference:1 - Problem frame - Construct mathematics for the question
- MATH.Reference:2 - Problem and forces - Make a usable construction
MATH.Reference:3 - Solution - Connect constructions through what they supply
- MATH.Reference:3.1 - Form objects, operations and representations
- MATH.Reference:3.2 - Obtain an argument and the object it supports
- MATH.Reference:3.3 - Change a construction and develop its theory
- MATH.Reference:3.4 - Return a construction to further work
- MATH.Reference:3.5 - Use this contribution within the wider repertoire
- MATH.Reference:3.6 - Constituent actions in ongoing work
- MATH.Reference:4 - Worked use - Choose a representation after the question changes
- MATH.Reference:5 - Worked use - Construct a choice after finding an obstruction
- MATH.Reference:6 - Checks and common failures - Preserve what the next construction needs
- MATH.Reference:7 - Consequences, biases and limits
- MATH.Reference:8 - Architectural Rationale - Organize by reusable constructions
- MATH.Reference:9 - Source use and currentness
- MATH.Reference:10 - Relations to further reasoning and work
- MATH.Reference:End
Part A - Choose and relate constructions
- MATH.16 - Choose a Mathematical Construction from Its Required Maps (Universal Property)
- MATH.17 - Construct Mathematical Spaces of Operations and Operations on Them
- MATH.1 - Build a Mathematical Structure of Composable Paths
- MATH.2 - Treat Objects as the Same While Preserving Operations (Quotient)
- MATH.5 - Extend a Generator Assignment While Preserving Operations (Homomorphism)
- MATH.7 - Transport a Mathematical Structure Through a Bijection
- MATH.18 - Compare Mathematical Accounts through Interpretations
Part C - Change a construction and develop its theory
- MATH.11 - Construct an Invariant from Transformation Rules
- MATH.13 - Derive a Consequence from a Symmetry
- MATH.8 - Generate a Solution Family by Symmetry
- MATH.9 - Determine Whether and How a Choice Rule Can Respect Symmetry
- MATH.10 - Improve a Mathematical Candidate or Derive a Necessary Condition by Admissible Variation
- MATH.21 - Construct an Object through Convergent Approximations
- MATH.22 - Change Axioms and Trace Their Consequences
- MATH.23 - Develop a Conjecture by Changing a Construction
Music and Dance Practice Engineering Principles Framework
A domain pattern language for creating, performing, transmitting, and deliberately developing music and dance practices and the environments that sustain them.
Contents · 22 patterns in Music and Dance Practice Engineering Principles Framework
- Table of Contents
Music and Dance Practice Engineering Principles Framework Architectural Reference
- MDPE.Reference:1 - A first result and a sufficient combination
- MDPE.Reference:2 - Several structures operate at once
- MDPE.Reference:3 - Performance, recognition, selection, and continuation are different results
- MDPE.Reference:4 - Project Work and cultural change
- MDPE.Reference:5 - Conditions on a whole combination
- MDPE.Reference:6 - Shared patterns and specialized Music and Dance Methods
MDPE.Reference:7 - Music, Dance, and overlapping use profiles
- MDPE.Reference:7.1 - Music: making and realizing musical possibilities
- MDPE.Reference:7.2 - Dance: making movement usable for its participants
- MDPE.Reference:7.3 - Teaching and recognition in Music and Dance
- MDPE.Reference:7.4 - Style development and continued practice
- MDPE.Reference:7.5 - Robotic, AI, and equipped performance
- MDPE.Reference:8 - What this publication foregrounds and leaves outside
- MDPE.Reference:9 - Architectural Rationale
- MDPE.Reference:10 - Shared source contributions and their limits
- MDPE.Reference:11 - Practical judgement, bias, and what changes next
- MDPE.Reference:12 - Intended use and ordinary non-use
- MDPE.Reference:13 - PatternID and reader order
- MDPE.Reference:14 - Source reliance and conditions for reconsideration
- MDPE.Reference:15 - External result use
- MDPE.Reference:16 - Publication boundary
- MDPE.Reference:End
Part III - Performance, Observation, Recognition, and Selection
- MDPE.11 - Interpret or Shape Music-or-Dance Material While Performing
- MDPE.5 - Integrate Production and Presentation for Performed Music-or-Dance Work
- MDPE.12 - Observe and Compare Music-or-Dance Performance and Cultural Results
- MDPE.23 - Develop and Test Music-or-Dance Recognition Capability
- MDPE.13 - Design How Music-or-Dance Variants Are Recognized and Selected
Part IV - Changed Conditions, Transmission, Memory, and Continuation
- MDPE.6 - Choose Whether and How to Use a Music-or-Dance Result under New Conditions
- MDPE.17 - Design and Test Transmission of a Music-or-Dance Method
- MDPE.18 - Build Usable Music-or-Dance Cultural Memory and Lineage Evidence
- MDPE.19 - Decide Whether a Music-or-Dance Variant Can Continue and What to Change
Part V - Supporting Environment, Practice Conflicts, Local Change, Alternatives, Trajectories, and Next Work
- MDPE.22 - Test a Support-Environment Change for a Music-or-Dance Practice
- MDPE.14 - Choose a Response to Conflicting Music-or-Dance Results
- MDPE.15 - Make and Test a Local Music-or-Dance Practice Change
- MDPE.16 - Keep Music-or-Dance Alternatives Available for Later Use
- MDPE.20 - Forecast How a Music-or-Dance Practice May Develop
- MDPE.7 - Choose the Next Music-or-Dance Development Work
Cross-Pattern Application
MDPE.Application:1 - A constructed social-dance and live-music development decision
- MDPE.Application:1.1 - Enter through the costly difficulty
- MDPE.Application:1.2 - Keep simultaneous Work separate from the decision unfolding
- MDPE.Application:1.3 - Test the support relation and the performed Work
- MDPE.Application:1.4 - Choose and perform one local change
- MDPE.Application:1.5 - Choose the next Work and stop before a cultural claim
MDPE.Application:2 - Investigate movement through physics, bodily experience and composition
- MDPE.Application:2.1 - Choose what the movement is doing in the inquiry
- MDPE.Application:2.2 - From an encountered difference to a physical explanation
- MDPE.Application:2.3 - Discover material before there is a phrase
- MDPE.Application:2.4 - Change quality and relationships, not only positions
- MDPE.Application:2.5 - Investigate what is perceived and what a trace preserves
- MDPE.Application:2.6 - Keep the useful result when the next question changes
MDPE.Application:3 - Compose movement from a physical relation or a scientific image
- MDPE.Application:3.1 - Make the source useful to a composition
- MDPE.Application:3.2 - Case A — Keep an apex in the music without demanding a longer flight
- MDPE.Application:3.3 - Case B — Use relativity to generate a spatial duet, not to explain the dancers’ bodies
- MDPE.Application:3.4 - Adapt the construction without losing its distinction
MDPE.Application:4 - Construct a rhythmic part from a seed, phase and action rule
- MDPE.Application:4.1 - Generate the small seed and choose its phase
- MDPE.Application:4.2 - Turn the onsets into actual hand and sound parts
- MDPE.Application:4.3 - Change the receiving condition without confusing the two action rules
- MDPE.Application:4.4 - Extend the phrase while preserving a chosen action relation
- MDPE.Application:4.5 - Return the useful part and its limits
MDPE.Application:5 - Participation, learning, recognition and renewal in music and movement practices
MDPE.Application:5.1 - Renew a shared practice without losing what makes participation worthwhile
- MDPE.Application:5.1.1 - Use this when
- MDPE.Application:5.1.2 - Problem and forces
MDPE.Application:5.1.3 - Solution
- MDPE.Application:5.1.3.1 - 1. Start from the participation that should remain possible
- MDPE.Application:5.1.3.2 - 2. Follow the connections that produce the difficulty
- MDPE.Application:5.1.3.3 - 3. Construct an arrangement by working backward from its receiving use
- MDPE.Application:5.1.3.4 - 4. Compare whole arrangements, including who bears the change
- MDPE.Application:5.1.3.5 - 5. Arrange acquisition and provision at the point where they are needed
- MDPE.Application:5.1.3.6 - 6. Carry out the change and follow its consequences through receiving use
- MDPE.Application:5.1.3.7 - 7. Renew the criteria as well as the selected repertoire
- MDPE.Application:5.1.4 - A complete constructed case: the evening that became a qualification course
- MDPE.Application:5.1.5 - What makes this one composite method
- MDPE.Application:5.1.6 - Recognition and assurance
- MDPE.Application:5.1.7 - Grounds, alternatives and limits
MDPE.Application:5.3 - Connect style, Method structure and acquisition
- MDPE.Application:5.3.1 - Begin with the difference the work needs
- MDPE.Application:5.3.2 - Compare a style through declared changes and distinctions
- MDPE.Application:5.3.3 - Restore the Method behind a stylistic result
- MDPE.Application:5.3.4 - Make granularity a declared comparison choice
- MDPE.Application:5.3.5 - Separate recoverable structure from acquired capability
- MDPE.Application:5.3.6 - A worked acquisition contrast
- MDPE.Application:5.3.7 - Use assisted reach as a question, not a permanent rank
- MDPE.Application:5.3.8 - Where an epiplexity analogy is useful
- MDPE.Application:5.3.9 - Return the distinction to the shared practice
MDPE.Application:5.4 - Obtain and change a movement organization for partnered performance
- MDPE.Application:5.4.1 - Start from the continuation the participants want
- MDPE.Application:5.4.2 - Use a small joint attempt to find the limiting relation
- MDPE.Application:5.4.3 - Construct usable bodily means at the scale of the gap
- MDPE.Application:5.4.4 - Make attention available for the next consequential change
- MDPE.Application:5.4.5 - Build the transition from the next entry back to the present movement
- MDPE.Application:5.4.6 - Derive learning from the execution that is missing
- MDPE.Application:5.4.7 - Two connected constructed cases
- MDPE.Application:5.4.8 - Grounds, evidence and limits
MDPE.Application:5.6 - Receive a declined invitation and find an available next action
- MDPE.Application:5.6.1 - Let the actual answer end the invitation
- MDPE.Application:5.6.2 - Obtain a next action from what is actually available
- MDPE.Application:5.6.3 - Supply the missing contribution without demanding a different feeling
- MDPE.Application:5.6.4 - A constructed case: a courteous reply leaves another task
- MDPE.Application:5.6.5 - Derive practice and evidence from the missing action
- MDPE.Application:5.6.6 - Grounds, alternatives and limits
- MDPE.Application:End
Narrativization and Narrative Studies Principles Framework
This framework helps turn material with connected ideas, events or constraints into a narrative that a reader can follow and use. The work includes choosing what must survive, deciding its order, designing the reader's route and repairing misleading or unhelpful explanations. The entries below are selected examples, not a catalogue or coverage boundary. Bring the actual question; use the Table of Contents or a direct pattern when no example fits. Some difficulties need one bounded repair; others need several patterns working together. For a question already answered by one pattern, use its PatternID and title in the Table of Contents.
Contents · 8 patterns in Narrativization and Narrative Studies Principles Framework
- Table of Contents
Narrativization and Narrative Studies Principles Framework Architectural Reference
- NSTD.Reference:1 - Problem frame and shared difficulty
- NSTD.Reference:2 - Solution and connected use
- NSTD.Reference:3 - Shared distinctions and conditions
- NSTD.Reference:4 - Architectural Rationale, forces and performance across levels
- NSTD.Reference:5 - Evaluation, typical failures and consequences
- NSTD.Reference:6 - Source synthesis, coverage and relations
- NSTD.Reference:8 - Support Maps
- NSTD.Reference:9 - Architecture and narrative work bridge
- NSTD.Reference:10 - Semiotic and language-precision bridge
- NSTD.Reference:11 - Working meanings and direct source returns
- NSTD.Reference:12 - FPF contribution and compatibility
- NSTD.Reference:13 - DPF relations
- NSTD.Reference:14 - Refresh the affected narrative use
- NSTD.Reference:End
Patterns
- NSTD.1 - Choose a Narrative’s Purpose and the Source Structures It Must Preserve
- NSTD.2 - Choose a Narrative Order That Keeps Needed Source Relations Recoverable
- NSTD.3 - Repair Missing or Unsupported Narrative Connections (Coherence and Event Models)
- NSTD.4 - Choose Narrative Voice and Focalization while Keeping Agency Claims Grounded
- NSTD.5 - Choose Narrative Engagement Devices for the Intended Experience or Use
- NSTD.6 - Declared-Use Narrative Rendering Quality Evaluation
- NSTD.7 - Automated Narrativization and Story Planning
- NSTD.8 - Design a Narrative Learning Route for Reconstruction and Use
Notational Engineering DPF
A pattern language for designing expressions that people and computational agents can interpret, manipulate, translate and use together.
Contents · 8 patterns in Notational Engineering DPF
- Table of Contents
Notational Engineering DPF Architectural Reference
- NOT.Reference:1 - Problem frame and the work of designing a notation
- NOT.Reference:2 - Forces that shape the choice
- NOT.Reference:5 - Conditions of use, checks and recurring failures
- NOT.Reference:6 - Consequences and Architectural Rationale
- NOT.Reference:7 - Shared sources, alternatives and refresh
- NOT.Reference:8 - Relations to the rest of the Suite
- NOT.Reference:End
Operations Management Principles Framework
A domain pattern language for admission, continuation, coordination, service, quality, improvement and performance decisions in continuing operation.
Contents · 28 patterns in Operations Management Principles Framework
- Table of Contents
Operations Management Principles Framework Readme
Practical entries
- OPS-PUMPWORKS — Find the next supported controller-service decision
- OPS-SERVICE-WINDOW — Offer service that rooms, people and commitments can support together
- OPS-ACCEPTED-RESULT — Faster generation still leaves the promised result unavailable
- OPS-PRACTICE-CHANGE — Change the way of working without treating publication as successful use
- OPS-RELEASE-AND-WAIT - Change admission without losing the customer’s wait
- OPS-PROTECT-AND-DEVELOP - Prepare or learn while preserving promised service
- OPS-PREPARE-AND-RESPOND - Prepare useful work and keep a response possible
- OPS-ADVICE-IN-USE - Follow an operating explanation into the user’s work
- OPS-AIMS-AND-PERFORMANCE — Set a meaningful aim and interpret what follows
Operations Management Principles Framework Architectural Reference
- OPS.Reference:1 - Start from a difficulty in continuing operation
- OPS.Reference:2 - Competing demands on one operation
- OPS.Reference:3 - Work, descriptions, structures, and records remain distinct
- OPS.Reference:4 - Demand, commitments, subjects, and units remain distinct
- OPS.Reference:5 - Several management views can coexist on the same Work
- OPS.Reference:6 - Shared attention is stronger than visibility and weaker than consensus
- OPS.Reference:7 - The control branch is conditional
- OPS.Reference:8 - Pattern relations do not prescribe an operating lifecycle
- OPS.Reference:9 - Use the Methods together where their results meet
- OPS.Reference:10 - Conditions on a whole combination
- OPS.Reference:11 - Check the combined decision and its result
- OPS.Reference:12 - Architectural Rationale
- OPS.Reference:13 - Apply the repertoire in production and service settings
- OPS.Reference:14 - Gains, burden and limits of combined use
- OPS.Reference:15 - What this publication covers and leaves outside
- OPS.Reference:16 - Intended use and ordinary non-use
- OPS.Reference:17 - PatternID and reader order
- OPS.Reference:18 - Practical entry forms
- OPS.Reference:20 - FPF dependency and compatibility
- OPS.Reference:21 - Sibling-domain returns and availability
- OPS.Reference:22 - Available contributions
- OPS.Reference:23 - Representative case coverage
- OPS.Reference:24 - Edition return
- OPS.Reference:25 - Publication boundary
- OPS.Reference:End
Organization Administration Principles Framework
ADM helps administrators examine administrative requests, give justified refusals and provide usable results under the organization's rules. Its fifteen patterns also help improve the arrangements supporting this work by connecting organizational rules, participants, permissions, work and records. Establish any permission required for the action being taken; specialist decisions remain with the people authorized to make them.
Contents · 15 patterns in Organization Administration Principles Framework
- Table of Contents
Organization Administration Principles Framework Architectural Reference
- ADM.Reference:1 - The working problem
- ADM.Reference:2 - How the contributions connect
- ADM.Reference:3 - Different things, different accounts and different structures
- ADM.Reference:4 - Correct use and its cost
- ADM.Reference:5 - Why use this language
- ADM.Reference:6 - Sources, evidence and changed conditions
- ADM.Reference:7 - Applied framework instructions
- ADM.Reference:8 - Enabling provision and decision accounts
- ADM.Reference:9 - Using operational accounts
- ADM.Reference:End
Part B - Design the Repeated Case, Resolve Exceptions and Supply the Result
- ADM.5 - Design Reusable Instructions for Administrative Requests
- ADM.6 - Resolve an Administrative Exception
- ADM.7 - Check the Claim Needed for This Administrative Decision
- ADM.8 - Establish and Exercise the Required Permission for an Administrative Action
- ADM.9 - Provide a Usable Administrative Result
- ADM.10 - Reconcile Administrative Obligations, Performance and Records
Organization Change Engineering Principles Framework
A domain pattern language for changing an organization's contributions, working relations, and capability while its work continues.
Contents · 17 patterns in Organization Change Engineering Principles Framework
- Table of Contents
Organization Change Engineering Principles Framework Readme
Practical entries
- OCE-PUMPWORKS - Compare weekly AI-inspection work arrangements while service continues
- OCE-CONSEQUENCES - Keep a useful contribution while repairing the service it disrupts
- OCE-ASSOCIATION - Preserve contribution and authority across membership and service changes
- OCE-PRACTICE-CONTINUATION - Keep useful practice when names, examples and opportunities differ
- Citation
Organization Change Engineering Principles Framework Architectural Reference
- OCE.Reference:1 - From a bounded change to continuing organization development
- OCE.Reference:2 - Actual, formal, and possible claims remain distinct
- OCE.Reference:3 - Several structures and several views can coexist
- OCE.Reference:4 - Pattern relations do not prescribe a lifecycle
- OCE.Reference:5 - How the contributions connect
- OCE.Reference:6 - Conditions for using the contributions together
- OCE.Reference:7 - Architectural Rationale
- OCE.Reference:8 - Applying the language in different settings
- OCE.Reference:9 - Practical gains, costs and limits
- OCE.Reference:10 - Questions before relying on a combined result
- OCE.Reference:11 - Intended use and ordinary non-use
- OCE.Reference:12 - PatternID and reader order
- OCE.Reference:13 - Using the available Methods
- OCE.Reference:14 - Pattern selection and result relations
- OCE.Reference:16 - FPF dependency and compatibility
- OCE.Reference:17 - Method development and Implementation Facilitation contributions
- OCE.Reference:18 - Sibling-domain returns
- OCE.Reference:19 - Representative case coverage
- OCE.Reference:20 - Publication boundary
- OCE.Reference:End
Part II - Design Organization Relations and Work Arrangements
- OCE.4 - Design an Organization’s Contribution Architecture
- OCE.5 - Define Organization Positions
- OCE.6 - Establish Holder Assignments and Enabling Relations for Organization Change
- OCE.7 - Coordinate Product-or-Service and Organization Architecture Decisions
- OCE.8 - Compare Human, AI, Robotic, and Provider Arrangements for the Same Organizational Work Result
Part III - Realize Change While Work Continues
- OCE.9 - Realize a Bounded Organization-Capability Increment
- OCE.10 - Choose a Response to Participation or Working Culture Difficulties in the Target Organization
- OCE.11 - Coordinate Organization-Change Work with Continuing Service
- OCE.18 - Arrange Capability Development and Receiving Work in an Organizational Transition
Physical Thinking DPF
A pattern language for forming physical accounts, deriving usable consequences, constructing observations and revising the physical assumptions.
Contents · 10 patterns in Physical Thinking DPF
- Table of Contents
Physical Thinking DPF Architectural Reference
- PHY.Reference:1 - Problem frame - Construct a physical account you can use and change
- PHY.Reference:2 - Problem and forces - Keep the physical question through the calculation
- PHY.Reference:4 - Worked connection - From an unknown resistance to a useful comparison
- PHY.Reference:5 - Bias, use checks and recurring failures
- PHY.Reference:6 - Consequences and Architectural Rationale
- PHY.Reference:7 - Shared sources, alternatives and relations
- PHY.Reference:End
Part A - Construct and constrain a physical account
- PHY.4 - Constrain an Unknown Physical Law by Transforming the Situation
- PHY.5 - Choose an Effective Physical Description by Scales and Couplings
- PHY.6 - Construct Physical Evolution from Balances and Response Laws
- PHY.7 - Obtain Motion from a Physical Variational Principle
- PHY.8 - Infer Macroscopic Physical Behavior from Microscopic Alternatives
Part B - Compare, observe and act
- PHY.1 - Construct Physical Similarity Across Changed Conditions
- PHY.2 - Construct a Physical Analogue from Interactions
- PHY.9 - Construct a Measuring Interaction for a Physical Distinction
- PHY.10 - Construct a Physical Test That Separates Rival Accounts
- PHY.3 - Derive a Physical Limit from Permitted Transformations
Research Method Practice Principles Framework
A research repertoire for qualifying a question, choosing and conducting a defensible inquiry, examining and returning its knowledge contribution, and retaining or improving the Methods that serve it.
Contents · 11 patterns in Research Method Practice Principles Framework
- Table of Contents
Research Method Practice Principles Framework Architectural Reference
- RMP.Reference:1 - The practical question behind research and engineering
- RMP.Reference:2 - Forces that shape the first result
- RMP.Reference:3 - Research membership is not institutional status
- RMP.Reference:4 - Question, frame, design, Work, result, and decision remain distinct
- RMP.Reference:5 - Criticism comes before method prestige
- RMP.Reference:6 - Pattern relations do not prescribe a research lifecycle
- RMP.Reference:7 - Use the two contributions together
- RMP.Reference:8 - Connect operationalization and actual trace
- RMP.Reference:9 - Connect analysis and the credibility choice
- RMP.Reference:10 - Connect corpus synthesis and exact revision
- RMP.Reference:11 - Connect Method improvement and research consequences
- RMP.Reference:12 - Conditions for a usable combined result
- RMP.Reference:13 - Architectural Rationale
- RMP.Reference:14 - What the repertoire foregrounds and leaves outside
- RMP.Reference:15 - Intended use and ordinary non-use
- RMP.Reference:16 - Judge the connected result
- RMP.Reference:17 - Bias and the reach of these examples
- RMP.Reference:18 - Failures at the connection between the patterns
- RMP.Reference:19 - Practical consequences and revision
- RMP.Reference:20 - PatternID and reader order
- RMP.Reference:21 - Available repertoire and scope
- RMP.Reference:22 - Direct result relations and non-lifecycle topology
- RMP.Reference:23 - What the sources contribute to the shared architecture
- RMP.Reference:24 - Using FPF for the source answer
- RMP.Reference:25 - External result and authority boundaries
- RMP.Reference:26 - Public returns to adjoining practice
- RMP.Reference:27 - Representative case coverage
- RMP.Reference:28 - Publication and maintenance boundary
- RMP.Reference:End
Cross-Pattern Application
RMP.Application:1 - APP-RMP-01 — Pump-P4 accelerated seal evidence
- RMP.Application:1.1 - First fork — routine qualification, supplied answer, or research question
- RMP.Application:1.2 - Construct a comparison that can answer the mechanism question
- RMP.Application:1.3 - Second fork — answer the current research-allocation question
- RMP.Application:1.4 - From the selected design to operational choices and actual trace
- RMP.Application:1.5 - From analysis to a relevant credibility examination
- RMP.Application:1.6 - From a corpus answer to the exact model return
- RMP.Application:3 - APP-RMP-03 — Factory-closure historical transfer probe
- RMP.Application:4 - APP-RMP-04 — Retain the Method and correct its research consequence
RMP.Application:5 - APP-RMP-05 — Should a second approver reduce customer waiting?
- RMP.Application:5.1 - Find the question that matters
- RMP.Application:5.2 - Obtain records that preserve the needed distinction
- RMP.Application:5.3 - Separate a delay forecast from an intervention effect
- RMP.Application:5.4 - Ask for a comparison the organization can obtain and run
- RMP.Application:5.5 - Decide whether the study is worth obtaining
- RMP.Application:5.6 - Use the returned analysis at the strength it supports
- RMP.Application:5.7 - Change the shared-queue condition
- RMP.Application:5.8 - Keep the threats connected to actual decisions
- RMP.Application:6 - Restore a service while investigating an unresolved mechanism
- RMP.Application:End
Semantic Integration Engineering Principles Framework
A domain pattern language for making separately governed meanings and representations usable together for a named receiving use.
Contents · 12 patterns in Semantic Integration Engineering Principles Framework
- Table of Contents
Semantic Integration Engineering Principles Framework Architectural Reference
- SIE.Reference:1 - Meanings, identifiers, claims, carriers, and world-side referents remain distinct
- SIE.Reference:2 - Source authority and receiving authority remain separate
- SIE.Reference:3 - Pattern relations do not prescribe a lifecycle
- SIE.Reference:4 - The first whole result
- SIE.Reference:5 - Use the repertoire at the scale of the missing result
- SIE.Reference:8 - Costs, perspectives, and correction
- SIE.Reference:9 - Before relying on the whole result
- SIE.Reference:10 - Intended use and ordinary non-use
- SIE.Reference:11 - PatternID and reader order
- SIE.Reference:12 - Supplied pattern repertoire
- SIE.Reference:13 - Package anatomy and direct result relations
- SIE.Reference:14 - Pattern selection and first returned result
- SIE.Reference:15 - Related modeling and engineering work
- SIE.Reference:16 - FPF, neighboring practice, and authority boundaries
- SIE.Reference:17 - Representative case coverage
- SIE.Reference:18 - Publication boundary
- SIE.Reference:End
Part I - Semantic Integration Engineering Methods
- SIE.1 - Bound the Receiving Use and Semantic Contract
- SIE.2 - Recover and Qualify Source Semantics and Authority
- SIE.3 - Construct or Reuse a Semantic Model for a Named Use
- SIE.4 - Judge Cross-Source Correspondences and Their Permitted Uses
- SIE.5 - Resolve Cross-Source Identity without Erasing Identifier Authority
- SIE.6 - Fuse Source-Qualified Claims without Erasing Conflict
- SIE.7 - Specify Semantic Extraction and Transformation Mappings
- SIE.8 - Choose Virtual, Materialized, or Hybrid Semantic Realization
- SIE.9 - Connect a Receiving Use through a Semantic Interface
- SIE.10 - Validate a Semantic Integration Result for Its Receiving Use
- SIE.11 - Trace Semantic Change and Revalidate Affected Uses
- SIE.12 - Govern Modular Semantic Commons without Universal Authority
Cross-Pattern Application
- SIE.Application:1 - APP-SIE-01 - AP242 and QIF product-lifecycle query
- SIE.Application:2 - APP-SIE-02 - Semiconductor identity and traceability
- SIE.Application:3 - APP-SIE-03 - End-to-end quality and provenance
- SIE.Application:4 - APP-SIE-04 - High-change provider availability without a materialized graph
- SIE.Application:5 - APP-SIE-05 - A Modular Equipment-Classification Commons
- SIE.Application:End
Somatic Movement Modeling DPF
A pattern language for understanding, learning and changing the bodily contribution to a skilled human movement.
Contents · 5 patterns in Somatic Movement Modeling DPF
- Table of Contents
Somatic Movement Modeling DPF Architectural Reference
- SOM.Reference:1 - Problem frame and scope
- SOM.Reference:2 - How the methods work together
- SOM.Reference:3 - A connected worked use
- SOM.Reference:4 - The simultaneous vertical of movement
- SOM.Reference:5 - Interpreting results and choosing further work
- SOM.Reference:6 - Rationale, source use and alternatives
- SOM.Reference:7 - Companion publications and dependencies
- SOM.Reference:End
Strategy Principles Framework
Each pattern starts with a recognizable working situation, the useful result and an ordinary non-use boundary. Its Solution explains the action; its case makes a consequential choice or stop visible. Conformance and evidence guidance help test the particular result without turning recognition into proof.
Contents · 17 patterns in Strategy Principles Framework
- Table of Contents
Strategy Principles Framework Architectural Reference
- STR.Reference:1 - Problem frame - Direction and commitment under changing conditions
- STR.Reference:2 - Problem - From attractive intentions to responsible choices
- STR.Reference:3 - Forces - What the comparison must hold together
- STR.Reference:4 - Solution - Connect the results the question needs
- STR.Reference:5 - Recognition and assurance - Understand the move, then support the claim
- STR.Reference:6 - Archetypal grounding - Three unlike applications
- STR.Reference:7 - Bias-Annotation - Whose contribution and whose burden?
- STR.Reference:8 - Conformance Checklist - Correct use of the connected language
- STR.Reference:9 - Common Anti-Patterns and How to Avoid Them
- STR.Reference:10 - Consequences - What changes in practice?
- STR.Reference:11 - Architectural Rationale - Why a connected repertoire?
- STR.Reference:12 - SoTA-Echoing - Current contributions, bounded transfers
- STR.Reference:13 - Relations - Obtain the professional results the decision needs
- STR.Reference:14 - Strategic-method synthesis
- STR.Reference:15 - Framework guidance and professional results
- STR.Reference:16 - Refresh the smallest affected use
- STR.Reference:End
Part IV - Revisit and Sustain Strategic Practice
- STR.12 - Observe Signals to Continue or Reconsider Strategic Direction and Commitments
- STR.13 - Choose and Maintain Strategy Methods
- STR.14 - Reconcile Simultaneous Strategic Work Across Horizons and Scales
- STR.15 - Deliberately Continue and Change Strategy Culture
- STR.16 - Construct a Feasible Portfolio with Shared or Branch-Specific Support
- STR.17 - Investigate Technological Change for Strategic Possibilities
Cross-pattern applications
STR.Application:1 - APP-STR-01 - Choose SensorCo’s response to commoditized AI inspection
- STR.Application:1.1 - The opening decision
- STR.Application:1.2 - Frame the uncertainty and preserve a serious rival
- STR.Application:1.3 - Use different futures because they change the comparison
- STR.Application:1.4 - Decide whether more inquiry is worth doing
- STR.Application:1.5 - Make the whole proposed arrangement visible
- STR.Application:1.6 - Select only the supported commitment
- STR.Application:1.7 - Reconsider in time and preserve independent work
- STR.Application:1.8 - Sustain useful methods and cultural practice separately
- STR.Application:2 - APP-STR-02 - A professional considering a new practice
- STR.Application:3 - APP-STR-03 - A public service under deep uncertainty
- STR.Application:End
Systems Engineering Principles Framework
A domain pattern language for bringing about and changing engineered Systems, from their intended use and architecture to realization, assurance, and continuing development.
Contents · 53 patterns in Systems Engineering Principles Framework
- Table of Contents
Systems Engineering Principles Framework Readme
Practical entries
- SYSE-CARD-01 — Release a mixed physical-and-software change without losing service, configuration, or evidence
- SYSE-CARD-02 — Develop a problem portfolio and System family without freezing either
- SYSE-PLATFORM-PATH — Make an engineering task easier without losing its usable result
- SYSE-LLM-PATH — Choose and use a way to complete the task
- Citation
Systems Engineering Principles Framework Architectural Reference
- SYSE.Reference:1 - Choose a useful result and combine its needed contributions
- SYSE.Reference:2 - One System can appear in several engineering structures
- SYSE.Reference:3 - Use and System concepts stay linked
- SYSE.Reference:4 - Realization is recursive and continuous
- SYSE.Reference:6 - Configuration and evidence travel with continuing change
- SYSE.Reference:7 - A Method has several structures; Work can be simultaneous
- SYSE.Reference:8 - How project Work contributes to engineering culture
- SYSE.Reference:9 - Architectural Rationale
- SYSE.Reference:10 - Check the combined engineering answer
- SYSE.Reference:11 - Scope and specialist boundaries
- SYSE.Reference:12 - Intended use and non-use boundary
- SYSE.Reference:13 - PatternID discipline
- SYSE.Reference:14 - Source use and epistemic status
- SYSE.Reference:15 - Shared engineering sources and architectural choices
- SYSE.Reference:16 - Dependence on FPF and neighbouring products
- SYSE.Reference:17 - Edition scope and refresh
- SYSE.Reference:End
Part I - Project Focus, Environment, Consequences, and Problem/System-Family Development
- SYSE.1 - Choose and Reopen the Project System-of-Interest
- SYSE.16 - Recover the Systems and Conditions Needed for a Use Decision
- SYSE.17 - Find Systems That May Bear Engineering Consequences
- SYSE.2 - Develop Linked Use and System Concepts
- SYSE.22 - Coevolve Engineering Problems and System-Family Options
Part II - Architecture, Descriptions, Offerings, and Professional Contributions
- SYSE.5 - Develop an Engineered System’s Functional Organization and Bearer Alternatives
- SYSE.6 - Decide and Reopen the Engineering Architecture
- SYSE.7 - Keep Engineering Descriptions Usable Together for Decisions
- SYSE.8 - Develop an Integrated Offering and Provider Concept for Using an Engineered Result
- SYSE.9 - Use or Request Specialist Engineering Results
- SYSE.10 - Assess Research, Model, and Trial Results for an Engineering Decision
Part III - Obtaining Engineering Results, Recursive Realization, Platforms, Independent Constituents, and Evolvability
- SYSE.24 - Choose How the Project Will Obtain a Needed Engineering Result
- SYSE.3 - Plan the Next System-Realization Action (Recursive Realization Network)
- SYSE.11 - Integrate a System for One Bounded Use
- SYSE.12 - Develop or Retain an Engineering Platform for Practitioner Work
- SYSE.18 - Decide Whether and How to Integrate Systems Governed by Different Agents
- SYSE.23 - Choose What to Change So Later System Changes Become Easier
Part VI - Platform Engineering: Supported Use and Continuing Change
- SYSE.25 - Decide Whether and How to Improve a Platform from Practitioner-Task Evidence
- SYSE.26 - Design a Supported Platform-Use Path
- SYSE.27 - Evolve Platform Interfaces and Contribution Paths
- SYSE.28 - Place Qualified Controls in a Supported Platform-Use Path
- SYSE.29 - Decide Whether and How to Migrate or Retire a Supported Platform Path
- SYSE.53 - Resolve a Usable Composition of Independently Released Components
Part VII - Software Platform Engineering
- SYSE.30 - Make Software Builds Repeatable and Traceable
- SYSE.31 - Keep Software Feedback and Continuous Integration Fast and Trustworthy
- SYSE.32 - Promote Verified Artifacts without Rebuilding
- SYSE.33 - Provide Reconstructible Software Development and Test Environments
- SYSE.34 - Change Software and Persistent Data with a Recovery Boundary
- SYSE.35 - Control Software Release Exposure with User-Relevant Signals
- SYSE.36 - Measure User Tasks and Set Software-Service Reliability Objectives
- SYSE.37 - Alert on Actionable Software-Service Reliability Risk
- SYSE.38 - Diagnose and Restore a Failed Software-Platform Task
- SYSE.39 - Decide Whether and How to Reduce the Total Burden of Repetitive Platform Work
- SYSE.40 - Protect Software Platform Capacity and Isolate Failure
- SYSE.41 - Deploy a Verified Software Artifact with the Target Configuration and Handle Partial Failure
Part VIII - Engineering Agent Work and Support
- SYSE.42 - Use a Selected Tool and Apply Its Result
- SYSE.43 - Maintain External Memory for Continuing Work
- SYSE.44 - Divide and Recombine Work across Agents
- SYSE.45 - Train an LLM Policy from Qualified Interaction Experience
- SYSE.46 - Test an Agent and Its Support in Representative Work
- SYSE.47 - Construct and Revise an Agent’s Execution Procedure
- SYSE.48 - Construct and Maintain Reusable Tools and Procedures
- SYSE.49 - Construct Informative Tasks and Feedback Environments for Agent Work
- SYSE.50 - Construct and Calibrate an Agent’s Assistance Policy
- SYSE.51 - Construct Adaptive Control of Reasoning and Tool Effort
- SYSE.52 - Prepare Working Material and Tools for an Agent’s Next Step
Cross-Pattern Applications
SYSE.Application:3 - APP-SYSE-03 — Worked application: choose and bound an authentication-service migration
- SYSE.Application:3.1 - 1. Fix the System, use, and decision
- SYSE.Application:3.2 - 2. Compare architecture alternatives using displayed evidence
- SYSE.Application:3.3 - 3. Bind the recommendation to configuration, effectivity, and evidence
- SYSE.Application:3.4 - 4. What transfers and what remains specialist
- SYSE.Application:3.5 - Result, stop, and reopen
SYSE.Application:4 - APP-SYSE-04 — Worked application: obtain climate control for a new greenhouse configuration
- SYSE.Application:4.1 - 1. Fix the System, use, and result to obtain
- SYSE.Application:4.2 - 2. Construct complete obtaining arrangements
- SYSE.Application:4.3 - 3. Restore parity and choose the next probe
- SYSE.Application:4.4 - 4. Continue with realization, configuration, and assurance
- SYSE.Application:4.5 - Result, stop, and reopen
SYSE.Application:5 - APP-SYSE-05 - Worked application: construct a supported software build-and-delivery path
- SYSE.Application:5.1 - Initial situation and available means
- SYSE.Application:5.2 - 1. Derive an improvement and compare repaired obtaining arrangements
- SYSE.Application:5.3 - 2. Construct the supported interaction and provider relation
- SYSE.Application:5.4 - 3. Produce trustworthy integration, build and artifact results
- SYSE.Application:5.5 - 4. Construct a compatible data change and its recovery boundary
- SYSE.Application:5.6 - 5. Produce and test an actual runtime
- SYSE.Application:5.7 - 6. Measure the right tasks and evaluate exposure
- SYSE.Application:5.8 - 7. Recover, reduce burden and resolve migration
- SYSE.Application:5.9 - Result, stop and direct-entry variations
SYSE.Application:6 - APP-SYSE-06 - Worked application: qualify a machining path with an external operation
- SYSE.Application:6.1 - Initial situation and the two users
- SYSE.Application:6.2 - 1. Select an improvement and retain the whole obtaining comparison
- SYSE.Application:6.3 - 2. Construct the supported transfer and its failure return
- SYSE.Application:6.4 - 3. Construct the independent-provider relation and contribution path
- SYSE.Application:6.5 - 4. Place the decisive dimensional control and expose what it still lacks
- SYSE.Application:6.6 - 5. Separate nominal cycle arithmetic from qualified delivery capability
- SYSE.Application:6.7 - 5.1. Compare independent preparation and a transferable setting
- SYSE.Application:6.8 - 6. Recover physical work and make exit real
- SYSE.Application:6.9 - Result and practical change
- SYSE.Application:End
References and other texts
- Engineering DPF Suite
Methods for designing, realizing, changing and sustaining functioning systems.
- Engineering DPF Suite Architectural Reference
Understand the Engineering Suite’s composition and boundaries, find a method for your working question, and see how methods from different fields contribute to one decision.
- Foundational Thinking DPF Suite
Mathematical Thinking · Mathematical Modeling · Physical Thinking · Computational Thinking · Notational Engineering
- Foundational Thinking DPF Suite Architectural Reference
Find the mathematical, physical, computational, modeling or notational contribution your question needs, and understand how the contributions work together.
- Human Capability Engineering DPF Suite
Human Capability Engineering connects knowledge of how people change with Methods for forming, changing, restoring and sustaining their capabilities. The human is the holder whose capability is at issue; a teacher, assisting AI or provider organization may perform part of the work.
- Human Capability Engineering DPF Suite Architectural Reference
This account explains the Human Capability Engineering DPF Suite to people and capable assisting agents choosing or connecting its Methods. It describes the learning and somatic part supplied by HCD and SOM, the larger engineering subject to which that part contributes, and the boundaries that change a user's next move. A familiar Method can be used directly without reading the account in order.
- Management DPF Suite
Management connects direction, commitments, provision and performance so that a collective undertaking can make and sustain promises under actual conditions. The undertaking can be a business, public service, temporary collaboration or voluntary community. A shared employer is unnecessary; the contributions, authority and resources on which others rely must have an actual basis.
- Management DPF Suite Architectural Reference
Management concerns choosing and sustaining the direction, commitments and provision of a collective undertaking, and changing them when the results or conditions warrant it. The undertaking may be a company, public service, professional practice, temporary collaboration or voluntary community. Its participants can have different purposes and decision rights. A shared employer is unnecessary; an actual basis for making and relying on a contribution is necessary.