Gateway and control plane
Handles identity, action scopes, evaluation orchestration, publication rules, revocation and audit controls.
core/api · core/auth · control contractsCertentIQ / Development technical paper
Candidate Agent Evaluation and Control Architecture
A scoped account of how CertentIQ configures evaluation runs, observes system behavior, applies control gates, and preserves operator-generated evidence for a declared agent-system version.
01 / Document status
Purpose and evidence position
CertentIQ is designed to run versioned, adversarial and tool-enabled tests against a declared agent configuration. It records behavior observed during a particular run. It does not establish general intelligence, future behavior, legal compliance, or production safety.
DocumentCandidate architecture
A development description of the intended and implemented system boundaries.
Evidence levelOperator-evaluated
Runs and reports are produced by the system operator.
Result scopeSystem and version specific
Claims remain attached to the tested configuration and suite.
External statusValidation incomplete
No independent measurement or conformity conclusion is represented.
02 / Architecture
Four boundaries shape the run
The repository separates orchestration, execution, scoring and evidence responsibilities. This structure supports review and regression testing, but it is not proof that every deployment is isolated or secure.
Declared execution path
Connects the selected agent configuration to supported providers and bounded tools. Runtime-proof strength varies by connection mode.
core/connector · core/sandbox · runtime metadataTasks, fixtures and scorers
Defines versioned prompts, synthetic resources, repeated trials, telemetry and scoring logic. Changes can invalidate comparisons.
core/tasks · core/generator · suite fingerprintEvidence and public records
Binds manifests, run context, task outcomes, gate observations, signatures, validity periods and revocation state.
evidence contracts · RS256 records · JWKS03 / Evaluation lifecycle
From declaration to optional publication
A run is meaningful only when its system declaration, test battery, scorer, provider outcome and evidence context remain visible together.
Declare
Select the agent-system configuration and record the available runtime-proof method.
Freeze
Bind the suite, tasks, scorers, trial policy and battery fingerprint to the run.
Execute
Run required tasks and trials through the configured provider and tool boundary.
Observe
Capture responses, tool traces, task outcomes, provider errors and runtime context.
Separate
Keep aggregate task performance distinct from per-trial security-gate observations.
Validate run
Suppress results when required provider calls, fixtures or evidence are unavailable.
Bind evidence
Attach the result to the declared manifest, versions, validity period and record digest.
Publish by consent
Create a public record only when publication gates pass and the owner opts in.
04 / Evidence model
Integrity signals are not assurance conclusions
Cryptographic records can help detect alteration and identify the issuing key. They do not independently establish evaluator neutrality, measurement validity, behavioral correctness or regulatory conformity.
What the architecture records
- System declaration: provider, model, runtime mode and configuration identifiers.
- Evaluation declaration: suite, battery fingerprint, tasks, scorer and trial policy.
- Observed run data: outcomes, trial distributions, gates, provider failures and telemetry.
- Record state: signature, signing key, validity period, consent and revocation.
What still needs separate evidence
- Measurement: construct validity, reliability, calibration and cross-environment reproducibility.
- Operations: production topology, key custody, monitoring, resilience and incident response.
- Security: independent threat modeling, penetration testing and deployment review.
- Conformity: qualified legal analysis or assessment against a defined regulatory scope.
05 / Current limits
What this architecture does not establish
The public interpretation must remain no broader than the evidence generated for the exact run.
Revision: 20 July 2026 · Development release · Luxembourg
- No claim that an observed score predicts behavior for every future prompt, integration or deployment.
- No claim that a passing task or aggregate score overrides a failed required security trial.
- No claim that repository controls prove operating-system isolation, tenant separation or deployment hardening.
- No claim that framework mappings demonstrate NIST, OWASP, CISA, ISO or EU legal conformity.
- No claim of independent certification, accreditation, institutional attestation or production approval.
- Material changes to models, prompts, tools, providers, fixtures, scorers, policy or deployment require impact review and may require re-evaluation.
Review the evidence behind the architecture.
Read the evaluation model for result interpretation or inspect the internal secure-development regressions that support the current repository implementation.