Skip to content

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.

The dictionary, recipe, filled card, and bundle used by Axioval

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 may have verified ExternalName bindings. The stable ID is what rules reference; adapters map only authenticated bindings to supported model schemas. Project-local concepts remain explicitly local.

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. Its applicability can be one selector or named target groups, while requirements state what must hold for those groups. Optional explanatory images make the intent easier to understand but never affect execution. Instances are policy, the ABox-like layer, and belong in external ruleset repositories. This MCS 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.

A package is inspected, opened safely, checked completely, and handed to a compatible tool

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.