Trust Center
What KOREV documents, what is partially documented, what remains to be published — and the known limits. Transparency is part of the product.
Technical publication · v1.0.2
Protocol, threat model, hostile scenarios, experimental results, and limits, all documented. Verification covers integrity and continuity within declared boundaries; it proves neither truth nor regulatory compliance.
Evidence / Trust controls
Sources, uncertainties, publication, and security: every mechanism has a scope. The badges describe controls and technologies, not certifications or a real-time monitoring status.
Analysis available / Separate validation
Understanding a block is part of the result.
An analysis can explain the risks, the missing information, and the next checks while keeping a non-validated decision status. The record's actual status is what counts.
Measures described in the technical documentation provided. Their activation and scope must be confirmed for your deployment; this presentation is not an independent audit of the infrastructure.
A record may show "consensus not executed" or "cryptographic integrity not computed." These states must remain visible and never count as a passed control. Proof of integrity does not prove that the content is accurate.
KOREV documents a bounded post-admission continuity property over declared, instrumented boundaries: an admission acknowledged by the witness must remain represented and be reconciled before a population can be classified VERIFIED.
Published limits: instrumented boundaries only, no global completeness, no semantic truth, no certification, no independent third-party reproduction yet.
Technical note EN (PDF)KOREV Evidence is operated as a deployable product: production releases, a single release-to-production procedure, blocking CI checks, health checks, versioning of the deployed commit, and rollback/diagnostic procedures.
We do not publish a product TRL (technology readiness level) until the integrated system as a whole has been formally reassessed; the earlier TRL assessment of the PRISM component is archived.
Three layers — Atlas (Enterprise LLM and reasoning), Evidence (execution agents), PRISM (control) — between the business process and the client infrastructure, with five cross-cutting mechanisms: human oversight, audit trail, governance, security, data control.
Technical controls — encryption, isolation, access management, logging — within the chosen deployment environment.
Security certifications (ISO 27001, HDS, SecNumCloud…): no certification is claimed on the current site; to be published as actual certification steps are undertaken.
Security pageMechanisms built into the architecture: model identification, traces, sources, human approval, rules, divergences, history, review, permissions, responsibilities.
Atlas, KOREV AI's Enterprise LLM, specialized on your enterprise knowledge and managed with a version registry.
Formalization of the public list of supported models by version, and of the update policy.
AtlasData location, flows, and processing defined by the organization; KOREV does not use client data to train public models.
Architecture designed to help meet the oversight, traceability, and governance requirements that apply depending on the use. Not a certification of compliance.
Approval points defined process by process; automatic escalation when rules are not met; approvals traced and attributed.
Control layer: multi-model cross-checking, divergence detection, configurable consensus, thresholds, rules, fail-closed, human oversight.
KOREV already publishes targeted results on Decision Evidence and runs business validation campaigns; Atlas benchmarks and end-to-end performance measurements still need to be consolidated before publication.
Atlas, latency, cost, and load benchmarks to be published once they have been rerun on a stable public protocol.
How a process is assessed, piloted, and then rolled out to production: Pulse (assessment), Pilot (first use case), Production rollout, Multi-process deployment.
Principles: people remain accountable for the steps that require it; no marketing absolutes; limits are documented.
European cloud, hybrid, or on-premises; isolated environment depending on the project.
Engineering & auditability
An inventory of KOREV's engineering claims, measurements, and mechanisms. Each public signal is linked to a method, a precise scope, and an explicit methodological limitation.
14
14 active profiles under agents/: compliance, contradictor, default, developer, finance, hacker, infrastructure, legal_drafting_guarded, legal_safe, marketing, medical, multitask, researcher, sales. The _example folder is excluded.
3 levels
CriticalityRouter architecture (ADR-010 / ADR-011): LEVEL 1 (simple request: consensus bypassed by default, source baseline mandatory); LEVEL 2 (professional zone: analysis/advice, consensus can be enabled through explicit user opt-in or caller force_consensus, source baseline); LEVEL 3 (critical decision, liability, dispute, critical action: PRISM consensus mandatory, strict mode if the domain is critical). Fail-closed always takes priority in case of ambiguity.
RSA-PSS / HMAC
critical_output layer (ADR-010): v2 signature binding input_hash, output_hash, consensus_result_hash, criticality_level, policy_id/version, timestamp, trace_id. RSA-PSS-SHA256 algorithm in production, HMAC fallback depending on configuration.
v1.0.2
Admissions acknowledged by the witness on the configured path; history continuity, admission→terminal reconciliation, checkpoint freshness, and bundle inventory.
Technical note v1.0.2 + v2 protocol + verifier + recorded hostile scenarios.67 tests
Targeted decision_pack / decision_capture / witness suite, not the product's full test set.
python -m unittest discover -s tests -p 'test_decision*.py' -v22 / 22
Deterministic synthetic study, with no external LLM calls and no external network traffic.
Two decision-capture-v2 runs; 11 hostile scenarios per batch.5 required checks
Production release chain for the Evidence backend: protected main branch, mandatory PR, 5 required checks, enforce_admins, build/deploy guardrails, drain before restart, /healthz, and VERSION.json.build_commit.
Operations runbook + branch protection + deploy_prod.sh / stamp_version.py scripts.2/3
Canonical run_consensus() API: a 2/3 quorum of the valid votes cast by the cross-checked models is required.
Formal consensus specification and run_consensus() implementation.Fail-closed tested
Fail-closed behavior replayed on the trust contracts, the log, and the providers covered by the proof suite (TrustContext, adversarial tests).
Language model and contextualized reasoning capabilities, drawing on internal documents, reference frameworks, procedures, and controlled interactions with KOREV agents.
Regulatory compliance depends on the context, the system, its use, and the organization's role. KOREV provides technical governance capabilities; on its own, it does not constitute a legal certification of compliance.