Styrning av Kshana

Det här dokumentet anger hur Kshana styrs: vem som fattar beslut, hur, och vad projektet kommer och inte kommer att ta emot. Det är medvetet lätt, i proportion till projektets nuvarande storlek, och är ärligt om att det i dag finns en enda underhållare och om vägen mot bredare styrning när gemenskapen växer.

Uppdrag och omfattning#

Kshana är en neutral, reproducerbar och ärligt validerad referens för prestanda och resiliens hos hybrid kvant/klassisk PNT. Uppdraget sätter ribban för varje beslut: korrekthet, källhänvisningar och reproducerbarhet går före bredd. Den ärliga omfattningen dokumenteras i docs/CAPABILITY.md och valideringsstatusen i docs/VALIDATION.md; förslag vägs mot den omfattningen, inte mot antalet funktioner.

Roller#

Underhållare. Kshana underhålls för närvarande av sin grundare, Ashforde OÜ (kontakt: contact@ashforde.org). Underhållaren fattar slutgiltigt beslut om omfattning, utformning, utgåvor och vad som slås ihop. Det här är en modell med en välvillig underhållare, uttryckt rakt ut i stället för att klädas ut till en kommitté som inte finns.
Bidragsgivare. Alla som öppnar ett ärende eller en pull request. Bidrag mäts mot ribban i CONTRIBUTING.md: ursprung för varje numerisk parameter, validering mot ett publicerat samband och ärlighet om mognad.
Framtida committers. Allteftersom ihållande bidrag av hög kvalitet motiverar det utökas skrivrättigheterna till betrodda bidragsgivare, och det här dokumentet uppdateras till en modell med flera underhållare (beslut genom lazy consensus, där underhållargruppen löser oenigheter). Fram till dess är vägen: bidra, bygga upp en meritlista och bli inbjuden.

Hur beslut fattas#

Diskussion i det öppna. Betydande ändringar börjar som ett GitHub-ärende så att motiv, alternativ och avvägningar finns dokumenterade.
Lazy consensus. Ett förslag utan ihållande invändningar efter rimlig tid, och som klarar den tekniska ribban nedan, går vidare.
Underhållaren avgör vid oenighet. Där konsensus inte nås avgör underhållaren och antecknar skälet. Oenighet löses av uppdraget och den tekniska ribban, inte av ålder i tjänsten eller volym.

Den tekniska ribban (icke förhandlingsbar)#

Det här är hårda invarianter, upprätthållna av CI och granskning, som inget beslut åsidosätter:

Reproducibility. (scenario, seed, engine_version) måste reproducera en körning bit för bit. En ändring som gör detta icke-deterministiskt är ett fel, inte en funktion.
Ursprung. Inga anonyma numeriska konstanter: varje parameter anger en källa.
Ärlighet i validering. Varje förmåga märks validated (mot en oberoende extern referens) eller modelled / not modeled. Ingenting hävdas utöver sitt belägg. Se den maskinkontrollerade matrisen i src/verification.rs.
Hygien. Ingen angivelse av automatiserade verktyg som upphovsman någonstans i commits, innehåll eller historik (upprätthålls av scripts/check-no-attribution.sh).

En ändring som inte kan klara ribban avvisas, hur användbar den än vore.

Gränsen mellan öppet och slutet#

Kshana är open-core. Det här arkivet är, och förblir, den kompletta öppna AGPL-3.0-motorn, den neutrala referensen, dubbellicensierad kommersiellt av Ashforde OÜ (se LICENSING.md). Projektet kommer inte att ta emot följande i det öppna arkivet:

Exportkontrollerat eller dual-use-djup: verkliga hotbibliotek, motståndarvågformer eller prestandaparametrar för anti-jam/anti-spoof. Det publika arkivet håller sig till generella, publicerade modeller och metoder (se CONTRIBUTING.md → Export control). Om du är osäker, fråga innan du bidrar.
Kund- eller partnerkonfidentiella data eller kalibrering.
Copyleft-beroenden (GPL/AGPL/LGPL/MPL): inte för att de krockar med motorns egen AGPL-licens (det gör de inte), utan för att de inte kan omlicensieras till den kommersiella utgåvan: vi kan bara sälja en kommersiell licens för kod som vi äger eller som är permissiv. Ett copyleft-beroende skulle smitta den kommersiella utgåvan och bryta dubbellicensen. Beroenden förblir därför permissiva (Apache/MIT/BSD/ISC), vilket upprätthålls av deny.toml.

Omvänt kommer projektet inte att urholka den öppna kärnan för att driva upp proprietärt värde: den validerade motorn, de publika valideringsankarna, ärlighetsregistret, utbytes-/standardformatet och distributionskanalerna förblir öppna. Att svälta den öppna kärnan är det enda ödesdigra misstaget i open-core, och det är uteslutet.

Utgåvor#

Semantisk versionshantering. Före 1.0 kan scenario- och resultatschemat ändras; brytande ändringar lyfts fram, och schemaversionen för utbytet (src/interchange.rs::SCHEMA_VERSION) är den enda sanningskällan för kompatibilitet mellan artefakter.
Utgivningsmandat. Publicering (till exempel cargo publish) är ett manuellt steg för underhållaren som kräver en registertoken. CI och det taggstyrda utgivningsarbetsflödet publicerar aldrig automatiskt till externa register: de kör bara om alla kontroller och bifogar en byggartefakt. Se CONTRIBUTING.md → Commits and versioning.

Uppförandekod och säkerhet#

Uppförande styrs av CODE_OF_CONDUCT.md.
Säkerhetsärenden följer den privata rapporteringsprocessen i SECURITY.md: öppna inte ett publikt ärende för en sårbarhet.

Varumärke#

Namnet och logotypen Kshana är varumärken som tillhör Ashforde OÜ. Licensen (AGPL-3.0, eller en kommersiell licens) gäller koden, inte märkena: en fork får använda koden under licensen, men inte namnet Kshana eller den kanoniska distributionsidentiteten. Det gör att Ashforde förblir den citerade sanningskällan och är en del av hur den öppna kärnan förblir en neutral referens.

Ändring av det här dokumentet#

Ändringar av styrningen föreslås själva som en pull request och avgörs enligt processen ovan. När projektets skala ändras kan du räkna med att det här dokumentet får en beslutsmodell med flera underhållare; det kommer inte att sänka den tekniska ribban.

Lätt med avsikt. Ärligt om i dag, med en angiven väg för i morgon.