# Rules, Policies, Constraints, Goals and Decisions

Status: settled semantic contract, 2026-09-11. Policy composition, conflict handling, enforcement and governed exceptions are settled; evaluator mechanisms are specified separately and remain unbuilt.

Owns: the business meanings of Rule, Policy, Constraint, Goal and Decision, their applicability and relationships. The [core object model and authority](core-object-model-and-authority.md) contract supplies the cross-cutting distinction between descriptive definitions, actual configuration and authoritative adoption. [Objects and types](objects-and-types.md) owns typed validity; [identity and governance](identity-and-governance.md) owns permission and approval enforcement; [workflows and automation](workflows-and-automation.md) owns runtime evaluation and execution.

Lineage: the semantic concepts named in source 02 sections 2, 3 and 11, source 01's knowledge/ownership/evolution principles, source 03's examples and the final D04 clarification. See the [source ledger](../governance/source-map.md#final-architecture-integration).

## Distinct Conceptual Meanings

| Concept | Meaning | Question it answers |
|---|---|---|
| Rule | An explicit statement connecting conditions to a conclusion or prescribed response in a defined context. | Given these facts, what follows or should be considered? |
| Policy | An authoritative statement of business intent or governance that guides permitted or required behavior within an applicability scope. | What position has the business adopted, and where does it apply? |
| Constraint | A condition that limits acceptable values, states or actions within its scope. | What must remain true for this candidate to be admissible? |
| Goal | A desired result against which progress or outcomes can be assessed. | What are we trying to achieve, and how will we judge it? |
| Decision | A recorded determination among alternatives or about a proposal, with its context, authority and rationale. | What was decided, by whom or what authority, on what evidence, and why? |

These are distinct meanings, not five competing storage primitives or a requirement for five separate engines. Their independently addressable representations all use the universal model and connect within the [Business Graph](business-model.md).

A policy may motivate rules and constraints; a goal may motivate a proposal; a decision may accept or reject it. These relationships do not establish type inheritance, an evaluation order or an override hierarchy.

## Rule

A rule makes a conditional relationship inspectable. For example: if an enquiry concerns equipment servicing, propose a service follow-up task and make the relevant procedure available to the responsible person.

Rules can support derivation, classification, validation or workflow routing. The intended effect must be explicit: calculating a suggested classification is different from updating an authoritative field or executing an external action.

A rule declaration does not itself execute. The relevant deterministic responsibility interprets a supported rule representation, checks its applicability, and handles the resulting conclusion or proposed action under governance. A derived conclusion or suggested configuration remains distinct from an authoritative mutation or an adopted definition.

Rules and decisions operate within the universal Data, Workflow and Logic model. They do not introduce a separate variable, calculated-field, binding or Logic system. Where evaluation assigns a retained reference or a resolved value, it uses the common governed assignment/mutation mechanism and preserves the applicable provenance and authority evidence.

Rule definitions may connect to relevant types, knowledge, policies and workflows. A rule copied into several hidden UI handlers would lose shared authority and explanation; it should instead be an inspectable definition where independent identity or lifecycle matters.

## Policy

A policy expresses business authority and intent, not just a Boolean expression. A pricing policy may explain who can approve discounts, which offerings it covers and why the limits exist.

Its source may be an approved document or other [knowledge](knowledge.md). A PDF that says "special discounts require approval" is not automatically an executable permission rule; its interpretation must be made explicit and reviewed before it controls behavior.

Machine-enforceable portions can be represented as related rules or constraints. Narrative explanation can remain knowledge, linked to the policy and relevant business objects, without forcing all policy meaning into scalar fields.

Authority, owner, status, source and applicability must be distinguishable from confidence. An AI interpretation with high confidence is still not an approved company policy.

Policies are first-class addressable objects with explicit versions. Dependency, refinement, exception and supersession relationships are explicit and typed; a relationship alone does not establish precedence. Scope specificity, creation date, author role, confidence or an AI recommendation must not silently determine which Policy wins.

### Composition and Conflict Resolution

Evaluate applicable Policies against Business context, scope, time, conditions and relevant object/action state. Composition and conflict resolution follow explicit governed rules. Where a deterministic resolution is defined, apply it and retain its evidence. Otherwise an authorised human Decision is required before the conflicting operation can proceed. The resolution is itself addressable and auditable, with applicable Policy versions, context, authority and rationale.
[Final D04](../governance/decisions.md#d04) establishes the composition contract. The concrete expression representation, supported operators and demonstrator Policy configuration are specified in [implementation architecture](../implementation/architecture.md#authority-and-policy-mechanism). Tests must preserve conflicts and refuse an exception or relationship that lacks authority. Neither a simpler evaluator nor a human-only first flow may remove Policy/version/Decision distinctions. Neither a simpler evaluator nor a human-only first flow may remove Policy/version/Decision distinctions.
Preserve conflicting Policies rather than silently overwriting them. A new version or a supersession relationship does not rewrite which Policy informed an earlier Action. Resolution changes operative use within its stated scope, not the existence of contrary evidence.

Policy enforcement is required at the authoritative access/action boundary. A governed exception identifies the affected Policy/version, scope, conditions, period and approving authority. The exception relationship is not itself a bypass; its applicability and authorised effect must be evaluated under the explicit composition rules. The [implementation evaluator](../implementation/architecture.md#authority-and-policy-mechanism) supplies a bounded mechanism, not a universal implicit priority ladder.

## Constraint

A constraint limits admissibility. Examples include a required service-inspection result before completion, a permitted lifecycle transition, or a defined spending bound before a proposed purchase can proceed.

Its context matters: a value-shape constraint is checked under [objects and types](objects-and-types.md); authority or approval requirements are enforced under [identity and governance](identity-and-governance.md); an execution prerequisite is evaluated by its runtime owner.

A goal's urgency does not erase a constraint. Likewise, schema validity does not prove that an operation satisfies its business constraints or is authorized.

Any exception mechanism must itself be explicit and governed. This document does not create an implicit administrator override, a universal notion of "soft" constraints or a complete exception language.

## Goal

A goal expresses a desired outcome rather than a command or permission. Examples include reducing enquiry response time, avoiding missed service visits or improving a campaign's measured result.

Useful goal context includes the subject or scope, intended measure, target, observation period, owner and evidence. The exact field structure depends on approved types and [analytics and evolution](analytics-and-evolution.md), which owns measurement and improvement evaluation.

A numeric target is not automatically comparable without its units, period and measurement definition. A budget limit can be represented as a constraint when it limits admissibility; a desired cost reduction can instead be a goal. Meaning, not the presence of a number, distinguishes them.

Optimisation is evaluated against goals within valid authority and constraints. Neither an achieved metric nor a forecast of improvement legitimizes an unauthorized action.

## Decision

A business Decision records a determination, not just an activity label. It should connect the question/proposal, considered evidence, relevant policy or constraints, responsible authority, rationale and resulting determination where those are applicable.

Approval and rejection are possible determinations; approval semantics belong to [identity and governance](identity-and-governance.md). A decision to approve a workflow change is separate from evidence that the change was executed successfully.

Some determinations can eventually be delegated to deterministic automation within authorized configuration. Automation holds no independent authority; it acts under [authority delegated by a User](identity-and-governance.md#delegated-authority-for-automation), with the technical executor recorded as provenance. Recording "the system decided" is insufficient without identifying that delegated authority and the inputs or configuration on which the determination depended.

An AI recommendation is not an authoritative Decision merely because it is worded decisively. It remains a proposal until the appropriate authority accepts or otherwise determines it through the governed path.

Resolving contradictory Assertions produces a Decision or Action linked to the original accounts and their provenance. It does not erase rejected, challenged or superseded Assertions. Recording a Decision, executing its permitted Action and observing the result are distinct occurrences.

Business Decision objects are also distinct from the repository's [architectural decision records](../governance/decisions.md). The latter coordinate human design decisions and update canonical documentation; this document does not prescribe their storage in a running platform.

## Shared-Model Examples

The following examples use symbolic addresses and deliberately illustrative value fields. Referenced types and business concepts are themselves addressable under [objects and types](objects-and-types.md); no identifier encoding or executable expression grammar is approved here.

```text
{ id: policy/service-completion, type: type/policy,
  value: { intent: "Complete servicing only with required inspection evidence",
           appliesTo: type/service-visit, source: document/service-procedure,
           owner: user/operations-owner, status: "approved" } }

{ id: rule/check-inspection, type: type/rule,
  value: { condition: "A service visit is proposed for completion",
           response: "Evaluate the required inspection constraint",
           policy: policy/service-completion } }

{ id: constraint/inspection-evidence, type: type/constraint,
  value: { condition: "Required inspection results are recorded",
           appliesTo: type/service-visit, policy: policy/service-completion } }

{ id: goal/service-timeliness, type: type/goal,
  value: { intent: "Reduce missed service visits", measure: metric/missed-visits,
           period: "agreed review period", owner: user/operations-owner } }

{ id: decision/review-service-workflow, type: type/decision,
  value: { proposal: proposal/service-follow-up, determination: "approved",
           authority: user/operations-owner, goal: goal/service-timeliness,
           evidence: report/missed-visits, rationale: "Add a reviewed reminder step" } }
```

The approved statuses above describe a hypothetical reviewed case, not a default or an assertion that these definitions exist. Narrative conditions remain illustrative until a supported deterministic rule representation has been selected and validated.

Relationships can connect each definition to its source knowledge, affected type, workflow and subsequent outcomes instead of anonymously repeating its content. Independent relationship identity and granularity follow [business-model rules](business-model.md).

The policy expresses intent; the rule identifies when a check is relevant; the constraint states admissibility; the goal establishes improvement intent; the decision records an authorized determination. No example says that the goal overrides the policy or that approval guarantees execution success.

## Authority and Applicability

Before a definition is used, its applicability must be understood: which business/isolation context, types, objects, relationships, activities and time period it concerns, and whether it has the appropriate authority and status for that use.

Applicability can be narrower than visibility. A person may read a policy for reference without that policy governing their current action, and may see a goal without authority to change the associated process.

[Time and events](time-and-events.md) owns effective-time interpretation and historical references. A later Policy edit must not silently become the explanation for a prior Decision when a different version informed it; record the version actually used and re-evaluate current applicability before subsequent effects.

Where applicable Policies conflict or essential context is missing, the platform surfaces the unresolved business situation instead of inventing authority or allowing AI to choose precedence. An unresolved business case is not an undecided architecture: the settled response is the defined deterministic resolution or an authorised human determination, with no ungoverned effect while waiting.

## Evaluation and Execution Boundaries

Semantic definitions supply meaning to reusable responsibilities; this document does not introduce a mandatory Semantic Engine. Deterministic evaluation belongs to the responsibility executing the supported operation, including [workflows and automation](workflows-and-automation.md).

The governance boundary must authorize an intended operation and require relevant approvals, while typed validation checks the proposed values and relationships. A valid shape, a satisfied rule and an approval are separate facts; none replaces the others.

Evaluation must be explainable through the relevant input objects, definition/version references, applicability context and recorded result. Preserve the distinction between a proposed response, an authorized action, an execution result and a measured outcome.

Human-authored, imported, automated and AI-proposed definitions use the same controls. A business can inspect and apply its configured policies, goals and rules without AI; optional inference can help draft or explain them, not become the sole interpreter of business authority.

## Conformance and Implementation

Conforming examples include a workflow referring to an approved policy with linked source knowledge, a constraint rejection explaining missing inspection evidence, and an improvement proposal retaining its goal, review decision and measured outcome.

Nonconforming examples include a goal granting permission, a PDF extraction becoming active policy without review, an AI confidence score establishing authority, or a hidden "most recent policy wins" convention.

[Final D04](../governance/decisions.md#d04) establishes the composition contract. The concrete expression representation, supported operators and demonstrator Policy configuration are specified in [implementation architecture](../implementation/architecture.md#authority-and-policy-mechanism). Tests must preserve conflicts and refuse an exception or relationship that lacks authority. Neither a simpler evaluator nor a human-only first flow may remove Policy/version/Decision distinctions.