The AHR Constitution

The Ant Hill Reasoner (AHR) is Primum AI's research system for exploring solutions to problems with explicit rules or constraints. Its proposed architecture coordinates three computational roles: a Queen sets strategy and allocates resources; a Worker builds candidate solutions; and a Scout explores alternative paths. Learned or hand-defined scores guide the search, while shared memory can carry feedback from earlier attempts into later decisions.

AHR is designed to separate the search for an answer from the evidence needed to accept it. In formal reasoning, an independent checker evaluates the declared requirements before a result is certified. Other applications may produce estimates, recommendations or exploratory candidates under clearly stated limits. The architecture and its applications may evolve. This constitution sets the responsibilities that must accompany that development; each release states what it can support and how its results should be interpreted.

We develop AHR to help people understand problems, discover possibilities and make better decisions. We value scientific curiosity, useful invention and the freedom to pursue unfamiliar ideas. We also accept responsibility for the effects of the systems we build and the claims we make about them.

Responsible development requires judgment about actual consequences. We will match safeguards to the likelihood, severity and reach of harm, taking account of uncertainty and the ability to reverse a decision. The aim is to support ambitious research and timely delivery while preserving human dignity, honest communication and accountable control.

This constitution governs Primum's development, evaluation, deployment and public presentation of AHR and its derivatives. It does not restrict the company to a permanent list of tasks, architectures, datasets or industries. Work in mathematics, science, software, engineering and other fields may proceed through the proportionate review described in Article 2.

Each deployed system or pilot must have a current release profile stating its intended use, accountable owner, supported capabilities, data permissions, output claims and operating limits. Existing restrictions remain in force for that release until its profile is properly updated. Permission to investigate a field does not itself authorise live use in that field.

Technical specifications and procedures may change within these principles. In this constitution:

Must

marks a requirement.

Should

marks an expected practice, with a reasoned basis for material departures.

May

permits discretion within the applicable boundaries.

People's worth does not depend on their productivity, wealth or a system's score. We will consider who benefits from a proposed use, who bears its risks and who can challenge its effects. A formally correct answer can still advance an inappropriate objective or overlook a relevant human need.

We should design systems that support understanding, choice and practical competence. Where use could materially affect people, reviews should consider accessibility, unfair exclusion, working conditions and the perspectives of those affected. We should also weigh substantial resource and environmental costs. These considerations must be proportionate to the use and should inform product decisions without turning every experiment into a company-wide approval process.

Project owners must classify work by its actual effects: the people exposed, sensitivity of data, degree of autonomy, scale, reversibility and consequences of error. An industry label or a research label does not settle that classification. Uncertainty about a potentially serious consequence calls for stronger review or a narrower test.

Consequential deployment includes uses capable of materially affecting health, safety, rights, livelihoods, essential services or substantial financial interests. Greater autonomy, sensitive data or broad exposure can raise the required level of review. A contained experiment in the same field may remain routine research if its boundaries adequately control those risks.

Teams may make ordinary changes within an approved profile without renewed founder or company-wide approval. A material change in purpose, exposure, permissions or consequences must be reviewed before that change takes effect. Review the changed risks and reuse relevant evidence; unrelated parts of a project need not restart approval.

Within the core protections in Article 8, decision-makers may balance benefit, uncertainty, cost and speed, and accept justified residual risk. Review must be timely: procedures must name an owner and response target, with escalation when delayed. Silence does not approve a consequential release. Proof that every conceivable risk is absent is not a condition for responsible research.

A result presented as a certified formal solution must pass independent verification of the declared hard constraints. The checker must assess the candidate against the identified formal problem; agreement with the proposing model or its confidence is insufficient. Learned components may guide search and assessment, but may not substitute for the check supporting a formal certificate.

Verification supports a defined claim. A certificate does not establish that input facts are true, that every relevant condition was included, or that acting on the result is appropriate. A feasible assignment does not prove optimality, and failure to find a solution does not establish that none exists.

Checkers and acceptance rules must be versioned and tested for their intended claims. Changes that could alter certified acceptance require competent review by someone other than their author before release. In a small team, this may be a qualified colleague or external reviewer. Routine changes that do not affect acceptance can follow ordinary engineering review.

Interfaces translating a request into a formal task must expose material ambiguity or assumptions. A translator may also support explanation and clarification, provided those outputs are distinguishable from certified results and cannot bypass acceptance controls. Material changes to an agreed objective or hard constraint require authorisation from the responsible user or owner, followed by any necessary recheck.

Search and repair must respect the declared limits on total computation and external actions. Operational limits must account for unsuccessful attempts as well as the final candidate. Certified results must retain enough information to identify the formal instance, relevant certificate, checker version and outcome for authorised review. A failed or unavailable check prevents certification.

The status of an output must be clear enough for its intended user to rely on it appropriately. Formal reasoning should distinguish certified results, requests for clarification, unresolved searches and refusals. Other modes may provide estimates, forecasts, hypotheses or recommendations, with uncertainty and validation appropriate to those claims.

An exploratory mode may return useful unverified candidates when its users understand their status and its operating conditions permit that use. Such candidates must not be presented as certified, enter a downstream process that requires certification, or reach consequential use without the review required for that setting. A disclaimer alone does not make an otherwise unsafe deployment acceptable.

We will distinguish mathematical definitions, conditional theorems, measured results and future ambitions. Public claims must reflect the system actually evaluated. Evaluation should make clear the role of exact repair, human intervention, dataset overlap and selection of favourable runs where these materially affect interpretation.

We will correct material errors when found. Evaluation should examine both incorrect outputs and unnecessary abstention, and measure usefulness at an appropriate level of assurance. Refusal must have an intelligible reason; uncertainty should lead to clarification, qualification or a safer scope where these can still serve the user.

Teams may explore new fields, architectures and methods under standing research authorisation. They may use simulations, prototypes and controlled comparisons to test uncertain ideas, including ideas that fail. The record should make it possible to distinguish an unsuccessful experiment from an unsupported claim about capability.

Before involving external users or creating live effects, the owner must identify the intended benefit, plausible failures, affected people and applicable obligations, then use the review level in Article 2. A small pilot can establish evidence for a wider release. Its scale, duration, monitoring and stopping conditions must match the risks being investigated.

Entry into healthcare, finance, education, robotics or another field does not automatically require a constitutional amendment. A release in a new setting does require relevant evidence and an updated profile. Where professional judgment or regulatory authorisation is needed, competent domain review and the required permissions must precede the affected use. Research demonstrations must not be represented as authorisation for clinical or other consequential deployment.

Evidence requirements should grow with exposure and consequence. Teams should use staged release, limited access, simulation, human review or other controls where they enable useful learning at an acceptable risk. Expansion should pause when observed results undermine the basis for approval. A new application does not inherit safety or performance claims merely because it uses the same AHR components.

AHR may use synthetic, public, licensed or appropriately authorised real-world data. Dataset choice must reflect the research purpose, rights of use, sensitivity and safeguards needed. Synthetic data is useful where it answers the question, but is not a permanent restriction on research. Public availability alone does not establish permission for every form of collection, reuse or training.

Teams must know the source and permitted purpose of the data they use, limit access appropriately and protect it against unauthorised disclosure or alteration. Existing approved datasets and uses may be covered by standing authorisation. A material change of purpose, access or sensitivity requires review of the affected permissions and controls.

Work with personal, health or other sensitive data requires an appropriate basis, suitable security and any assessments or permissions required for that use. Early work should use less sensitive alternatives when they provide adequate evidence. Unexpected sensitive inputs must be contained and handled under a documented procedure rather than silently reused.

Operational records must support investigation while limiting unnecessary retention of personal or confidential information. Define what is recorded, who can inspect it and when it is removed. Reuse for training must be covered by an authorised purpose and applicable permissions. Logging a request does not itself grant permission to train on it. Security controls and retention schedules may evolve as risks and uses change.

People remain accountable for the authority delegated to AHR. Permissions may cover a defined class of routine actions, so a system need not seek fresh approval for every step. The scope, resource limits and means of intervention must be appropriate to the task. A valid certificate alone does not authorise an external action.

Systems must operate within their granted permissions and allow authorised operators to stop or restrict them. Expanding access, taking materially different actions or increasing consequential autonomy requires the appropriate review. Human oversight must give the responsible person enough information, time and practical authority to intervene.

People materially affected by consequential use should have an accessible way to raise concerns and obtain human review where appropriate. Primum must not disguise a system as a human, claim professional authority it lacks or design interactions to exploit vulnerability or dependence. Interfaces should help users understand relevant limits without overwhelming them with technical detail.

Public communication may explain our questions, methods and progress while protecting legitimate intellectual property, confidential information and security-sensitive details. Transparency does not require publication of source code, model weights or private datasets. It does require accurate capability claims, material limitations, appropriate reporting of serious failures and access to evidence for authorised reviewers. These duties apply to products, demonstrations and the ATLAS blog.

The following protections apply across research and deployment. Ordinary project decisions and temporary procedural exceptions cannot waive them.

• We must not knowingly misrepresent evidence, capabilities or the status of an output, or label an unchecked result as certified.
• We must not use technical success as a substitute for required human authority, data permissions or approval for the intended deployment.
• We must not design operational systems to evade authorised intervention, conceal consequential actions or expand their own permissions without authorisation.
• We must not proceed with an intended use involving serious abuse, coercion, exploitation or unlawful harm. Credible evidence of serious risk requires effective controls, a narrower scope or suspension of the affected use.
• We must preserve accountability for material decisions and failures, and must not retaliate against people who raise concerns in good faith.

Controlled testing may deliberately exercise failure cases, compare systems without particular controls, or investigate misuse. Such work requires appropriate containment, authorised access and clear experimental status. Outputs must remain within the authorised evaluation and must not reach a live process that relies on the disabled protection. This permission supports testing; it does not change the requirements for release.

Primum's governing authority must assign responsibility for engineering assurance, data protection, release decisions and this constitution. One person may hold several roles where competent, subject to required independent review. Decisions should sit with the closest competent owner whose delegated authority covers the risk; higher-level approval is reserved for matters outside that authority.

Records may be concise. A material release decision must identify its owner, intended use, evidence, significant unresolved risks, controls and approval conditions. Existing engineering records may satisfy this requirement. Reviewers should state a concrete concern and the evidence or change needed to resolve it. Disagreements must have a named escalation route and a recorded resolution.

Anyone identifying credible imminent serious harm may stop the affected test or operation and promptly notify the owner. Other material concerns must receive timely review. Containment should be limited to the affected capability unless the failure could extend further. The owner must preserve necessary evidence, assess impact, arrange correction and authorise restoration only when the basis for safe operation has been re-established.

We will inform affected parties and authorities as required, and communicate material failures in proportion to their consequences while protecting privacy and security. Lessons should improve tests, controls and release profiles. A defect in a checker requires assessment of previously accepted results. Good-faith reporting must be protected even when investigation does not confirm the concern.

Architecture, benchmarks, thresholds, dataset choices and operating procedures may evolve under delegated authority. Entering a new field or improving a control does not itself require amendment. We will review this constitution at least annually and when experience reveals a material gap in its principles or governance.

Before a temporary procedural exception takes effect, the accountable risk owner must record its reason, scope, expiry, substitute controls and review arrangements. Consequential exceptions require a competent reviewer independent of the proposer. Exceptions cannot waive Article 8 or applicable obligations. Emergency protective action may occur immediately, with the decision documented promptly.

Constitutional amendments require the governing authority or a body formally delegated that responsibility to approve a dated rationale. A material reduction in protection requires independent assessment of its consequences before adoption. Independent review may be internal where the expertise and separation are adequate, or external where they are not. Unanimous founder approval is not a standing requirement.

The adopted public constitution and material amendments must be accessible, with prior versions retained. Confidential supporting evidence may be reviewed under appropriate access controls. Before adoption, Primum must designate the responsible roles and reporting route. Draft status does not establish adoption or demonstrate that every stated control is already implemented.

Selected influences include Claude's Constitution on judgment and responsibility; the Pro-Human AI Declaration on human agency and honest capability claims; and Magnifica Humanitas on dignity, shared responsibility and decisions made close to the people affected. These are secular commitments here. No religious belief is required, and inclusion does not adopt every position in a source. The technical description draws on AHR Unified Mathematical Theory.

• Claude's Constitution
• The Pro-Human AI Declaration
• Magnifica Humanitas