Walidator ontologii

Wrzuć swoją ontologię i zobacz, w ilu miejscach odchodzi od praktyki projektowej Palantir Foundry. Każde znalezisko mówi, co jest nie tak, dlaczego to problem, jak to naprawić i skąd ta zasada pochodzi.

wersja 2.1 …

krok 1 Pobierz szablon YAML
Wzorzec, który przechodzi 100/100 — widać w nim, jak opisać typy, linki i akcje.
krok 2 Przepisz swoją ontologię na szablon
Ręcznie albo z pomocą AI: daj modelowi swój schemat i szablon, poproś o przepisanie bez dopisywania czegokolwiek od siebie.
krok 3 Wrzuć i dostań wynik
Wklej albo przeciągnij plik niżej i kliknij „Sprawdź” — wynik 0–100 z wyjaśnieniem każdego znaleziska.
krok 4 Poprawiaj, aż będzie 90+
Każde znalezisko mówi, jak je naprawić. Sprawdzaj ponownie, aż zgodność przekroczy 90 / 100.

Dokumentacja

Format wejścia jest celowo nazwany po Foundry'emu (objectTypes, apiName, MANY_TO_ONE) — te nazwy rozpoznasz z dokumentacji Palantira. Obowiązkowa jest tylko lista objectTypes; grupa, której nie ma, nie jest karana. Przyjmujemy JSON i YAML.

Formatowanie nas nie obchodzi. Czytamy plik po bibliotece YAML tak samo jak pisany ręcznie: listę na tym samym wcięciu co klucz, opis łamany na kilka linii (w cudzysłowie, w apostrofach albo bez), blok >- i |-, polskie znaki jako \xF3, tagi !!str. Zgodność sprawdzamy, porównując wynik z prawdziwym parserem YAML. Jak plik naprawdę nie parsuje — komunikat podaje numer linii.

wczytuję…

Reguły są deterministyczne i mają stałe identyfikatory — P12 znaczy to samo dziś i za rok, więc raport da się porównywać między wersjami modelu. Każda ma przy sobie cytat ze źródła; reguła bez źródła nie przechodzi naszych testów.

Id	Kategoria	Klasa	Czego pilnuje

wynik = 100 − suma kosztów znalezisk, przy czym każda kategoria ma budżet: tyle punktów najwyżej można w niej stracić. Dzięki temu jeden zepsuty obszar nie zjada całego wyniku, a widać, gdzie model przestał trzymać.

Klasa	Koszt	Co znaczy
złamanie	`4 pkt`	łamie zasadę, którą Foundry stawia wprost — zwykle nie da się tego zbudować
ryzyko	`1,5 pkt`	wpada we wzorzec, przed którym Foundry ostrzega
uwaga	`0,4 pkt`	sygnał do przejrzenia — bywa uzasadniony, dlatego kosztuje mało

Wersja zestawu reguł

Każdy raport niesie numer wersji (wersjaRegul w JSON-ie, odznaka u góry strony). Numer ma dwie liczby i idzie co 0,1 — 0.1 → 0.2 → … → 1.0 → 1.1. To nie jest semver: nie ma tu API, które można zepsuć, jest zestaw reguł, który się rozrasta.

⚠ Numer rośnie przy wszystkim, co może przesunąć czyjś wynik: dołożona albo skasowana reguła, zmieniony koszt klasy, zmieniony budżet kategorii, przesunięty próg. Poprawka literówki w uzasadnieniu wersji nie zmienia. Dzięki temu zdanie „poprawiliśmy model o 6 punktów” znaczy coś tylko wtedy, gdy oba raporty mają ten sam numer — a jeśli nie mają, od razu to widać.

Dwa silniki, jedna liczba

Wynik liczy wyłącznie kod, deterministycznie: ten sam plik zawsze da tę samą liczbę. Model językowy — jeśli go włączysz — dokłada osąd o rzeczach, których nie da się policzyć (czy dwa typy to ten sam byt, czy nazwa coś znaczy w tej branży), ale nie dotyka punktów. Gdyby je liczył, dwa uruchomienia dałyby dwie liczby i raport przestałby się nadawać do porównywania wersji.

Model pytamy wąsko — i domyślnie tanio. W trybie klasyfikacji dostaje samą tabelę nazw typów i odpowiada zamkniętą etykietą: co jest maszynerią narzędzia, a co rzeczownikiem z twojej organizacji. Wniosek („więc to powinno mieć hidden”) wyciąga z tych etykiet kod. Dzięki temu wystarcza mały, tani model: zamknięta odpowiedź jest sprawdzalna (nazwa musi istnieć w wysłanej tabeli), a wolna proza nie jest — i to ona wymaga dużego modelu. Recenzja prozą jest drugim trybem, włączanym świadomie; na typowym modelu kosztuje ponad dwadzieścia razy więcej tokenów.

Czego to narzędzie NIE sprawdza

Nie wie nic o twoich danych ani o twoim kodzie. Sprawdza kształt modelu: czy jest zaprojektowany tak, jak radzi Palantir. Ontologia może dostać 100/100 tutaj i dalej nie pasować do rzeczywistości zakładu — to sprawdza się rozmową z ludźmi, którzy tam pracują, nie walidatorem.

Ta sama ocena z terminala albo z CI.

curl -s https://valid.nueve.design/api/waliduj \
  -H 'content-type: application/json' \
  -d "$(jq -Rs '{tekst:.}' < moja-ontologia.yaml)" | jq '.projekt.wynik'

Trasa	Co robi
`POST /api/waliduj`	`{ tekst \| kanon, ai?, tryb? }` → pełny raport JSON. `tekst` — plik JSON albo YAML w kształcie szablonu; `kanon` — ontologia już zamieniona na kształt kanoniczny (obiekt, z polem `formatWejscia`). `tryb`: `skan` — domyślny, pełny — albo `klasyfikacja`, tani; `ai: false` wyłącza osąd modelu
`GET /api/reguly`	lista reguł, kategorii i klas
`GET /api/zdrowie`	wersja i czy osąd modelu jest dostępny
`GET /szablon.yaml`	szablon wejścia

Co zostaje na serwerze

Twoja ontologia nie jest nigdzie zapisywana — wchodzi do pamięci procesu, zostaje oceniona i znika.

Osąd modelu wysyła do OpenAI same nazwy typów i pól (tryb klasyfikacji) albo szkielet (pełny skan) — nigdy prozy z opisów. Odpowiedź modelu leży godzinę w pamięci procesu, żeby drugie kliknięcie w ten sam plik nie kosztowało drugiego zapytania; restart ją kasuje.

Kto to zrobił

Narzędzie Nueve. Reguły odwzorowują publiczną dokumentację Palantir Foundry → Ontology (Core concepts, Object & link types, Action types, Interfaces, Ontology design: Best practices / Structural guidance / Anti-patterns). Nie jesteśmy związani z Palantir Technologies; nazwy produktów należą do ich właścicieli.