Layer 5 – Process
0. Introduction
0.1 Purpose
This standard defines the righteous processes you execute when acting within a specific institutional domain — as defined in RSS 37004‑B.2 (Domain Catalog) and elaborated in the 21 Domain Modules (B.4.x). These processes translate the institutional characteristics, core system mappings, and extended factors of your domain (defined in Layer 4B) into standardized, repeatable, and verifiable operational workflows.
0.2 Process Overview
For you, the player, Domain Processes are the institutional‑scale application of the 5.1 Framework. They sit at the intersection of:
- Your Role (5.3) — who you are (e.g., a Doctor, a Teacher, a Financial Advisor);
- Your Domain (4B) — where you operate (e.g., Healthcare, Education, Finance);
- Your Process (5.1) — how you execute standardized workflows.
If 5.2 (People Processes) is your personal foundation, and 5.3 (Role Processes) is your role‑specific execution, then 5.4 (Domain Processes) is the institutional workflow context in which your role operates.
For example:
- Your Employee Role Process (5.3) tells you how to execute a task as an employee.
- Your Healthcare Domain Process (5.4) tells you the specific clinical workflow for patient intake, diagnosis, and treatment — which applies whether you are a Doctor, a Nurse, or an Administrator operating within the Healthcare Domain.
0.3 Relationship to Other Layers
| Layer | How It Relates to Your Domain Processes |
|---|---|
| Layer 1 (Axioms) | Your domain processes must never violate foundational axioms. |
| Layer 2 (Core System) | Your domain processes operationalize the 25 core systems within the specific context of your domain (e.g., the Education System operates differently in the Education Domain vs. the Healthcare Domain). |
| Layer 3 (Factors) | Your domain process outputs must be verifiable against the 30 core factors, adapted to domain‑specific expressions. |
| Layer 4B (Structure — Domains) | This standard directly implements the Domain Characteristics, Core System Mapping, and Extended Factors defined in your domain’s module (B.4.x). |
| Layer 4A (Roles) | Domain processes are executed by the roles defined in 4A.3 (Domain‑Specific Roles). |
| Layer 5.1 (Process Framework) | This standard is a direct application of the 5.1 framework to institutional domains. |
| Layer 5.2 (People Processes) | Your personal processes underpin your domain execution — you bring your personal integrity into every domain process. |
| Layer 5.3 (Role Processes) | Your role processes are executed within domain processes — the role defines who acts, the domain defines the workflow they follow. |
| Layer 6 (Metrics) | Your domain process performance is quantified through Layer 6 indicators, specific to each domain. |
| Layer 7 (Restoration) | When domain processes fail, Layer 7 provides domain‑appropriate restoration pathways (e.g., medical malpractice review, financial regulatory remediation). |
1. Scope
This standard applies to:
- You, when acting within any of the 21 domains defined in RSS 37004‑B.2 (Domain Catalog);
- The design, execution, and improvement of institutional workflows within each domain;
- The adaptation of 5.3 (Role Processes) to the specific institutional context, regulatory environment, and operational characteristics of each domain.
2. Normative References
- RSS 37005‑5.1:2026 — Process Framework
- RSS 37005‑5.2:2026 — People Processes
- RSS 37005‑5.3:2026 — Role Processes
- RSS 37004‑B.1:2026 — Domain Framework
- RSS 37004‑B.2:2026 — Domain Catalog
- RSS 37004‑B.3:2026 — Domain Extended Factors
- RSS 37004‑B.4.x:2026 — Domain Modules (21 modules)
- RSS 37001:2026 — Axioms
- RSS 37002:2026 — Core System
- RSS 37003:2026 — Factors
- RSS 37006:2026 — Metrics Standard (forthcoming)
- RSS 37007:2026 — Restoration Standard (forthcoming)
3. Terms and Definitions
(For you, as a player executing processes within an institutional domain)
| Term | Definition |
|---|---|
| Domain | One of the 21 institutional domains defined in 4B.2 (e.g., Healthcare, Finance, Education, Retail). |
| Domain Process | A standardized workflow designed specifically for a domain, incorporating the domain’s characteristics, core system mappings, and extended factors. |
| Domain Characteristic | A defining feature of a domain — its core functions, primary stakeholders, risk profile, and regulatory context (defined in 4B, Section 4 of each Domain Module). |
| Core System Mapping | The classification of the 25 core systems as Primary, Secondary, or Contextual for a specific domain (defined in 4B, Section 5 of each Domain Module). |
| Extended Factor | A domain‑specific expression of the 30 core factors (defined in 4B, Section 6 of each Domain Module). |
| Domain Stakeholder | Any individual or party affected by domain processes (e.g., patients in Healthcare, students in Education, customers in Retail, citizens in Government). |
| Domain Constraint | A control specific to a domain — derived from domain‑specific law, regulation, professional standards, or institutional policy (e.g., HIPAA in Healthcare, GAAP in Finance). |
4. Domain Process Structure
All Domain Processes must be defined using the following structure, which is an extension of the 5.1 Process Framework components, adapted for institutional domains.
4.1 Generic Domain Process Template
Every domain process you design or execute must specify:
| Component | Domain‑Specific Application |
|---|---|
| Inputs | Domain‑specific triggers (e.g., a patient presenting symptoms for Healthcare; a loan application for Finance; a student enrollment for Education); domain‑relevant information; regulatory documentation; stakeholder requests. |
| Activities | The standardized workflow steps specific to the domain — derived from the domain’s core functions and core system mappings (4B, Sections 4 and 5). |
| Gates | Decision points where you must pause and evaluate against domain‑specific obligations (e.g., “Is this diagnosis supported by clinical evidence?”; “Is this loan application compliant with underwriting standards?”; “Is this grade justified by the student’s performance?”). |
| Outputs | Domain‑specific deliverables (e.g., a diagnosis and treatment plan; a loan approval or denial; a grade transcript; a retail transaction record). |
| Controls | Domain‑specific constraints: regulatory requirements (e.g., financial reporting standards, healthcare privacy laws, educational accreditation standards); institutional policies; professional ethics within the domain. |
| Verification | Domain‑specific checks: clinical peer review; financial audit; educational quality assurance; regulatory compliance inspection. |
4.2 Mapping from Role Processes (5.3) to Domain Processes (5.4)
Your Role Processes (5.3) are executed within Domain Processes (5.4). The relationship is:
| 5.3 Role Process | 5.4 Domain Process (Example) |
|---|---|
| Doctor Role Process (decision‑making as a doctor) | Healthcare Domain Diagnosis Process — the clinical workflow for diagnosing a patient. |
| Teacher Role Process (instruction and assessment) | Education Domain Grading Process — the workflow for evaluating student performance. |
| Manager Role Process (oversight and approval) | Finance Domain Loan Approval Process — the workflow for credit underwriting. |
| Police Officer Role Process (law enforcement) | Public Safety Domain Incident Response Process — the workflow for responding to a call. |
| Retail Associate Role Process (customer service) | Retail Domain Transaction Process — the workflow for processing a sale. |
5. Exemplary Domain Processes (by Domain Category)
This section provides canonical examples for major domain categories. Each domain’s full process suite is elaborated in its respective Domain Module (B.4.x) and may be further detailed in 5.4 sub‑standards (future).
5.4.1 Healthcare Domain Processes
Based on Domain Module B.4.2 — Healthcare
| Component | Patient Intake & Diagnosis Process (example) |
|---|---|
| Inputs | Patient presentation (symptoms, history); patient identity and consent; insurance/coverage information; clinical guidelines; electronic health records. |
| Activities | 1. Register patient and verify identity. 2. Collect medical history and current symptoms. 3. Perform preliminary examination. 4. Order diagnostic tests (if required). 5. Interpret test results. 6. Formulate diagnosis. 7. Develop treatment plan. 8. Communicate diagnosis and plan to patient. 9. Obtain informed consent. 10. Initiate treatment or referral. |
| Gates | At Step 3 — “Is this examination appropriate and within my scope of practice?” At Step 6 — “Is the diagnosis supported by sufficient clinical evidence? Does it align with Layer 3 Factors (e.g., Beneficence, Non‑maleficence)?” At Step 9 — “Has the patient fully understood and consented?” |
| Outputs | Diagnosis documentation; treatment plan; prescribed medications or therapies; patient education materials; referral letters; electronic health record updates. |
| Controls | Clinical guidelines (e.g., WHO standards); healthcare regulations (e.g., HIPAA, privacy laws); professional ethics (Hippocratic Oath); institutional policies; scope of practice limitations. |
| Verification | Peer review; clinical audit; patient outcomes tracking; regulatory compliance inspections (Layer 6 metrics). |
5.4.2 Education Domain Processes
Based on Domain Module B.4.4 — Education
| Component | Student Assessment & Grading Process (example) |
|---|---|
| Inputs | Student work (assignments, exams, projects); assessment criteria (rubrics, learning objectives); student records; institutional grading policies. |
| Activities | 1. Receive student submissions. 2. Evaluate against established criteria. 3. Assign a grade or score. 4. Provide constructive feedback. 5. Record the grade in the student information system. 6. Communicate grade and feedback to the student. 7. Address grade disputes (if any). |
| Gates | At Step 2 — “Is my evaluation fair, consistent, and free from bias (Layer 3 Factors: Equity, Transparency)?” At Step 7 — “Is the student’s dispute valid? Should I escalate to a department head?” |
| Outputs | Grade records; feedback reports; updated student transcripts; resolved grade disputes. |
| Controls | Institutional grading policies; accreditation standards; anti‑discrimination laws; academic integrity policies. |
| Verification | Grade audits; student feedback on assessment; external examiner reviews; institutional accreditation reviews. |
5.4.3 Finance Domain Processes
Based on Domain Module B.4.3 — Finance
| Component | Loan Underwriting & Approval Process (example) |
|---|---|
| Inputs | Loan application; applicant financial data (income, credit history, assets, liabilities); credit scoring models; underwriting guidelines; regulatory requirements. |
| Activities | 1. Receive and log application. 2. Verify applicant identity and documentation. 3. Assess creditworthiness (review credit history, income, debt‑to‑income ratio). 4. Apply underwriting criteria. 5. Make an approval/denial decision. 6. Communicate decision to applicant. 7. If approved, prepare loan documents. 8. Disburse funds. |
| Gates | At Step 3 — “Is the applicant’s financial profile accurately represented?” At Step 5 — “Does this decision comply with fair lending laws and Layer 3 Factors (e.g., Fairness, Transparency)?” |
| Outputs | Approval/denial decision; loan agreement; disbursement record; compliance documentation. |
| Controls | Banking regulations; fair lending laws; internal underwriting policies; anti‑money laundering (AML) requirements; privacy laws. |
| Verification | Internal audit; regulatory compliance review; loan performance monitoring (default rates); customer complaint handling. |
5.4.4 Retail Domain Processes
Based on Domain Module B.4.12 — Retail
| Component | Consumer Transaction & Return Process (example) |
|---|---|
| Inputs | Customer purchase request; product selection; payment method; return request (if applicable); loyalty program information. |
| Activities (Purchase) | 1. Assist customer with product selection. 2. Process the transaction (scan, verify price). 3. Receive payment. 4. Provide receipt and product. 5. Log transaction. |
| Activities (Return) | 1. Receive returned product. 2. Verify return eligibility (timing, condition, receipt). 3. Process refund or exchange. 4. Update inventory records. 5. Log return transaction. |
| Gates | At Step 2 of Return — “Is this return legitimate and within policy? Does it uphold the principle of fairness to both customer and institution?” |
| Outputs | Transaction receipt; payment confirmation; inventory update; refund confirmation; customer satisfaction record. |
| Controls | Consumer protection laws; return policy; payment processing security (PCI‑DSS); fraud prevention measures. |
| Verification | Inventory audits; customer feedback; transaction log reviews; fraud detection monitoring. |
6. Application of the Process Lifecycle (from 5.1)
For each Domain Process you define or execute, you follow the same seven‑phase lifecycle:
| Phase | Your Action |
|---|---|
| 1. Design | Define the domain process using the template in Section 4.1, anchored to the domain’s characteristics and core system mappings from 4B. |
| 2. Approval | Submit the domain process for institutional and/or regulatory approval (e.g., clinical governance for Healthcare; academic board for Education; board of directors for Finance). |
| 3. Publication | Publish the domain process to all relevant stakeholders (e.g., clinical staff, faculty, financial officers, retail staff). |
| 4. Execution | Run the process in operational settings whenever the domain situation arises. |
| 5. Monitoring | Use Layer 6 domain‑specific metrics to track process effectiveness, compliance, and outcomes. |
| 6. Review & Optimization | Periodically review domain processes — consult stakeholders, analyze outcome data, incorporate regulatory changes, and improve. |
| 7. Deprecation | Retire a domain process when the domain changes (e.g., new regulations, technological disruption) or the process is no longer relevant. |
7. Conformance Requirements
To claim conformance to this standard, you (as a player operating within a domain) must ensure that your domain processes satisfy the following requirements:
| ID | Requirement |
|---|---|
| CFR‑5.4‑01 | Each domain process must explicitly define all five components: Inputs, Activities, Outputs, Controls, and Verification Mechanisms. |
| CFR‑5.4‑02 | Each domain process must include at least one Gate requiring a domain‑specific ethical or regulatory decision. |
| CFR‑5.4‑03 | Each domain process must include in‑process verification appropriate to the domain (e.g., clinical peer check, financial review, educational quality check). |
| CFR‑5.4‑04 | Each domain process must explicitly map to the relevant Domain Module (B.4.x) and align with the domain’s Core System Mapping (4B, Section 5) and Extended Factors (4B, Section 6). |
| CFR‑5.4‑05 | Each domain process must incorporate the Domain‑Specific Roles defined in 4A.3 (and 4B, Section 7 of each module) as the designated executors. |
| CFR‑5.4‑06 | Each domain process must include explicit timing expectations appropriate to the domain (e.g., clinical response times, financial settlement cycles, academic grading timelines). |
| CFR‑5.4‑07 | The outputs of each domain process must be quantifiable and evaluable by Layer 6 (Metrics) standards, specifically the domain‑specific metrics defined or referenced in the domain module. |
| CFR‑5.4‑08 | Each domain process must define a clear escalation path for failures, linking to Layer 7 (Restoration) and referencing both the 5.2 Self‑Correction Process (personal accountability) and the 5.3 Role Correction Process (role‑specific accountability). |
8. Relationship to Other Layers
| Target Layer | How Your Domain Processes Connect |
|---|---|
| Layer 1 (Axioms) | Your domain processes must never violate foundational axioms — domain operations do not exempt you from fundamental righteousness. |
| Layer 2 (Core System) | Your domain processes operationalize the 25 core systems within the specific context of your domain. The Primary/Secondary/Contextual mapping from 4B, Section 5, directly informs which systems are central to your process. |
| Layer 3 (Factors) | Your domain process outputs must be verifiable against the 30 core factors, expressed through the domain‑specific Extended Factors (4B, Section 6). For example, “Transparency” in Healthcare means informed consent; in Finance, it means clear disclosure of terms. |
| Layer 4A (Structure — Roles) | Domain processes are executed by Domain‑Specific Roles (4A.3). The role definitions determine who performs which activities within the domain workflow. |
| Layer 4B (Structure — Domains) | This standard is the direct operationalization of your Domain Module (B.4.x). The Domain Characteristics (4B, Section 4) inform the process design; the Core System Mapping (4B, Section 5) informs activity selection; the Extended Factors (4B, Section 6) inform verification mechanisms. |
| Layer 5.1 (Process Framework) | This standard instantiates the 5.1 framework for institutional domains. |
| Layer 5.2 (People Processes) | Your personal processes underpin all domain execution — your integrity, decision‑making, and accountability as a person carry into every domain process. |
| Layer 5.3 (Role Processes) | Your role processes (5.3) are executed within domain processes. The domain defines the workflow; the role defines who executes which part of that workflow. |
| Layer 6 (Metrics) | Your domain process performance is quantified through Layer 6 indicators — specific metrics for each domain (e.g., patient outcomes in Healthcare, student achievement in Education, loan performance in Finance). |
| Layer 7 (Restoration) | When domain processes fail, Layer 7 provides domain‑appropriate restoration (e.g., clinical peer review for medical errors, academic appeals for grading disputes, financial restitution for fraud). |