How Axioval fits together

This page opens the booklet's four ideas and shows what sits behind each one. The simple picture remains the same: shared names, reusable check recipes, completed checks, and a bundle that carries them safely. Technical names appear only where a tool builder needs them.

1. Vocabulary

A definition package can declare three independent concept catalogs:

Concept	Purpose	Example
ObjectTypeDefinition	Reusable model-object type	IFC IfcWall
PropertyDefinition	Reusable property identity and value kind	boolean LoadBearing
PropertySetDefinition	Optional external container qualifier	Pset_WallCommon

Each concept has a stable qualified ID and one or more ExternalName bindings. The stable ID is what rules reference; adapters map it to each supported model schema.

Important

PropertySetDefinition does not list or own properties. A property may appear in multiple external containers. Container membership becomes normative only when a selector or PropertyReferenceValue names a set.

2. Template

A RuleDefinition declares:

• a stable definition ID;
• a stable capability that applications explicitly implement; and
• typed parameter definitions.

Show the Pkl template

["axioval:example.boolean-property-equals"] = new Definitions.RuleDefinition {
  id = "axioval:example.boolean-property-equals"
  capability = "axioval:capability.property-value-equals"
  name = new Types.LocalizedText { default = "Boolean property equals" }
  parameters {
    ["property"] = new Definitions.ParameterDefinition {
      id = "property"
      name = new Types.LocalizedText { default = "Property" }
      kind = "propertyReference"
      referencedValueKind = "boolean"
    }
    ["expected"] = new Definitions.ParameterDefinition {
      id = "expected"
      name = new Types.LocalizedText { default = "Expected" }
      kind = "boolean"
    }
  }
}

referencedValueKind closes a subtle type hole: this boolean template cannot be bound to a string property.

3. Instance

A RuleInstance binds a known definition to concrete values and an applicability selector. Instances are policy, the ABox-like layer, and belong in external ruleset repositories. This schema repository contains them only under examples/.

4. Package and normalization

axioval.json statically identifies the package and every definition entrypoint. Only after all entrypoints are repository-confined and all candidate JSON is semantically bound does the output become normalized interchange.

What Axioval does own

• Shared, stable names for building facts
• Typed, reusable descriptions of checks
• Declarative filled checks that can be shared as data
• A package contract that rejects incomplete or inconsistent input

What Axioval deliberately does not own

• Opening model files or following IFC relationships
• Calculating geometry
• Running executable rule logic supplied by a package
• Replacing an application's trusted internal model
• Trusting a package merely because of who owns its repository

Axioval describes meaning at the exchange boundary. Each application remains in control of model access, algorithms, execution, and trust decisions.