PRITECHK / GOVERNANCE ENGINEERING

Intent. Structure.
Accountable action.

A framework for turning obligations into connected models, executable logic and verifiable outcomes.

Explore the architecture ↘

01 / THE CONNECTED ARCHITECTURE

Explore the architecture.

SELECT A COMPONENT TO EXPLORE

The same structure applies across data, technology, cyber, clinical and third-party governance.

ARCHITECTURE / 07 COMPONENTS01 / 07

Traceability

TRACEABILITY & AUDITABILITY

Who · What · When · Why · Source · Authority · Version

01 / DEFINE THE BOUNDARYContext model → requirements

02 / THE ENGINEERING FOUNDATIONS

Define the structure.
Specify the behaviour. Verify the result.

A policy states an expectation. Engineering makes its meaning, operation and evidence explicit.

Consider a requirement: “High-risk system changes require independent review before release.” Implementing it requires a shared definition of risk, an identifiable review, a rule that makes review mandatory, a release gate and evidence that the gate operated. Each is a different part of the governance system.

STRUCTURE / GOVERNANCE MODEL

A model defines the things governance needs to reason about.

It specifies the objects, their attributes and their relationships: a system has a risk classification; a requirement applies to that system; a control addresses the requirement; evidence supports an assessment; an authorised decision permits an action.

Here, model means a structured representation of governance, not a machine-learning model. It can be maintained in linked registers, a relational database or a graph.

In the release example

System SYS-042 is classified High. REQ-021 applies to SYS-042. CTRL-011 requires an independent review. EVD-102 records the review. DEC-008 records the release determination.

What makes it engineered

Stable identifiers, defined field meanings, relationship constraints, accountable owners and versions make the structure consistent and traversable.

The model defines what exists and what it means. Rules and decision logic evaluate that structure. Controls, mechanisms and workflows act on it. Evidence allows the result to be assessed.

03 / FROM POLICY TO OPERATION

One requirement. Six engineering artefacts.

Follow the same generic release requirement through the model, logic, control and evidence.

This example governs a system change. It applies whether or not that system uses AI. Each step adds a different kind of precision; none substitutes for the others.

Design time

Define the schema, requirements, rules, controls, roles, evidence criteria and allowed transitions. Review and test them as a coherent configuration before activation.

Run time

Apply the approved configuration to an actual case. Capture facts, evaluate the applicable rules, obtain the authorised decision, execute the action and retain the evidence of what happened.

FROM INTENT TO ACTION

Make the decision logic inspectable.

Change the facts and observe which rule determines the next permitted state.

Try a release decision

Illustrative internal policy. This demonstration does not authorise a real release.

Risk classificationValidation evidence Independent review completed Decision authority confirmed

ILLUSTRATIVE DECISION / DEC-008

A recorded determination must also preserve scope, rationale, evidence versions, conditions, owner and reassessment triggers.

The decision table behind the demonstration

All gates are evaluated. When several are unmet, this illustrative configuration displays the first applicable result in the order below and lists every unmet gate. That precedence is an explicit design choice, not a universal governance rule.

Priority / Rule	Condition	Result	Required response
1 / R1	Mandatory control failed	Block	Remediate and reassess; this demonstration has no exception path.
2 / R2	Required evidence missing	Defer	Obtain relevant evidence and assess its sufficiency.
3 / R3	Authority not confirmed	Escalate	Route to a person with the required delegated authority.
4 / R4	High risk AND independent review incomplete	Review required	Complete the required review before proceeding.
5 / R5	Evidence accepted AND authority confirmed AND applicable review complete	Ready for determination	An authorised owner assesses residual risk and records a decision.

A full implementation must also define applicability, unknown values, evidence expiry, conflicts between sources, and permitted exceptions. Those cases are discussed below; this demonstration intentionally covers a bounded set of known inputs.

Context & requirements→Risks & controls→Evidence→Assessment→Authorised decision→Action & outcome

EVIDENCE BY DESIGN

Follow the evidence.

A log becomes useful evidence when its relevance and quality are assessed.

THE FRAMEWORK IN PRACTICE

Clinical knowledge assistant

An illustrative hospital use case, from context to controlled change.

Knowledge support using approved policies; patient-specific treatment decisions are outside scope. Requirements are hypothetical internal policy choices.

ENGINEERING QUALITY

What makes the framework operational?

The deliverable is a verifiable governance system, with defined behaviour and accountable change.

1. Semantic precision

Define terms and field values before writing logic. “High risk”, “independent”, “accepted evidence” and “authorised” need agreed meanings, criteria and accountable owners.

2. Complete decision behaviour

Specify true, false and unknown states; rule overlaps; no-match cases; and escalation. A missing risk classification must not be treated as Standard risk simply to complete a workflow.

3. Proportionate authority

Match control intensity and decision rights to impact and uncertainty. Exceptions need a permitted basis, bounded scope, compensating controls, authority and expiry. Some requirements cannot be waived.

4. Verifiable control operation

Test control design and observed operation separately. Check whether the review was independent and sufficiently scoped, not only whether a file was uploaded or a checkbox selected.

5. Traceable configurations

Record the context, requirement, rule and evidence versions used for each decision. Preserve effective dates and supersession links so current and historical configurations can both be reconstructed.

6. Controlled adaptation

Link changes to impact analysis, tests and approval. Review dependent controls and prior decisions. Retain the old record and create a new assessment rather than rewriting history.

Illustrative validation cases

Case	Expected behaviour	What it verifies
High risk; accepted evidence; no independent review	Review required	Risk-dependent gate is enforced.
Standard risk; accepted evidence; authority confirmed	Ready for determination	High-risk review is not imposed where inapplicable.
Control failed; all other gates passed	Release blocked	A positive review cannot bypass a failed mandatory control.
Control failed and authority absent	Block displayed; both failures retained	Explicit precedence without hiding other unmet gates.
Risk classification unknown	Defer classification or escalate under configured policy	Missing facts do not become a favourable default.
Evidence expired or covers another release	Require applicable, current evidence	Presence is not mistaken for sufficiency.
New rule version activated	New cases use the effective version; earlier decisions retain their basis	Change does not overwrite decision history.

Implementation references: OMG Decision Model and Notation 1.5 provides a formal specification for decision modelling. W3C PROV-DM defines provenance entities, activities, agents and their relationships. These are supporting references, not claims that this Pritechk framework is certified against either specification.

FRAMEWORK REFERENCE

Supporting framework reference

1 Purpose and architecture

Governance Engineering translates governance intent into a structured, operational, traceable and adaptive governance system. Its central engineering problem is how to transform requirements written for people into connected models, explicit decision logic, controls and evidence that operate consistently.

The core is domain and technology agnostic. It can be configured for data, cybersecurity, technology, clinical, third-party and other governance domains. It can operate through people and established workflows without an LLM, agent or automated rules engine. [1]

1.1 Design principles

Begin with context and intent. Connect requirements, risks, controls and accountable owners. Apply controls proportionately to impact and uncertainty. Make decision rights explicit, generate evidence during operation and govern changes to the governance system itself.

Governance of AI applies the core to AI as the governed object. AI-Enabled Governance uses AI within governance execution, for example to analyse evidence. These applications can overlap, but neither defines the generic core.

2 Context intent and governance model

2.1 Context

Define the governed activity and its boundaries before selecting controls. Record jurisdiction, industry, organisation, business domain, use case, system or process, users, data, decision role, impact and criticality. Identify assumptions and unresolved facts; uncertainty must remain visible to later decisions.

2.2 Governance Intent

Translate policy, regulation, standards, contracts, risk appetite, principles and objectives into structured requirements. Preserve the source and distinguish the original obligation from its interpretation. An accountable owner validates applicability and resolves ambiguity.

Each requirement specifies an identifier, source and version, applicability condition, required action, timing, owner, evidence and whether an exception is permitted. For example: “High-risk systems require independent review before production” becomes a risk trigger, a review gate and a required review record.

2.3 Governance Model

Connect Context, Requirement, Risk, Control, Owner, Evidence, Assessment, Decision, Action, Outcome and Event as identifiable objects. A requirement may have several controls; one control may address several requirements. Ownership and applicability are explicit relationships, not inferred from a folder location.

Trace forward from a source requirement to a decision and outcome, or backwards from an incident through the affected system, control and risk to its requirement. The model is a relationship structure, not a mandatory linear database design.

3 Logic mechanisms and execution

3.1 Logic & Mechanisms

Make the conditions for action explicit enough to interpret, execute, test and evidence. Rules may be implemented in software, checklists, approval procedures or a combination. Record dependencies, thresholds, escalation routes and the authority needed for exceptions.

Mechanism	Illustrative operational rule
Rule	If risk is high, require independent review before release.
Condition	If personal information and an external service are involved, require a privacy assessment.
Threshold	If residual risk exceeds approved appetite, escalate to the designated authority.
Dependency	Release requires completed security, privacy and validation reviews where applicable.
Exception	A failed mandatory control blocks release unless the requirement permits an exception and an authorised, scoped, unexpired exception exists.

An exception records rationale, compensating controls, owner, expiry and review conditions. It cannot override a non-waivable obligation. Test rule boundaries, missing inputs, conflicting requirements and expired approvals before activating the configuration.

3.2 Decision & Execution

Assign each activity to an appropriate execution mechanism. Deterministic systems check explicit rules and gates. AI can assist with interpretation, classification and evidence analysis. People exercise accountable judgement, challenge recommendations and accept risk within delegated authority.

A combined workflow can validate submitted evidence, obtain an AI-assisted assessment, route it to an authorised reviewer and record the decision. Separate a recommendation from authorisation, and authorisation from execution. Capture failed actions and retries as well as successful completion.

4 Governance decision model

A decision is a first-class governance object. It states who authorised what, for which scope, against which requirements, using which evidence and subject to which conditions. “Approved” alone is an incomplete governance record.

Record element	Minimum information
Identity and scope	Decision ID, type, governed object, permitted activity and applicable context version.
Basis	Requirement, risk and control IDs with versions; evidence references; assessment and remaining uncertainty.
Authority	Decision maker, accountable owner, delegated authority and decision timestamp.
Determination	Approve, approve with conditions, reject, defer or escalate; rationale and any dissent.
Conditions and actions	Action owner, due date, verification evidence, expiry and conditions that must hold before execution.
Assistance	AI or other recommendations where used, their provenance and the reviewer’s disposition.
Reassessment	Triggers, review date, status and links to decisions that supersede or revoke this one.

4.1 Decision discipline

Distinguish evidence completeness from evidence sufficiency. A complete submission can still fail the acceptance criteria. If material evidence is missing, contradictory or stale, defer or escalate according to the applicable rules rather than treating absence as assurance.

Conditional approval must specify whether conditions are prerequisites or ongoing obligations. A workflow checks prerequisite completion before enabling the action, then monitors continuing conditions. Breach, expiry or a material context change initiates review and, where configured, suspension.

5 Evidence and monitoring

5.1 Evidence & Monitoring

Evidence substantiates a claim about a requirement, control or outcome. Design evidence collection as part of normal operation. A log entry can become evidence when its relevance, provenance and quality are established; its existence alone does not demonstrate control effectiveness.

Evidence field	Purpose
Identity and linkage	Evidence ID, claim, related requirement/control and governed object.
Provenance	Source, producer or collector, collection method and source version.
Time and coverage	Observation and collection times, period covered, scope and validity or expiry.
Integrity and access	Stable location, integrity check where appropriate, access controls and retention rule.
Assessment	Assessor, criteria, result, limitations, contradictions and follow-up required.

For interoperable provenance, the W3C PROV family provides a model for entities, activities and agents involved in producing information. It is a useful implementation reference, not a required storage technology. [2]

5.2 Monitoring and response

Observe events, controls and outcomes together. Events include incidents and changes; control signals include tests, failures and exceptions; outcome signals show whether governance actions achieved their intended effect. A named owner receives each actionable signal.

Define each indicator’s source, calculation, cadence, threshold, response and escalation route. Examples include overdue reviews, evidence freshness, control failure rates, expired exceptions and unresolved approval conditions. Risk determines monitoring frequency; event-driven reassessment complements scheduled review.

Monitor missing or failed evidence collection as a signal in its own right. A silent collector must not be interpreted as proof that no incidents occurred. Retain assessment results and action closure evidence alongside the original observations.

6 Traceability auditability and observability

Traceability & Auditability is a cross-cutting layer across all seven components. Every material action retains who, what, when, why, source, authority and version. Stable object and correlation identifiers connect design intent with execution, decisions and subsequent change.

Concept	Role in the framework
Logging	Records individual events and their attributes.
Tracing	Connects related events across an end-to-end execution.
Evidence	Supports a specific governance claim, assessment or decision.
Audit trail	Preserves the sequence and authority needed to reconstruct actions and decisions.
Versioning	Identifies the context, requirement, rule or control active at the time.
Provenance	Records where information came from and how it was produced.

6.1 Governance observability

Governance observability is the ability to infer the state and effectiveness of governance from linked signals and records. It combines operational telemetry with requirement coverage, control status, decision conditions, exceptions and outcomes. It should reveal why a workflow stopped, which authority permitted an action and what changed afterwards.

OpenTelemetry distinguishes signals such as traces, metrics and logs. These can support technical instrumentation, while the governance model supplies meaning, accountability and assessment criteria. Telemetry does not by itself establish that governance obligations were met. [3]

Restrict access to records, apply retention rules and preserve corrections without silently replacing history. Capture the inputs, outputs, versions, tool actions and review rationale needed for reconstruction; avoid unnecessary sensitive content. Reconstruction of an AI-assisted decision does not require claiming that its output can be reproduced exactly.

7 Learning adaptation and versioning

7.1 Learn & Adapt

Changes to context, requirements, technology, risks, control performance or evidence can invalidate earlier assumptions. Adaptation begins with an identifiable change or signal, followed by impact analysis across linked governance objects. It ends with an authorised change and verification of its effect.

Impact analysis identifies affected requirements, risks, controls, evidence and prior decisions. Assign an owner and determine whether existing activity may continue during reassessment. Review the proposed change, test affected rules and workflows, approve the release and monitor the result. Adaptation must not silently change its own authority or acceptance criteria.

7.2 Governance versioning

Version the context model, source requirements, risk and control definitions, decision logic, evidence criteria and workflow configuration. Preserve an effective period, approval record, change rationale and relationship to the superseded version. A decision references the versions actually used, not whichever versions happen to be current later.

Version record	Required distinction
Object identity	A stable identifier describes the same object across revisions.
Revision and effectivity	A revision identifies content; effective dates identify when it governs activity.
Change authority	The reviewer, approver, rationale and affected objects explain why it changed.
Activation and recovery	Release checks and a rollback or suspension plan govern deployment.
Historical decisions	Earlier records remain intact; reassessment produces a linked new decision.

The system should answer both “What configuration is active now?” and “What applied when this decision was made?” A policy revision may require new controls and a fresh assessment; it does not retrospectively rewrite the evidence or rationale of an earlier decision.

8 Contextual configuration and worked example

8.1 Configure the generic core

Reuse the object structure and lifecycle while configuring applicability, risk thresholds, controls, evidence, decision rights and monitoring for the actual setting. Jurisdiction → industry → organisation → use case → context instance → requirements and logic → governance configuration. A reusable human-oversight rule still needs a local definition of impact and authorised reviewer.

8.2 Clinical knowledge assistant

Illustrative example. An Australian hospital proposes an assistant that helps clinicians retrieve approved policies. It provides knowledge support; the proposed scope excludes patient-specific treatment decisions. The requirements below are hypothetical internal policy choices, not claims about a named hospital or legal obligations.

Component	End-to-end application
1 Context	CTX-004 v1 records approved-policy retrieval, clinician users, potential safety impact and the boundary excluding patient data.
2 Governance Intent	REQ-021 v1 requires independent review for high-risk releases. REQ-032 v1 requires current approved sources and evidence of validation.
3 Governance Model	RISK-014 links misleading or outdated guidance to CTRL-011 source approval and CTRL-017 validation, with named clinical and technical owners.
4 Logic & Mechanisms	High-risk classification triggers independent review. Failed mandatory validation blocks release. Evidence must cover the proposed configuration.
5 Decision & Execution	Automated checks verify evidence completeness. An independent reviewer assesses sufficiency. The authorised business owner records DEC-008.
6 Evidence & Monitoring	EVD-102–108 link the source inventory, test results and reviews to their versions. Monitor retrieval failures, stale sources, incidents and open conditions.
7 Learn & Adapt	A material source, model, data or use change triggers impact analysis, reassessment and a newly approved configuration.

8.3 Decision and feedback

DEC-008 conditionally approves a limited pilot against CTX-004 v1. Prerequisites are completed independent review and accepted validation evidence. Continuing conditions include incident reporting and monthly review, with named owners and due dates. The decision records rationale, remaining risks and authority; deployment stays blocked until prerequisites close.

An outdated-policy incident subsequently links to CTRL-011. The owner suspends the affected source, reassesses the risk and adds a source-expiry check. Approved CTRL-011 v2 and new evidence support a linked reassessment decision. This is Governance of AI; using AI to summarise review evidence would additionally be AI-Enabled Governance.

9 Implementation and references

9.1 Minimum implementation baseline

Start with one bounded use case and an accountable owner. Agree context and requirements, map controls and evidence, specify decision rights, then test a complete decision and reassessment cycle. A document-based implementation can use the same object IDs and records as an automated one.

Deliverable	Acceptance question
Context and requirements	Are scope, source, applicability, owners and unresolved assumptions explicit?
Connected model	Can each material requirement be followed to controls, evidence, decisions and outcomes?
Rules and workflow	Do gates, authority, exceptions and failed actions behave as intended?
Decision and evidence records	Can a reviewer reconstruct the basis, authority, conditions and versions?
Monitoring and change process	Do meaningful signals reach owners and produce tracked reassessment and approved change?

Use the baseline to test operating effectiveness, not only documentation completeness. Review whether actions close, controls work and outcomes meet the intended objectives. Expand scope only when ownership and the evidence chain remain manageable.

9.2 References

[1] Pritechk. AI and Governance Analysis. Framework development conversation, latest “01 Governance Engineering Framework”, September 2026. Primary conceptual source for the seven components, connected governance objects and application-domain distinction.
Conversation reference: 6aae2117-f144-83ec-a259-92cc60a38030.

[2] World Wide Web Consortium. PROV-Overview: An Overview of the PROV Family of Documents. Working Group Note, 30 April 2013. Supports the provenance concepts in section 5.
https://www.w3.org/TR/prov-overview/

[3] OpenTelemetry. Signals. Documentation, accessed 21 September 2026. Supports the telemetry terminology in section 6.
https://opentelemetry.io/docs/concepts/signals/