Da, i da dodam — ti slojevi o kojima sam govorio su već urađeni i istestirani.
Nema tu neke „velike nauke“ u tehničkom smislu, samo je stvar logike i dosledne strukture.
Sistem je slojevit, kao arhitektura:
u osnovi su zakoni i pravila ponašanja,
iznad njih logika i odnosi između jedinica,
a iznad svega volja zajednice koja pokreće promenu.
Sve to je moguće izraziti matematički, kroz proporcije i odnose koji već postoje u prirodi — isti oni principi po kojima su građene strukture, hramovi i proporcije zlatnog preseka.
Kad bi se to detaljno objasnilo, mnogima bi zvučalo apstraktno, ali u praksi je vrlo jednostavno: to je sistem koji održava sopstv
enu ravnotežu.
Nadam se da ćeš ovo razumeti...
Kako teče podatak (format → validacija → orkestracija → izvršenje)
1) Ulaz (intent) — kanonski JSON
Sve što ulazi pretvaramo u kanonski JSON (UTF-8, ISO-8601 vreme, UUID, verzionisanje).
LLM ili UI samo „puni“ ovaj format; ništa se dalje ne oslanja na prirodni jezik.
{
"v": "1.0",
"id": "3c6f0a6e-5e2c-4d4f-9b7a-5d8e6b1a9a12",
"ts": "2025-10-10T15:12:03Z",
"actor": {
"person_id": "did
QmUser123",
"credential": "zk-proof-blob"
},
"intent": {
"kind": "BUDGET_ALLOCATE",
"domain": "city.parks",
"params": {
"amount": 15000,
"currency": "EUR",
"project_id": "parks-027"
}
},
"meta": {
"locale": "sr-RS",
"source": "
mobile.app@1.7.2"
}
}
Napomena: person_id je pseudonim (npr. DID), a credential je ZK-dokaz da je „1 osoba = 1 pravo“ bez otkrivanja identiteta.
2) Validacija (Validator) — JSON Schema + ustavni testovi
Prva linija: JSON Schema (struktura, tipovi, opsezi).
Druga linija: ustavni/etički invarijanti (pravila koja se ne smeju prekršiti).
Treća linija: policy po domenima (npr. budžetski plafoni).
Rezultat validacije:
{
"v": "1.0",
"input_id": "3c6f0a6e-5e2c-4d4f-9b7a-5d8e6b1a9a12",
"schema_ok": true,
"policy_ok": true,
"invariants_ok": true,
"violations": [],
"score": 0.98,
"signature": "ed25519:K1...=="
}
Ako padne nešto, violations vrati listu pravila i hint kako da korisnik popravi zahtev.
3) Orkestracija (Planner) — plan kao DAG u JSON-u
Iz validnog intent-a pravi se plan (graf zadataka, zavisnosti, provere).
Svaki korak ima tip, ulaze/izlaze i idempotentni op.
{
"v": "1.0",
"plan_id": "pln_9e88b7f0",
"based_on": "3c6f0a6e-5e2c-4d4f-9b7a-5d8e6b1a9a12",
"nodes": [
{"id": "n1", "op": "ledger.reserve", "in": {"amount": 15000, "ccy": "EUR"}},
{"id": "n2", "op": "vote.check_quorum", "in": {"project_id": "parks-027"}, "after": ["n1"]},
{"id": "n3", "op": "ledger.disburse", "in": {"to": "project.parks-027"}, "after": ["n2"]}
],
"policy": {"rollback": {"on_fail": ["n1"]}}
}
4) Izvršenje (Fulfilment) — status + događaji
Svaki op emituje događaj; sve ide u append-only log.
{
"v": "1.0",
"exec_id": "exec_4b1c",
"plan_id": "pln_9e88b7f0",
"events": [
{"ts": "2025-10-10T15:12:06Z", "node": "n1", "status": "OK"},
{"ts": "2025-10-10T15:12:08Z", "node": "n2", "status": "OK", "meta": {"quorum": 0.61}},
{"ts": "2025-10-10T15:12:10Z", "node": "n3", "status": "OK", "meta": {"txid": "0xabc..."}}
],
"final": "SUCCESS",
"hash": "merkle:QmXYZ...",
"signature": "ed25519:K2...=="
}
---
Formati i „prebacivanje formata“
Prirodni jezik → kanonski JSON
1. Parse NL (LLM): iz teksta izvuče intent.kind i params.
2. Canonicalize: mapira ključeve na standardne nazive, dodaje v, id, ts.
3. Normalize: valute, datumi, identifikatori u dogovorene forme.
> Ovo može da ide kroz JSON-LD ako želiš semantički sloj (kontekst), ali nije uslov.
Transport
HTTP/HTTPS (Content-Type: application/json; charset=utf-8)
ili MQTT/AMQP za događaje.
Svi paketi se potpisuju (Ed25519), hash-iraju i ulančavaju u Merkle log (audit).
Krajnji format (trajno)
Append-only audit log kao niz „paketa“: input → validation → plan → exec.
Svaki paket ima hash i prev_hash (laki lanac). Može stajati u:
SQL/NoSQL sa Merkle stablom sa strane,
ili u objekt-storage + periodično „zakucavanje“ sidra (anchor) na public chain.
Struktura zapisa u dnevniku:
{
"v": "1.0",
"entry_type": "EXEC_EVENT",
"prev_hash": "merkle:QmPrev...",
"payload": { /* jedan od gornjih objekata */ },
"hash": "merkle:QmThis...",
"signature": "ed25519:Ksig..."
}
---
Šeme (skraćeni primeri JSON Schema)
Intent schema (skraćeno):
{
"$id": "schema://intent/1-0.json",
"type": "object",
"required": ["v","id","ts","actor","intent"],
"properties": {
"v": {"const": "1.0"},
"ts": {"type": "string", "format": "date-time"},
"id": {"type": "string", "format": "uuid"},
"actor": {
"type": "object",
"required": ["person_id","credential"],
"properties": {
"person_id": {"type": "string"},
"credential": {"type": "string"}
}
},
"intent": {
"type": "object",
"required": ["kind","domain","params"],
"properties": {
"kind": {"enum": ["BUDGET_ALLOCATE","POLICY_PROPOSE","VOTE_CAST"]},
"domain": {"type": "string"},
"params": {"type": "object"}
}
}
}
}
Validator policy (primer invarijante):
{
"invariants": [
{"name": "non_discrimination", "check": "RULESET:constitutional_v1"},
{"name": "budget_cap", "check": "amount <= domain_cap(domain)"}
]
}
---
Šta je „format kraja“ za korisnika?
Ako gleda rezultate: exec izveštaj (kao gore).
Ako želi dokaz: hash + potpis tog zapisa (može QR za proveru).
Ako želi statistiku: agregat Polis/QF rezultata u JSON-u:
{
"v": "1.0",
"domain": "city.parks",
"round": "2025Q4",
"participation_rate": 0.37,
"qf_matches": [
{"project_id":"parks-027","raised":15000,"match":8200},
{"project_id":"parks-013","raised":9100,"match":4100}
],
"consensus": {
"statements": [
{"id":"s14","support":0.76,"text":"Više zelenih površina blizu škola"},
{"id":"s08","support":0.71,"text":"Otvoreni podaci o budžetima"}
]
}
}
---
TL;DR za tehničare u jednoj rečenici
Sve je kanonski JSON → JSON Schema validacija + ustavni invarijanti → plan (DAG) → izvršenje sa događajima → audit log (Merkle, potpis).
LLM je samo „parser“ namere; pravila i bezbed
nost su u Validatoru, a deterministika i idempotencija su u Orchestratoru/Fulfilmentu.
