Checks that show their reasons.
Bayesian Logic checks the statements in a document against the norms and evidence that apply to them. It shows every step: the provision, the record, the condition decided for this case, and anything it had to assume.
What Bayesian Logic does
Bayesian Logic reads a text, such as the documentation for a building permit, and breaks it into claims it can check. For each claim it finds the norms and evidence that bear on it as they stood on the relevant day. It decides, for this case, whether each norm’s conditions hold, and composes the result. Every result comes with its derivation: the provisions and records it rests on, the conditions it set aside and why, and what it presumed. A value someone merely states is shown as a statement until a measurement or a record settles it. Every change to the knowledge behind a result is journaled with who made it.
AI-assisted: where a provision or a project text has to be read, a language model reads it. The engine records that it did, and counts a model’s reading below a reviewed rule or an official record.
How it judges
The law as it stood
Provisions are read in the version in force on the filing day, or on the day the check names. Every result states the day and its basis.
Conditions decided for this case
A norm counts only where its conditions hold for this project. Each condition is decided with its basis named: the project’s facts, the place, or the usual case.
Presumptions are marked
Where the documentation is silent, the usual case is presumed. The presumption is marked as such and listed with what would decide it otherwise.
A statement is not a measurement
A value the applicant states is shown as stated. A survey, a measurement or an official record settles it.
The specific norm decides
Where norms disagree, the more specific one decides. The others are shown, with the reason each was set aside.
Every change is journaled
Every change to the knowledge is recorded with who made it and why, and can be amended with a reason. No probability is ever 1: a settled fact is shown as verified and stays open to correction.
One check, traced
This is a statement from the documentation for a new single-family house, checked against the municipal spatial plan. The sentence was written for this example. The plan, the location and the plan’s rules are the real project’s. The reasoning below is the engine’s own output from 28 October 2026. The parcel, the address and all names are left out.
“Načrtovana je novogradnja enostanovanjske stavbe etažnosti P (pritličje).”
A new single-family house is planned, with a ground floor only (P).
- Norm
- Art. 84 of the municipal spatial plan, Odlok o občinskem prostorskem načrtu občine Juršinci (Uradni vestnik Občine Juršinci, št. 3/14): “v dolinskih naseljih do največ (K) + P + (1N) s kolenčnim zidom do 0,2 m”. In valley settlements, at most an optional basement, the ground floor and one optional upper storey, with a knee wall of up to 0.2 m.
- Outcome
- Meets the norm
- Shown as
- Insufficient evidence, 0.57: the storeys are the applicant’s own statement
- As of
- 31 December 2022, the documentation’s date. The filing date was unknown, so this is an assumption, stated with the result.
- Plan rule
- Read from the provision by a model and not yet reviewed by a planner, so it is counted at reliability 0.7
The derivation, as the engine renders it
#1 “Načrtovana je novogradnja enostanovanjske stavbe etažnosti P (pritličje).”
site:example storeys:p: insufficient evidence, 0.57 [statute]
statute: Odlok o občinskem prostorskem načrtu občine Juršinci (Uradni vestnik Občine Juršinci, št. 3/14), 52. člen <the plan's page in PIS> (2026-10-26)
statute: Odlok o občinskem prostorskem načrtu občine Juršinci (Uradni vestnik Občine Juršinci, št. 3/14), 84. člen <the plan's page in PIS> (2026-10-28)
statute: Odlok o občinskem prostorskem načrtu občine Juršinci (Uradni vestnik Občine Juršinci, št. 3/14), 84. člen <the plan's page in PIS> (2021-08-23)
site:example condition “dolinska naselja” (fact): holds [supplied]
supplied: place line 8 “zone:M:EUP1 is_classified_as:valley_settlement”; The parcel lies wholly in unit EUP1, and the plan classifies EUP1 as a valley settlement (dolinsko naselje).
site:example condition “slemenska naselja” (fact): does not hold: 'norm:r1|land_use:M:SK' is not this project's case [supplied]
supplied: place line 8 “zone:M:EUP1 is_classified_as:valley_settlement”; The plan classifies unit EUP1 as a valley settlement, not a ridge settlement. The ridge-settlement case therefore does not apply.
site:example condition “na ravninskem terenu, če predstavlja značilne naselbinske poudarke in ni porušen višinski videz naselja” (fact): does not hold: 'norm:r2|act:opn' is not this project's case [assumption]
assumption: The exception requires the building to be a characteristic settlement accent on flat terrain. An ordinary ground-floor-only (P) single-family house is not such an accent unless its documentation presents it as one, and the documentation given does not. The conjunction therefore fails whatever the terrain. Needs: Whether the DGD presents the building as a characteristic settlement accent (značilni naselbinski poudarek), whether the terrain is flat, and whether the settlement's height profile stays intact.
site:example condition “teren ali tla ne omogočajo podkletitve” (fact): does not hold: 'norm:r3|act:opn' is not this project's case [assumption]
assumption: Nothing given says the terrain or ground rules out a basement. The usual case is that a basement is possible unless a geotechnical finding says otherwise. The project is plain P and does not invoke this exception. Needs: A geotechnical or geomechanical report, or a statement in the DGD, on whether the terrain or ground at the parcel allows a basement.
grounds: 3; judgements: none; open: none
presumed or assumed (holds unless shown otherwise): site:example condition “na ravninskem terenu, če predstavlja značilne naselbinske poudarke in ni porušen višinski videz naselja”, site:example condition “teren ali tla ne omogočajo podkletitve”
- What the result rests on: a provision of the plan, with the date of the record, or a value as stated.
- A condition of a norm that holds for this project.
- A condition that does not hold, so its norm is set aside as not this project’s case.
[supplied]decided on the project’s facts or the place as given.[assumption]decided on the usual case, with what would decide it otherwise (“Needs”).
What to notice
- Three rows of Art. 84 do not fit this project, and each is set aside with its basis. The ridge-settlement row is set aside because the plan classifies the planning unit as a valley settlement. The two exceptions are set aside on the usual case, each with what would decide it.
- The norm is met, yet the result reads “insufficient evidence”. The storeys are the applicant’s statement, and Bayesian shows a statement as a statement. A measured value or a record would decide it.
- The day is part of the result: the plan is applied in the version in force on that day.
The second claim: the plot ratio (FZ)
“Faktor zazidanosti gradbene parcele je 0,19.”
The plot ratio (faktor zazidanosti) of the building plot is 0.19.
- Norm
- Art. 84 of the same plan: “pri stanovanjskih in drugih stavbah do vrednosti 0,4” (for residential and other buildings, up to 0.4)
- Outcome
- 0.19 ≤ 0.4: meets the norm
- Shown as
- Insufficient evidence, 0.70: the value is stated by the applicant
- Also considered
- The raised limit of 0.6 applies only if setbacks, position and safe access are ensured. Those conditions are undecided, so the stricter limit decides. The farm rows are set aside on the usual case, and the extension row on the project’s facts.
#2 “Faktor zazidanosti gradbene parcele je 0,19.”
site:example fz:0.19: insufficient evidence, 0.70 [stated]
stated by the applicant: 0.19
statute: Odlok o občinskem prostorskem načrtu občine Juršinci (Uradni vestnik Občine Juršinci, št. 3/14), 84. člen <the plan's page in PIS> (2021-08-23)
site:example condition “stanovanjske in druge stavbe” (fact): holds [supplied]
supplied: project fact 0 “Načrtovana je novogradnja enostanovanjske stavbe etažnosti P (pritličje).”; The project is a single-family house, which is a residential building (stanovanjska stavba). The condition of the ≤ 0.4 norm is therefore met.
site:example condition “kmetije” (fact): does not hold: 'norm:r8|land_use:M:SK' is not this project's case [assumption]
assumption: The documentation describes a new single-family house and says nothing about a farm. A single-family house is not a farm (kmetija) unless the documentation says it is. Needs: Whether the DGD states that the house is part of a farm holding (kmetija), e.g. a farm dwelling with farm buildings.
site:example condition “kmetije, če so zagotovljeni pogoji o odmikih, legi, varnosti dostopa” (fact): does not hold: 'norm:r9|land_use:M:SK' is not this project's case [assumption]
assumption: project fact 0 “Načrtovana je novogradnja enostanovanjske stavbe etažnosti P (pritličje).”; This norm applies only to farms (kmetije). The documentation describes the project as a new single-family house and does not say it is a farm or belongs to one, so I take the usual case that it is not a farm. Because the farm condition fails, the conditions on setbacks, position and access safety do not matter here. Needs: A statement in the documentation on whether the house is a farm building or part of a farm (kmetija).
site:example condition “dozidava” (fact): does not hold: 'norm:r10|act:opn' is not this project's case [supplied]
supplied: project fact 0 “Načrtovana je novogradnja enostanovanjske stavbe”; The documentation describes the project as new construction (novogradnja), not as an extension (dozidava) of an existing building. The extension condition of 52. člen therefore does not apply to this project.
grounds: 3; judgements: none; open: none
presumed or assumed (holds unless shown otherwise): site:example condition “kmetije”, site:example condition “kmetije, če so zagotovljeni pogoji o odmikih, legi, varnosti dostopa”
The same two checks as the API returns them: storeys.json, fz.json.
Pre-assessments with Luma Intelligence
Luma Intelligence, GEATEH’s AI-assisted service for assessing sites and building projects, is piloting Bayesian Logic as the rule engine behind its regulatory pre-assessments. Luma supplies the project documentation, the rules of the municipal spatial plan with the location card, and the texts of the national acts in the version in force on the filing day. Bayesian works out which norms apply to the project, whether each is met and on what grounds, with every step traceable to the provision it rests on. Luma’s report explains the result in plain language: a pre-assessment with human sign-off, never a permit decision.
In the pilot, the documentation of a real building permit was checked end to end against its municipal plan and the national acts, and the results matched an independent review. A check takes minutes, not hours.
Independence
There is no advertising, and no sponsor chooses what is checked. A result is never bought: who commissions a check does not change what it finds, and the full chain of reasons is shown with it.
API
Bayesian runs as a service with an HTTP API. A caller starts a check as a job and supplies its own facts: documents, plan rules with their review states, and provision texts. It answers the questions a check raises, and reads each result with its derivation, the day it was judged as of and the revision of the knowledge it used.
API access is available to partners on request.