OISG adequate on the full stack
Admina is designed around the OISG paradigm — Open,
Intelligent, Secure, Governed.
The full Docker Compose stack — which ships the Rust engine compiled in — reaches the
OISG adequate level out of the box; a bare admina[proxy] install plus
admina dev scores 75, in the Good coverage band. Either way the
adequacy score is computed automatically from the live runtime state — not a checklist,
not a quarterly audit, not a PDF.
What is OISG?
OISG is a public framework for evaluating whether an AI system is adequate to be trusted in production. It defines four pillars — Open, Intelligent, Secure, Governed — each with five technical criteria. Every criterion is worth five points; the total is a 0–100 adequacy score.
0–24 Critical gaps — system is not safe to deploy 25–49 Partial coverage — significant remediation required 50–79 Good coverage — ready for constrained production 80–100 OISG adequate — ready for governed production deployment Why the full stack ships OISG adequate
Every governance capability Admina ships maps directly onto OISG criteria.
The adequacy score is not a marketing metric — it is a runtime read of the features you
have actually turned on. The default Docker Compose stack compiles the Rust engine into
the image, which satisfies o5 and s5 and lands the instance in
the OISG adequate band with no additional configuration. Enabling AI infra and
RAG (o1, i3) and loading a governance-guard plugin
(g3) takes it the rest of the way to 100.
The four pillars
Open
25 / 25Auditable by design — model, governance, and protocols are public and inspectable.
- O1 Model documentation (capabilities, limitations, provenance) available to independent auditors
- O2 Governance infrastructure (policy engines, decision logic) is open and auditable
- O3 Communication protocols use open standards (MCP, OpenTelemetry, A2A)
- O4 Open projects have community stewardship (contribution process, security disclosure, governance)
- O5 Model provenance and training methodology are documented and reproducible
Intelligent
25 / 25Measurable, sovereign, traceable — reasoning can be explained, not assumed.
- I1 Model capabilities measured with benchmark results, known failure modes, confidence calibration
- I2 Infrastructure supports sovereign execution (on-premise, private cloud, air-gapped)
- I3 RAG pipelines are traceable (document version, embedding model, retrieval path)
- I4 Agent autonomy scope is explicit, machine-readable, and enforced at runtime
- I5 System can produce on demand a complete explanation of why it gave a specific response
Secure
25 / 25Defence in depth — bidirectional, cryptographic, recoverable.
- S1 Bidirectional injection defence operates on both request and response paths
- S2 Agent identities are cryptographically verifiable (DIDs, Ed25519 key pairs)
- S3 Transactional kill switch preserves forensic state and enables rollback
- S4 PII redaction is enforced at infrastructure level before model endpoints
- S5 Model supply chain integrity is verified (fingerprinting, SBOM, cryptographic provenance)
Governed
25 / 25Continuous, automated compliance — not a quarterly audit PDF.
- G1 Compliance verified automatically at runtime, not through periodic audits
- G2 Immutable forensic log (hash-chained) records all interactions and decisions
- G3 Human oversight is architecturally defined (which decisions, what info, what timeout)
- G4 End-to-end observability in place (distributed tracing, SLOs, dashboards)
- G5 Risk classification is proportional, automated, and auditable as capabilities evolve
How Admina maps onto OISG
admina.yaml, per-decision explanation.
ADMINA_FORENSIC_STATE_KEY is set), OpenTelemetry spans on every decision,
Admina Score + OISG Score on the dashboard.
Verify your adequacy score
Once the proxy is running, the live OISG score is available from the dashboard and via
the REST API. The result reflects the actual runtime state and is recomputed on
every read. admina.yaml is read when the proxy starts, so turning a capability
off there lowers the score after the next restart. The endpoint belongs to the
dashboard surface: with ADMINA_ENABLED_SURFACES leaving it out, it
answers 404.
Since v0.13.1 three live criteria follow the runtime more closely: G2 (immutable forensic
log) is not satisfied while the forensic chain status is invalid; G4
(observability) follows ADMINA_DASHBOARD_ENABLED and
ADMINA_ENABLED_SURFACES, as the dashboard itself does; and G4 counts OpenTelemetry
only when the exporter actually exports spans (not with OTEL_ENABLED=false,
ADMINA_OFFLINE=true or the telemetry library missing). O3 stays satisfied; only
its reason text says whether the exporter is active.
curl http://localhost:8080/api/dashboard/oisg \ -H "X-API-Key: $ADMINA_API_KEY" # { # "total": 85, # "max_total": 100, # "level": "OISG adequate", # "pillars": { "open": {...}, "intelligent": {...}, ... }, # "computed_at": "...", # "colors": { "open": {"light": "#0F6E56", "dark": "#5DCAA5"}, ... } # }
Score from external evidence
New in v0.13.0
The live score above only sees what the running proxy exposes. To assess a system with
evidence gathered elsewhere — documents, audit records, a review — the library function
compute_oisg_score_from_evidence() (in
admina.domains.compliance) scores the same 20 criteria, with the same ids and
labels, from a status you supply for each one. It is a Python function only: no endpoint
and no CLI command, and compute_oisg_score() is unchanged.
satisfied 5 points. partial 2.5 points. accepted_gap 0 points — a known gap, accepted with a reason, which is required and must not be blank. not_applicable Left out of the score. Each pillar is rescaled to 25 over the criteria that apply; a pillar where none applies has no score (null) and the total is rescaled to 100 over the other pillars.
Scores have one decimal, rounded half up, and the level uses the same bands as above, applied
to the rounded total. The evidence needs an entry for every one of the 20 criteria
(reason and evidence_ref are optional strings); a missing or unknown
criterion, an unknown status or key, an accepted_gap without a reason, or
evidence where every criterion is not_applicable raises
OISGEvidenceError (a ValueError whose problems names
each key). The JSON Schema ships in the package as
admina/domains/compliance/schemas/oisg-evidence.schema.json.
from admina.domains.compliance import compute_oisg_score_from_evidence evidence = { "schema_version": 1, "criteria": { "o1": {"status": "partial", "reason": "Model card covers capabilities only", "evidence_ref": "docs/model-card.md"}, "i3": {"status": "not_applicable", "reason": "No RAG pipeline"}, "g3": {"status": "accepted_gap", "reason": "Oversight design due next quarter"}, # ... one entry for each of the other 17 criteria, here all "satisfied" }, } result = compute_oisg_score_from_evidence(evidence) result.total # 92.5 (Open 22.5, Intelligent 25.0 over 4 criteria, Secure 25.0, Governed 20.0) result.level # "OISG adequate" result.to_json() # total, level, pillars with each criterion's status, reason, evidence_ref, points result.to_markdown() # the total, then one table per pillar