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 0.1. Numer dotyczy zestawu reguł, nie kodu strony, i rośnie co 0,1 przy każdej zmianie, która może przesunąć czyjś wynik (dołożona reguła, inny koszt, inny próg). Wyniki porównuj tylko w obrębie jednej wersji.
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.
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 |
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ć.
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.
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, ai? } → pełny raport JSON |
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 |
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.
Twoja ontologia nie jest nigdzie zapisywana — wchodzi do pamięci procesu,
zostaje oceniona i znika. Włączenie osądu modelu wysyła szkielet (nazwy i typy,
bez prozy) do OpenAI.