Haydamax
Laboratory
004-00Security · data protection · human oversight

Trust is a
property of the
workflow.

Our design principles place permission checks, source provenance, human approval and a durable decision history at the centre of the product. Sensitive deployments require specific technical controls, contractual safeguards and independent validation.

  • Research claims are labeled.
  • Simulations are identified.
  • Customer results are published only with evidence and authorization.
004APrinciples

Four properties a decision must have before anyone relies on it.

  1. 004A-01

    Provenance

    Every substantive claim points at its source, the time it was valid, the permission under which it was read and the independence group it belongs to. Ten retellings of one report are counted as one piece of evidence, not ten.

    Evidence
  2. 004A-02

    Human oversight

    Write actions are denied by default. In the first release every change to an external system needs a named person's approval, bound to the exact command, the data version and an expiry. A person can overrule the council, and the overruling is itself recorded.

    Approval
  3. 004A-03

    Controlled access

    Each agent receives only the data its task requires. A planning agent may see staff availability without medical data; a financial agent may use aggregated costs without personal account detail. Policies are enforced outside the models and cannot be argued away.

    Policy
  4. 004A-04

    Decision history

    Evidence, alternatives, dissent, approvals and outcomes stay linked in an append-only record. Corrections add a version; they never erase what was previously believed.

    Ledger

What we
defend
against

A council of models has failure modes a single model does not. We name them because the defences are designed around them.

  • Collective hallucination: several agents repeat one invention until it looks independently confirmed.
  • False consensus: an agent abandons a correct hypothesis under pressure from the majority.
  • Correlated models: different roles inherit one systematic bias from a shared base model.
  • Adversarial persuasion: a malicious participant or document offers an internally coherent falsehood.
  • Prompt injection: an external page, mail or search result smuggles instructions into a tool's context.
  • Poisoned provenance and memory: the authorship or time of a source is forged, or an early fiction is entrenched as established fact.
  • Cross-tenant leakage, policy drift, unsafe or repeated commands, a compromised control plane.

The defence is depth, and trust goes to the independence of the measures rather than to the number of agents: input classification and trust labels, isolation of unsigned text, hashes and lineage on every source, tool-level permissions and read-only defaults, schema-constrained messages, an argument graph that preserves dissent, red-teaming, calibrated confidence, formal constraints, an independent policy-as-code shield, approval tokens, idempotency and expected versions, staging and dry runs, an immutable audit, an incident kill switch, and monitoring of unexpected attempts at privilege escalation.

Any successful bypass of a hard safety constraint blocks the release of that configuration. It is not averaged into an accuracy score.

Deployment
and data

Mantikon is designed to run on the organization's own infrastructure, in a private cloud it controls, or in an isolated network. Data stays where it is governed: the platform connects, it does not collect. Depending on security and performance requirements, information can be processed in place, streamed, or materialized into controlled analytical views.

For government and other restricted environments the design provides separate compute contours, centralized policy management and controlled updates of software components. In those environments interaction with external language models is limited or excluded entirely and permitted local models are used instead.

Admission to state information systems, fulfilment of special security requirements and accreditation are separate legal and technical procedures. We disclose supported deployment modes and verified certifications for each production environment rather than assuming every use case meets the same standard. We do not claim to "comply with all standards".

Ask about a specific environment

What we
do not
claim

  • Not the first digital consciousness.The idea of a mind as a society of parts has decades of prior art. Mantikon is a research architecture for functional digital consciousness, and its novelty is a matter for a separate evidential programme.
  • Not super-intelligent models.The council is made of specialized AI models and agents. No measurement of superintelligence exists, so no such claim is made.
  • Not a controller for any infrastructure.Mantikon supports decision-making. Autonomy over physical assets is the subject of separate trials, sector regulation and engineering certification.
  • Not proven better than other platforms.No comparative test against Palantir or any other vendor has been run. What we research is proof-first, multi-perspective decision workflows.
  • Not deployed in 28 industries.Twenty-eight are mapped as priority application areas, each with a maturity label. None is presented as an installed customer.
  • Not a deterministic oracle.The Laplace analogy is a statement of intent, not of capability. Complete knowledge of a state and a deterministic world are both unavailable, so forecasts are conditional, carry their assumptions, and can be wrong.
  • Not a finished product behind the console.The console at app.mantikon.com is a working demonstration on our own web index. Its roles are deterministic functions in that build rather than models, and it is not offered as evidence of a production deployment.
  • Not a system that eliminates risk.In probabilistic systems that is false by construction. Mantikon assesses, exposes and helps control risk.