Applications

Reality Audit has a common methodological core, but it is not performed in a vacuum. An audit in research encounters different sources, roles, and professional standards from an audit in public administration, media, employment, or artificial intelligence.

An application domain therefore does not determine what is true within the domain. It determines how the common method must be bounded, which professional and legal standards must be respected, which audit types are relevant, and what documentation a responsible finding requires.

The applications architecture is designed to prevent two opposite errors: applying a general method without domain competence, and making the domain's own categories immune from external examination.

Theory, methodology, audit type, application domain, and case answer different questions. When they are conflated, both mandate and conclusion become unclear.

The application domain stands between the general method and the concrete case: it adds domain conditions without making the domain a separate reality or a separate theory of truth.

Every application document will follow the same architecture. The domain may require its own source types, thresholds, and professional standards, but it must not conceal how they are used.

The adaptation must remain traceable from the domain's purpose and norms to the choice of audit types, material, findings, and correction.

1. B1

   Domain and purpose

   Identifies the social or professional domain, the purpose of the arrangement, and the norms or standards governing it.

   Domain boundary, purpose, applicable norms, and explicit exclusions.
2. B2

   Case and mandate

   Bounds the concrete claim, process, decision, or practice under audit and identifies who has which mandate.

   Audit question, period, parties, roles, decision power, and limitations.
3. B3

   Selection of audit types

   Selects one or more of A1–A7 according to the objects and failure modes actually present in the case.

   Primary and supporting audit types with a reason for each selection.
4. B4

   Domain grounds

   Maps sources, standards, professional practice, rights, risks, uncertainty, and relevant counter-material.

   Source register, standards register, competence map, and documented knowledge gaps.
5. B5

   Findings and correction

   Formulates bounded F1–F7 findings and selects correction within mandate, competence, and documented consequence.

   Findings matrix, confidence, contradiction, correction plan, and responsibility.
6. B6

   Review and transfer limit

   Tests the effect of correction and states what may and may not be transferred to other cases or domains.

   Review report, effect data, side effects, and explicit limit on generalisation.

The domain register identifies where dedicated application documents will be developed. Codes D1–D8 are stable references in the publication programme, not rankings.

A domain may require several audit types at once. The lists of primary audits show common combinations, not a prewritten mandate for every case.

Some operational questions cut across every domain and should not be turned into a new D-document or made subordinate to the R6 correction document. Roles and Responsibilities is the first cross-cutting operational guidance for the applications architecture.

The guidance distinguishes person, role, mandate, competence, authorisation, decision power, and responsibility, and makes the chain of responsibility traceable from initiation to control and correction.

A case must not be forced into one audit type where it actually contains several distinct objects. At the same time, the number of audit types should not exceed what the mandate requires.

The combination must be explicit: each audit type needs its own question, material, and role in the combined finding.

The common Standard establishes requirements for traceability, contradiction, and proportionality. The domain additionally determines which sources, professional standards, and competence requirements are relevant.

An application document must not choose between general method and domain standard. It must show how they operate together and what occurs where they conflict.

Reality Audit must make domain authority and domain limits visible, not replace them with the auditor's own role.

Especially in law, health, safety, and other high-risk areas, methodological findings must remain distinct from formal decisions requiring legal authority or regulated professional competence.

Domain documents should lead to worked cases, not merely general advice. A published case must nevertheless be bounded, examinable, and safe to publish.

Cases may be real, anonymised, historical, synthetic, or pedagogical. Their status must be explicit, and synthetic examples must not be presented as actual events.

1. S1

   Case status

   State whether the case is real, anonymised, historical, synthetic, or pedagogical and which material has been withheld.

2. S2

   Mandate and questions

   Formulate one or more bounded audit questions without building the conclusion into their wording.

3. S3

   Domain and audit-type map

   Show which application domain and A1–A7 types are used and the role each type plays in the case.

4. S4

   Sources and counter-material

   Make the source chain, missing material, disagreement, and alternative explanations visible.

5. S5

   Findings matrix

   Connect every F1–F7 finding to identified material, confidence, uncertainty, and relevant contradiction.

6. S6

   Correction and effect review

   Distinguish recommendation, formal decision, implementation, and actual effect, with responsibility and a date for renewed review.

7. S7

   Publication safeguards

   Assess privacy, source protection, copyright, safety, confidentiality, and risk of unfair identification before publication.

This page publishes the common applications architecture. Individual domain documents will follow the same template so that questions, requirements, and findings can be compared without erasing domain differences.

Publication order will be prioritised by the need for clear boundaries, available documentation, and responsible testing — not by which domain is easiest to criticise.