Policy Diagnostics

Use this catalog to identify a reported policy diagnostic and choose a repair. It covers source validation in the language package, editor lints also used by the CLI, and CLI reporting categories. Runtime query and evaluation errors belong to their API contracts.

Errors report source or profile violations. Warnings identify likely mistakes in supported source; they do not prove that a policy is incorrect. For the underlying language contracts, see Language Reference. For local and CI checks, see Testing & Validating Policies.

Diagnostic index

Source errors	Advisory warnings
reserved-type-name	mixed-arity
repeated-declaration-variable	unsafe-head-variable
conflicting-variable-types	singleton-variable
unsafe-negation-variable	duplicate-rule
invalid-constant	undefined-predicate
duplicate-policy-fact	tautological-comparison
invalid-validation-directive	contradictory-comparison
duplicate-validation-directive
reserved-authorization-predicate
authorization-predicate-reference
negated-compound-expression
negated-derived-predicate

For uncoded core errors, search the message prefixes below, including Predicates must have between 1 and 3 arguments, Test facts and assertions must be fully bound, and Unsafe variable. CLI wrappers such as policy-semantic identify reporting categories rather than distinct language rules.

Source and validation errors

The following errors originate in the language package. Consuming tools forward different subsets; entry-specific surface labels identify reporting boundaries. Parse failures can prevent a tool from reporting later semantic errors.

reserved-type-name

Error. Language validation and CLI. A reserved primitive spelling is used as an entity or type name. Alternate casing does not create another primitive type. The editor semantic cross-check does not currently forward this code.

Use canonical int, string, or boolean qualifiers, or choose a genuine entity type name. See Type spellings.

repeated-declaration-variable

Error. Language validation. One declare declaration repeats a documentation slot label. Declaration labels describe positions rather than requiring equal values.

Give each labeled slot a distinct name. Use repeated variables in a rule when values must agree. See Fact declarations.

conflicting-variable-types

Error. Language validation. The same variable has incompatible qualifiers within one scope.

Correct the qualifier, or use distinct variables when the positions represent different values. See Variable qualifiers.

unsafe-negation-variable

Error. Language validation. A comparison inside a negated scope uses a variable without a binding source available in that scope.

Supply the relevant value through the check, a positive condition, or supported equality binding. A local value inside negation does not become an outer output. This error does not prohibit every fresh local in a negated predicate. See Negation binding.

invalid-constant

Error. Language validation. A concrete static policy fact contains an integer outside the supported representation.

Use a signed 64-bit integer. Ordinary source integer literals can also be rejected during parsing, before this validation category is reached. See Literal bounds.

duplicate-policy-fact

Error. Language validation. The same concrete bodyless policy fact is stated more than once.

Remove the duplicate fact. This error concerns static policy source, rather than idempotent application fact writes. See Static policy facts.

invalid-validation-directive

Error. Language validation. A validation directive is malformed, contains an unknown option, or assigns an unsupported value.

Use the supported profile, negation, and strict_arity settings. Host overrides do not suppress malformed source directives. See Validation settings.

duplicate-validation-directive

Error. Language validation. A validation setting key appears more than once in the file, including across separate directives.

Keep one intended source value per key. A host override does not make duplicate keys valid. See Validation settings.

reserved-authorization-predicate

Error. Language validation. Under the authorization profile, source uses the predicate name authorize.

Choose an ordinary application helper name; authorize names the system operation. See Authorization predicates.

authorization-predicate-reference

Error. Language validation. Under the authorization profile, a rule body references terminal allow or deny.

Extract the reusable condition into an ordinary helper and call it from the decision rules. See Reusable conditions.

negated-compound-expression

Error. Language validation. With negation=fact_only, not applies to an unsupported compound or comparison rather than one direct stored-fact predicate.

Express the requirement using a supported stored input or positive condition. Consult the host’s admitted mode before considering broader negation. See Stored-only negation.

negated-derived-predicate

Error. Language validation. With negation=fact_only, the negated predicate’s name and arity has a derivation rule. Concrete static policy facts do not count as derivation rules for this check.

Test the appropriate stored input or express the condition positively. An advisory declaration does not exempt a predicate that also has derivation rules. See Negation modes.

Uncoded validation errors

These language errors have no distinct core diagnostic code. The CLI may report them as policy-semantic; use the message to identify the constraint.

Message prefix or family	Trigger	Repair
Predicates must have between 1 and 3 arguments, got <n>	A predicate or declaration has an unsupported term count	Use one to three terms. See predicates.
Test facts and assertions must be fully bound	A test fixture or assertion contains variables	Use concrete values for the case. See test blocks.
Invalid integer in a test fixture or assertion	A test value is outside the supported integer representation	Use a signed 64-bit integer. The parser can reject literal source earlier.
Unsafe variable '<name>' in rule head: not bound by a positive body condition	A bodyless statement contains variables	Supply concrete data or add a rule body. See static policy facts.

The unsafe-head message can also appear as an advisory editor/CLI lint for a rule with a body. Check severity and context: concrete checks can supply head values in supported rules.

Advisory warnings

mixed-arity is a core language warning. The other entries are editor semantic lints also consumed by the CLI. Warnings describe their actual syntactic checks, rather than a proof about every possible execution.

mixed-arity

Warning. Language, editor, and CLI. One predicate name is used with several supported term counts across declarations, rules, tests, or implicit has_attribute/3 lookups.

Correct an accidental missing term, use distinct names for different relationships, or retain deliberate reuse after checking intent. Different arities remain separate predicates. See Predicate identity.

unsafe-head-variable

Warning. Editor lint and CLI. A rule-head variable has no positive body occurrence. A concrete check can still supply its value, but the rule can be broader than intended.

Check the intended scope and add the missing relationship when appropriate. Test unsupported actions and unrelated resources rather than assuming this warning always means compilation must fail. See Concrete head inputs.

singleton-variable

Warning. Editor lint and CLI. A variable occurs exactly once in a rule with a body, suggesting a typo or missing correlation.

Correct the name or add the intended connection. If the occurrence is deliberate, check that the rule still expresses the required boundary. See Shared variables.

duplicate-rule

Warning. Editor lint and CLI. Rules have the same structure after lint normalization, ignoring their labels.

Remove the duplicate or correct the condition that was intended to differ. Duplicate static facts have a separate error. See Rules.

undefined-predicate

Warning. Editor lint and CLI. A body predicate has no matching name and arity in a rule head or advisory declare declaration.

Fix a typo or declare the intended stored input. Declarations recognize intended vocabulary; they do not enforce stored slot types. See Advisory declarations.

tautological-comparison

Warning. Editor lint and CLI. An equality has syntactically identical operands. Property accesses are excluded because independent lookups can select different values.

Remove the redundant condition or correct the operand. This lint does not establish a general theorem about the policy. See Equality.

contradictory-comparison

Warning. Editor lint and CLI. An equality compares primitive literal spellings classified as different by the lint, or an inequality has syntactically identical operands. Property accesses are excluded from identical-operand matching.

Correct the literal, operand, or operator. The check uses syntax and does not detect every impossible condition or normalize every equivalent literal spelling. See Comparisons.

Syntax and reporting categories

These labels describe how a failure is reported. They are not additional language constraints.

Category	Surface and meaning	Action
policy-read	CLI file or configuration loading failure	Check the path, readability, and CLI configuration.
policy-syntax	CLI language-parser failure; the editor parser cross-check can also use this category	Correct syntax at the reported location using Language Reference.
policy-semantic	CLI fallback for a semantic error without a specific code	Read the message and find the corresponding uncoded error.
policy-warning	CLI fallback for a warning without a specific code	Read the warning message; it is not another named lint.
Uncoded editor syntax messages	Editor parser messages such as an expected token or syntax error	Correct the local syntax. These messages do not form a separate stable code catalog.

Editor and CLI results can differ when their parsers encounter incomplete or malformed source.

Controls and verification

The file-wide strict_arity setting controls only mixed-arity; it is not a switch for all heuristic lints. Defaults and host overrides are defined in Language Reference.

The CLI gates reported warnings by default. --allow-warnings retains them while allowing success when there are no errors; --skip-warnings omits them. Neither flag admits errors. See the validate command for exact flags and structured output, and Testing & Validating Policies for the local and CI workflow.