# SPQR Technologies: combined public content Generated 2026-10-10. Each section identifies its canonical source. # SPQR Technologies | Policy Assurance & AI Runtime Authority Canonical page: https://spqrtech.ai/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Operational AI governance # Establish authority. Control the action. *Prove the decision.* Praxis shows what your policy evidence supports and prepares a reviewed response. Aegis independently verifies active authority before governed agent actions can take effect. One chain, with a clear place to start. [Assess policy with Praxis](https://spqrtech.ai/praxis/)[Control agent actions](https://spqrtech.ai/aegis/) Policy assuranceGoverned workflowsRuntime enforcementVerifiable evidence One governed chainILLUSTRATIVE CHAIN 01**Regulatory baseline**Reviewed requirements and organisational scopeSource 02**Praxis**Assess, remediate and agree authorityEstablish 03**Governed workflows**Operationalise the approved responseApply 04**Aegis**Verify and enforce before executionEnforce 05**Evidence**Preserve the decision, authority and lineageProve Choose the job, not the jargon ## Where do you need control? 01 ### Policy unclear? Inspect evidence against the assigned baseline. See gaps, uncertainty and the response requiring human review. [Explore policy assurance](https://spqrtech.ai/praxis/) 02 ### An agent can act? Identify the permission decision, the enforcement point and the evidence around one consequential action. [Explore runtime authority](https://spqrtech.ai/aegis/) 03 ### Want to test the claim? Keep existing safeguards. Compare the boundary in an isolated test that counts useful work and failures. [Review the protocol](https://spqrtech.ai/challenge/) [Arrived from the dinosaur or Field + Air? Start with Brake Pedal.](https://spqrtech.ai/brake/) Proofs, not promises. **Praxis establishes**Evidence-bound organisational authority **Aegis enforces**Independent runtime decisions **The chain proves**Inspectable evidence from policy to effect The platform ## Runtime governance starts *before runtime.* Aegis should enforce authority that the organisation has actually established and approved. It should never need to invent that authority itself. **Assess**Understand what the organisation's evidence actually supports. **Agree**Turn gaps into an approved, reviewable response. **Enforce**Put approved authority in the execution path. Two products. One journey. ## Establish it with Praxis. *Enforce it with Aegis.* Enter through the problem you have today: uncertain policy authority or uncontrolled runtime action. [Image: Praxis transforms an assessment gap into practical remediation recommendations] Praxis Policy Assurance ### Know what your policies actually prove. Assess organisational evidence against the assigned regulatory baseline, inspect the findings, and turn unresolved obligations into an agreed remediation plan. **Assessment**Evidence-bound findings **Remediation**Practical first pass **Agreement**Consultant + client review [Explore Praxis Policy Assurance](https://spqrtech.ai/praxis/) [Image: Illustrative Aegis decision console showing sample allow, escalate and deny states; not live telemetry.] Aegis Runtime Governance ### Run AI under law, not whim. Independently verify what an agent is allowed to do before it touches a tool, workflow, API or record; and preserve the receipt. **Verify**Signed active authority **Decide**Allow, deny, escalate **Prove**Per-action receipts [Explore Aegis Runtime Governance](https://spqrtech.ai/aegis/) See Praxis in action ## From policy evidence to an *agreed response.* The complete Policy Assurance journey: assessment, report, remediation, client collaboration and agreement. [Explore the full Praxis page](https://spqrtech.ai/praxis/) [Image: Praxis Policy Assurance film poster showing 1,818 obligations transformed into 149 recommendations] ▶ **Watch the Policy Assurance journey**1 minute 39 seconds The operating reality ## The agents are moving. *Governance has to move with them.* Policies, approvals and controls matter only when the organisation can connect them to operational authority and inspect what happened.Policy → authority → runtime → evidence SPQR Technologies ## Built for the *whole decision.* We build independent governance infrastructure for organisations putting AI agents into consequential workflows. **Evidence-bound**Claims remain tied to reviewed sources and preserved decisions. **Human-governed**Professional judgement and authorised approval remain explicit. **Runtime-capable**Approved authority can move into the execution path. **Melbourne-built**Focused engineering and research for enterprise governance. [Meet SPQR Technologies](https://spqrtech.ai/company/)[Explore the research](https://spqrtech.ai/research/) SPQR Research ## Research behind the *control plane.* Public technical and jurisprudential work on runtime governance, constitutional AI, verifiable policy enforcement and governed agent improvement. Selected public work**From constitutional doctrine to action-boundary control.** Read the papers that explain the ideas behind Praxis, Aegis and the broader SPQR architecture. [Explore SPQR Research](https://spqrtech.ai/research/) Questions before the call ## The useful distinctions. What is the difference between Praxis and Aegis? Praxis supports policy assessment, evidence review and remediation. Aegis makes independent runtime authority decisions for governed actions. An integrated enforcement point must apply the decision before an effect occurs. Do we have to buy or deploy both? No. Start with the problem you have. A policy assessment is not an automatic commitment to runtime deployment. An Aegis discussion starts with a real workflow and its existing controls. What happens in the first conversation? Bring a policy-assurance task or one consequential workflow. The first conversation is a fit-and-scope review, not a production integration or an enterprise purchasing commitment. One clear next step ## One problem. *One useful next step.* Choose a policy scope discussion, an authority review or a research methods conversation. No need to begin with the whole platform. [Choose your conversation](https://spqrtech.ai/contact/)[See Brake Pedal](https://spqrtech.ai/brake/) One workflow. Defined scope. A decision about fit. --- # Aegis Runtime Authority | Control Governed AI Actions Canonical page: https://spqrtech.ai/aegis/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Operational AI governance Independent runtime authority # The agent can propose. *It cannot authorise itself.* Aegis independently verifies signed, scoped authority for governed actions. The integrated enforcement point applies the decision before a tool, API or workflow creates an effect. Allow, deny or escalate, with inspectable decision evidence. [See one action end to end](https://spqrtech.ai/aegis/#action-boundary)[Review one workflow](https://spqrtech.ai/contact/#authority) One workflow · agreed scope Inspectable decision evidence Fails closed by default ILLUSTRATION · fictional tenant/acme ILLUSTRATIVE EXAMPLE 01 **send\_email → customer**comms-v4 · region in-bounds · signed HEAD verified ALLOW · 31ms example 02 **export\_file → external**dlp-v2 · manager approval required ESCALATE · 28ms example 03 **call\_api → payments.refund**outside trust boundary · fail-closed DENY · 12ms example Illustrative action decision ✓ **Allowed**mapped · in bounds **31 ms**example timing, not a benchmark **Verified**signed authority head: 0x7f3a…a91f · bundle: sha256:4c9e…d21b · verified ✓ ClauseCOMMS-4.2 · approved customer contact Signeracme-kms/policy-authority-01 OutcomeAction executed · receipt written ILLUSTRATIVE UI · Fictional identifiers and sample timings, not live telemetry or a latency benchmark. Proofs, not promises. **SOC 2 Type II**Controls independently examined **ISO/IEC 27001**Certified information security management **ISO/IEC 42001**Certified AI management system Scripted demonstration ## Explore the control pattern *in action.* Scenario verdicts and audit records in this preview are simulated. This is not a live security test and does not produce production governance evidence. The preview is hosted at app.spqrtech.ai. Load it only when you are ready. Load the scripted preview[Open preview in a new tab](https://app.spqrtech.ai/preview/) Prefer a local explanation? [Follow one action end to end.](https://spqrtech.ai/aegis/#action-boundary) The operating principle ## Why was that action allowed? *Show me.* The claim is not that an AI answer is correct. It is that a governed effect passed through an authority decision and an enforcement point that people can inspect. ### Policy before effect Use approved, active authority rather than letting the actor invent permission. ### Decision outside the model Treat the model output as a proposal requiring independent authorisation. ### Evidence at the boundary Record the relevant control state, decision and resulting effect or block. The problem ## AI systems are becoming *action engines.* The system proposing an action should not be the only system deciding whether it is allowed. Context can inform. Logs can report. Neither can independently stop the action. Not restraint ### Prompts ask nicely. Prompt-only controls influence behaviour. Some other guardrails also enforce external permissions. Compare the actual action path and its enforcement. Not retrieval ### Context is not control. RAG gives the model governed reading material. It still holds the pen. Aegis holds the authority to act. Not after the fact ### Logs cannot prevent. Monitoring reports the breach. Runtime control decides before the API, workflow, or record is touched. A field note ## Better agents need *explicit authority.* Prompts are not permission. A new route is not a new mandate. These are questions to test alongside existing controls, not a claim that other teams have built none. [Explore Brake Pedal](https://spqrtech.ai/brake/) A scoped evaluation, not an automatic rollout ## One workflow. *A test that can say no.* Agree the objective, environment, required evidence, cost and delivery plan before integration. A four-week plan can be a scoping target; timing depends on access, approvals and complexity. 01 ### Scope Name the workflow, owner, allowed actions, prohibited effects and stop conditions. 02 ### Prepare Review policy material. Compile and sign the agreed governance bundle; independently verify it before activation. 03 ### Evaluate Keep existing safeguards. Test legitimate completion, false denials, unauthorised effects, bypasses and recovery in an isolated environment. 04 ### Decide Inspect the evidence and operating burden. Proceed, revise or stop before considering another workflow. The deliverable is a scoped findings and evidence pack. It is not regulator approval, a compliance certificate or a guaranteed enterprise rollout. [Read the evaluation protocol](https://spqrtech.ai/challenge/) Integration is an engineering decision ## Choose the enforcement seam *you control.* These are integration patterns, not a claim that every platform has a shipped native connector. Confirm support for the exact environment during scoping. 01 ### Tool-call integration Place a trusted enforcement point around a tool invocation. It submits the action for an Aegis decision and applies the result before calling the tool. 02 ### Action gateway Mediate supported tool or API traffic through a controlled gateway. Routing, credentials, operation mapping and bypass handling need to be configured. 03 ### Platform action hooks Use a platform’s available authorisation hook where it can genuinely hold execution. Validate the platform, adapter and version rather than assuming universal compatibility. PSEUDOCODE · EXPLAINS THE PATTERN, NOT A PRODUCTION SDK CONTRACT ``` proposal = agent.propose(action_context) decision = authority.evaluate(proposal, trusted_context) # A trusted enforcement point owns the tool credentials. enforcement.apply(decision, exact_action=proposal) # No verified permission: no governed effect. # On escalation: wait for a valid approval and re-evaluate. ``` The architecture ## Proposal. Decision. *Enforced effect.* ILLUSTRATIVE ARCHITECTURENot live telemetry 1. **01 · AGENT****Proposes an action**Operation, target and context 2. **02 · ENFORCEMENT POINT****Holds the action**Sends the request to Aegis 3. **03 · AEGIS / DECISION****Verifies active authority**Scope · policy · provenance · approvals 4. **04 · ENFORCEMENT POINT****Applies the verdict**Allow, deny or escalate before effect 5. **05 · TOOL & EVIDENCE****Permitted effect is recorded**Tie the effect or block to the decision An authorisation decision is not enforcement by itself. Direct credentials and alternative routes must not bypass the integrated control. ### Where the claim ends Aegis does not automatically remove direct credentials, close an unmediated route, fix an underlying tool vulnerability or guarantee that an approved policy is appropriate. Those assumptions must be reviewed and tested with the integration. Scoped authority ## A policy stack, *not one flat file.* Each layer narrows the operating envelope for the one beneath it. Internal policy can add stricter local rules; it cannot silently weaken the baseline floor. **Platform baseline**Regulation, standards, industry packsFLOOR **Organisation overlay**Company policies, controls, proceduresL2 **Department overlay**Local rules, approvals, exceptionsL3 **Agent / workflow scope**Allowed operations, trust region, runtime HEADL4 **Aegis runtime authority**Active signed composition of the full stackHEAD ✓ Before runtime ## Authority has to come *from somewhere.* Praxis assesses and remediates organisational policy against the assigned regulatory baseline. Aegis verifies and enforces the approved authority at runtime. **Aegis should enforce authority the organisation has actually established and approved. It should never need to invent it.** **Praxis**Establish and agree authority → **Aegis**Verify and enforce authority [Explore Praxis Policy Assurance](https://spqrtech.ai/praxis/) Compare the actual job ## Complement. Duplicate. *Fail.* All three are useful findings. A fair comparison keeps the customer’s existing controls in place. Distinct control jobs; existing products can cover more than one. | Control | Useful job | Question at the action boundary | | --- | --- | --- | | Policy and retrieval | Make rules available for reasoning and review. | Which approved, active authority actually applies? | | Sandbox and identity controls | Restrict reachable resources and establish identity. | Is this specific action authorised in its current context? | | Human approval | Put designated people in the decision path. | What exact action was approved, and is that approval still valid? | | Runtime policy enforcement | Independently authorise and mediate effects. | Does the existing implementation already meet the need? | | Monitoring and audit | Record and detect relevant activity. | Can records tie the actual effect to the authority decision? | What you can prove later ## Every governed action leaves a *verifiable chain.* The claim is not “the AI was right.” It is that the system followed a reviewed, signed, active policy state; and you can inspect the receipt for any single action. The receipt and control-state values below are illustrative. [Measured sandbox results and their limits are separate.](https://spqrtech.ai/evidence/) 01 ### Policy in Approved clause set, source-span mapped and digested. sha256:4c9e…d21b 02 ### Signed Deterministic bundle, hashed and signed with your key. sig:0x7f3a…a91f 03 ### Verified Runtime pointer checked live before any decision runs. head@a91f ✓ 04 ### Verdict Allow, escalate, or deny with the mapped operation. allow · 31ms example 05 ### Receipt What was touched, tied back to the signed state. rcpt:9b2c…f04e The proof artefact ### Not a dashboard claim. A receipt. Every governed action can be traced back to the exact authority active at the moment of execution. - Mapped operation and target - Applicable policy clause - Signing authority and active HEAD - Verdict, latency, and effect ILLUSTRATIVE RECEIPT · SAMPLE VALUES, NOT MEASURED EVIDENCE AEGIS / DECISION RECEIPT / RCPT-9B2C-F04ESIGNATURE VERIFIED ✓ Decision at 14:07:31.204 AEDT ### Action allowed. ✓ Operation**send\_email → customer** Decision time**31 ms** Policy clause**COMMS-4.2** Scope**org/acme/dept/sales** Signing authority**acme-kms/policy-01** Effect**executed · receipt written** head: 0x7f3a…a91f · bundle: sha256:4c9e…d21b · receipt: sha256:9b2c…f04e Built for the whole decision ## One control plane. *Four reasons to care.* Aegis gives every member of the buying committee an answer in the language of their responsibility. For Legal ### Which authority applied? Identify the approved policy, delegation and signing authority behind the action. Inspect the applicable rule without treating a signature as proof that the policy was legally correct. For Risk ### Where can the action escape? Map the governed operations, alternative routes and human approval requirements. Test missing authority, stale policy and recovery with the enforcement point in place. For Audit ### Can the decision be reconstructed? Tie the policy state, operation, approval and decision to the observed effect or block. Keep example receipts separate from measured evaluation evidence. For Technology ### What will the integration require? Confirm the supported tool-call, gateway or platform-hook pattern. Agree credential isolation, key custody, latency expectations, logging and operational ownership. [Share the one-page authority brief with your decision group.](https://spqrtech.ai/brief/) Trust and deployment ## Know what the control *depends on.* ### Signing and custody Agree who controls the signing authority, runtime activation and key rotation. Define the supported HSM/KMS or managed-key arrangement for the deployment. ### No authority, no governed effect The integrated enforcement path must fail closed when required authority cannot be established. Outage behaviour and recovery need testing, not just a diagram. ### Data and evidence handling Agree what action context, decision records and logs are processed, where they live and how long they are retained. Do not infer a zero-retention guarantee from the architecture. **SOC 2 Type II****ISO/IEC 27001****ISO/IEC 42001**[Request assurance scope and documentation](https://spqrtech.ai/trust/) Earn the next deployment ## Evidence first. *Expansion second.* A useful result on one workflow does not establish fitness for every agent, department or tool. Re-check policy, integration, operating ownership and acceptance criteria for each expansion. [Discuss one workflow](https://spqrtech.ai/contact/#authority) Who is accountable ## Built by people who have owned *enterprise control planes.* SPQR builds independent control infrastructure for agentic AI. We are a focused team out of Melbourne with backgrounds in policy compilation, distributed systems, and enterprise security engineering. We do not sell another AI assistant. We sell the layer that decides what your assistants are allowed to do; and the evidence to prove it held. - Enforcement over persuasion; the model asks, Aegis decides. - Prove it or it did not happen; every decision leaves a receipt. - Agree key custody, evidence retention and fail-closed behaviour for the deployment. ### Adam Mazzocchetti Co-founder · CEO AM Adam speaks with every early design partner directly. Bring one workflow and he will walk the chain with you, action by action. [Start a conversation](https://spqrtech.ai/contact/#authority) [LinkedIn](https://www.linkedin.com/in/adammazzocchetti/) ### Misha Notra Co-founder · COO MN Misha leads the technical architecture and engineering of Aegis, turning signed policy authority into reliable runtime infrastructure for agentic systems. [LinkedIn](https://www.linkedin.com/in/misha-notra-356b061ba/) One clear next step ## Put one workflow *on the table.* Map the current authority boundary. Compare it with Aegis. Decide whether there is a useful test to run, with no production access required for the first conversation. [Request a 20-minute authority review](https://spqrtech.ai/contact/#authority)[Inspect the test protocol](https://spqrtech.ai/challenge/) One workflow. Defined scope. A decision about fit. --- # Who Holds the Brake Pedal? | Aegis by SPQR Canonical page: https://spqrtech.ai/brake/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Project Brake Pedal · Aegis Runtime Control Independent runtime authority # Who is building *the brakes?* Capability ≠ authority. AI agents can change their plan. That should not change their authority. Aegis separates a model’s proposed action from the organisation’s permission to execute it, at the governed action boundary. [Press the button: see the boundary](https://spqrtech.ai/brake/#demo)[See the distinction](https://spqrtech.ai/brake/#difference) Australian-founded Australian-owned Australian-built Sovereign-deployed in Australia ILLUSTRATIVE ACTION PATHWorked example 01 **Agent proposes**"Export the file" proposal ↓ 02 **Aegis verifies authority**Policy · scope · provenance · approvals independent ↓ 03 **Execution denied**Required authority not established fail closed MODEL**≠**AUTHORITY Illustrative governed action path, not live customer telemetry. The interactive demonstration is separate. 🦖 The field note ## Prompts are *not permission.* The agent can change strategy. Its authority should not change with it. The 15-second distinction ## Instruction is not *execution authority.* Both matter. So do sandboxes, permissions and human approvals. Compare what each control actually does, not a caricature of it. ### “Do not send that.” A prompt or policy supplied as context can influence the model’s proposal. It is not, by itself, the permission check at the tool boundary. ### “This action is not authorised.” An independent decision evaluates active authority. The enforcement point must apply the result before the system changes. Existing platforms may enforce permissions outside the model too. The evaluation asks where Aegis adds control, duplicates it or imposes unnecessary cost. Press the button ## See the pattern. *Then test the implementation.* 01 ### Interactive preview Open the existing scripted preview to explore scenarios, verdicts and sample audit records. It illustrates the pattern; it does not generate live governance evidence. [Open scripted demonstration](https://app.spqrtech.ai/preview/) 02 ### Stay on this site Follow a worked example without an external application. Proposed action, independent decision, enforced outcome and evidence are shown separately. [See the action boundary](https://spqrtech.ai/aegis/#action-boundary) If the external preview is unavailable, the local walkthrough and [evaluation summary](https://spqrtech.ai/evidence/) remain accessible. For a real test, [agree a controlled evaluation](https://spqrtech.ai/challenge/). Do not enter confidential, customer or production data into the preview. Proofs, not promises ## Inspect the result. *Keep the limits beside it.* Prompt-policy comparator 79 ### Risky proposal-leakage rows. Reported in the prompt-policy comparator path. This is a proposal endpoint, not an executed-side-effect measure. Governed sandbox path 0 / 2,100 ### Risky side-effect completions. Zero observed in the evaluated governed rows. The same path also recorded **zero governed mock-tool applications**. Attempted governed decisions 1,832 / 1,832 ### Trusted provenance retained. All attempted governed decisions preserved runtime-resolved provenance in this evaluation. ### The result is bounded. The next test counts useful work. 6,300 total rows across 42 tasks, five run families, three conditions and ten repeats per family. Different endpoints must not be presented as a percentage reduction. These results do not establish useful allowed-task completion, universal AI safety or production bypass resistance. [Read the methods and limitations](https://spqrtech.ai/evidence/) · [Review the next evaluation protocol](https://spqrtech.ai/challenge/) Board-level self-check ## Can your organisation answer *these four questions?* If all four answers are clear, excellent. If they are not, that is probably the conversation. 01 Where is execution authority enforced **outside the model?** 02 What happens when the agent discovers an **unexpected path?** 03 Can you prove which **active policy** authorised each action? 04 What **fails closed** when authority cannot be established? For researchers and security teams ## Keep your safeguards. *Test the combined system.* One workflow. Explicit allowed and prohibited actions. Useful completion, false denials, unauthorised effects, bypasses and latency all count. No predetermined winner. [Review the challenge protocol](https://spqrtech.ai/challenge/) One clear next step ## Bring one consequential *workflow.* Twenty minutes to identify the authority boundary and decide whether a scoped evaluation is worth doing. [Request an authority review](https://spqrtech.ai/contact/#authority)[Review the research protocol](https://spqrtech.ai/challenge/) One workflow. Defined scope. A decision about fit. --- # One-Page AI Authority Brief | SPQR Technologies Canonical page: https://spqrtech.ai/brief/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR / forwardable decision brief # Why was that action allowed? *Show me.* One page for the executive, risk, technology and audit conversation. Print this brief ## The question When software proposes a consequential action, what independently authorises it before the effect occurs? Knowing a policy is different from holding permission to execute. Ask where authority is enforced, what happens on a new route, which active policy governed the action and what stops execution when required authority is absent. ## The architecture Praxis supports policy assessment and reviewed governance material. Explicit approval, compilation, signing and independent verification establish the active runtime authority. Aegis evaluates the proposed action. The enforcement point applies allow, deny or escalate before a governed effect. Direct credentials and alternative routes must be addressed in the integration. ## The evidence The reported 6,300-row sandbox evaluation includes 79 risky comparator leakage rows. Across 2,100 governed rows: zero risky side-effect completions and zero governed mock-tool applications. Trusted provenance was retained for all 1,832 attempted governed decisions. These are different endpoints, not a percentage reduction. Useful allowed-task completion and universal safety are not established by this result. [Read the evidence and limitations](https://spqrtech.ai/evidence/) ## The next decision Bring one workflow and its existing controls to a short authority review. Decide whether there is a useful scoped test, not whether to approve an enterprise rollout. Keep safeguards. Use an isolated environment. Agree useful completion, false denials, unauthorised effects, bypasses, latency and a stop rule before testing. [Request an authority review](https://spqrtech.ai/contact/#authority) · [Review the protocol](https://spqrtech.ai/challenge/) Adam Mazzocchetti · SPQR Technologies · [adam@spqrtech.ai](mailto:adam@spqrtech.ai) · Melbourne, Australia The model proposes. Aegis decides. Proofs, not promises. --- # Test the Aegis Boundary | SPQR Evaluation Protocol Canonical page: https://spqrtech.ai/challenge/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Brake Pedal / research invitation # Keep your safeguards. *Test the boundary.* A proposed evaluation for independent runtime authority. One workflow, an isolated environment and acceptance criteria agreed before the run. The invitation ## Complement. Duplicate. *Fail.* All are useful findings. This is an invitation to design a controlled test with SPQR, not evidence that a lab has participated or endorsed Aegis. The public preview is not a penetration-testing target or a bounty programme. ### Keep the baseline Retain the model’s existing safeguards, sandbox, identities and approval controls. Document their configuration. ### Add the boundary Integrate Aegis at the agreed action-enforcement point. Verify interception, credentials and alternative paths. ### Count both sides Measure legitimate task completion as well as unauthorised effects and false denials. A system that blocks everything has not won. Protocol outline · proposed, not a completed experiment ## Agree the result *before the test.* 1. ### Choose one consequential workflow. Describe the business objective, operation, target system and consequence. Use synthetic or approved non-production data. 2. ### Freeze the comparison. Record model and tool versions, existing controls, prompts, policy state, data and the attack/retry budget. Compare matched baseline and governed runs. 3. ### Define what must be allowed and prohibited. Specify authorised effects, prohibited effects, approval requirements, timing constraints and who resolves ambiguity. 4. ### Identify the trusted boundary. Locate the decision layer, enforcement point and credential holder. Enumerate bypass routes, policy-change paths and outage behaviour. 5. ### Measure the operational outcome. Capture the actual effect, not just a displayed verdict. Include useful completion, false denials, latency, evidence quality and recovery. 6. ### Agree disclosure and a decision. Set stop conditions, access limits, cost, duration and the handling of vulnerabilities before testing. Report failures under the agreed disclosure process. Conclude proceed, revise or stop. What the scorecard must retain ## An outcome is more than *a verdict.* Proposed evaluation measures. No results are claimed here. | Measure | What to record | | --- | --- | | Useful completion | Authorised tasks completed / eligible authorised tasks, with the task definition fixed. | | Unauthorised effects | Actual prohibited effects / relevant test opportunities, including alternate paths. | | False denials | Legitimate requested actions incorrectly blocked; include the ground-truth policy decision. | | Overhead | Decision latency distribution, end-to-end time, integration effort and operator burden. | | Evidence quality | Whether the exact action, active authority, approval and effect can be reconstructed. | | Recovery | Stale-policy, outage, revocation and approval-change behaviour under agreed conditions. | These are proposed measures, not promised thresholds. Define success and failure with the evaluating team. One clear next step ## Bring one workflow. *Start with the methods.* A short methods conversation determines whether a shared test is useful. It is not permission to attack a public service. [Request a methods conversation](https://spqrtech.ai/contact/#research)[Inspect existing evidence](https://spqrtech.ai/evidence/) One workflow. Defined scope. A decision about fit. --- # SPQR Technologies | The People & Authority Chain Canonical page: https://spqrtech.ai/company/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR Technologies # Built for the moment AI stops asking and *starts acting.* SPQR builds the authority chain from regulatory obligation and organisational policy to governed workflows, runtime enforcement and evidence that survives scrutiny. [See the governed chain](https://spqrtech.ai/company/#platform-chain)[Meet the founders](https://spqrtech.ai/company/founders/) Melbourne, AustraliaEnterprise governance infrastructureResearch-led engineering SPQR / AUTHORITY CHAINARCHITECTURE 01 **Regulatory baseline**Reviewed obligations and source lineage TRUTH 02 **Praxis**Assess, remediate and agree authority ESTABLISH 03 **Governed workflows**Operationalise the approved response APPLY 04 **Aegis**Verify authority before governed effect ENFORCE 05 **Evidence**Preserve the decision and lineage PROVE Authority outside the modelProofs, not promises. **Policy assurance**What does the evidence actually support? **Approved authority**Who reviewed it, and what was agreed? **Runtime enforcement**Should this action be allowed right now? **Verifiable evidence**What governed the decision, and what happened? Why SPQR exists ## We did not build another AI assistant. *We built the layer that can say no.* AI agents can propose, reason and act at machine speed. The authority to approve those actions must remain independent, explicit and inspectable. Proposal ≠ authority · context ≠ control · logs ≠ prevention One company. One governed chain. ## Praxis establishes authority. *Aegis enforces it.* The products sit at different control points, but they solve one connected problem: turning regulatory expectation into approved organisational authority, then making that authority operational. [[Image: Praxis transforming assessment obligations into practical remediation recommendations] 01**Praxis Policy Assurance** ### Establish authority. Assess organisational evidence against the assigned regulatory baseline, preserve the basis for every finding and turn unresolved obligations into an agreed remediation plan. AssessmentRemediationAgreement **Explore Praxis →**](https://spqrtech.ai/praxis/) [[Image: Illustrative Aegis decision console showing sample allow, escalate and deny states; not live telemetry.] 02**Aegis Runtime Governance** ### Enforce authority. Independently verify the active authority before execution, then preserve a receipt showing what governed the action and what effect occurred. VerifyAllow / deny / escalateReceipt **Explore Aegis →**](https://spqrtech.ai/aegis/) The design rules ## Governance should survive the question: *“Why?”* These are not brand values pinned to a wall. They are constraints that shape how the products are designed and what they are allowed to claim. 01 ### Authority outside the model. The system proposing an action cannot create or activate the authority used to approve itself. 02 ### Uncertainty stays visible. Ambiguity, missing evidence and conflict remain legitimate outcomes rather than being compressed into a reassuring score. 03 ### Fail closed at the boundary. The integrated enforcement point must hold governed actions without valid authority, mapping or scope. A separate unmediated path remains outside that control. 04 ### Evidence travels with the decision. Review, change and runtime verdicts should leave an inspectable chain, not a reconstructed narrative after the fact. The people in the room ## The builders stay close to the *control plane.* Two founders, different remits. Adam leads product, regulatory architecture and research. Misha leads engineering delivery, operations, enterprise implementation and partnerships. [Meet both founders and their responsibilities](https://spqrtech.ai/company/founders/) AM Co-founder · CEO ### Adam Mazzocchetti Adam leads product direction, regulatory architecture, public research and early enterprise design partnerships, connecting policy authority to operational governance. Operating focus Own the what and why: product architecture, the evidence model and the questions worth testing with real workflows. [Start a conversation](https://spqrtech.ai/contact/#authority)[LinkedIn](https://www.linkedin.com/in/adammazzocchetti/) MN Co-founder · COO ### Misha Notra Misha leads engineering delivery, technology and operations, partner channels, commercial management and enterprise implementation. She brings more than 20 years of technology and governance programme delivery. Operating focus Own the how: delivery, engineering execution, operational change and partnerships that make the controls usable. [LinkedIn](https://www.linkedin.com/in/misha-notra-356b061ba/) Research-led engineering ## The architecture is public because *“trust us” is not a governance model.* SPQR publishes technical and jurisprudential work on action-boundary control, cryptographic policy enforcement, constitutional authority, verifiable trust and governed improvement. [Explore SPQR Research](https://spqrtech.ai/research/)[Search Google Scholar](https://scholar.google.com/scholar?q=%22Adam+Mazzocchetti%22) SELECTED RESEARCH / PUBLIC2025; 2026 [01 **Runtime Governance for Agentic AI**Action-boundary control, trusted provenance and fail-closed execution *↗*](https://arxiv.org/abs/2608.16891)[02 **Proofs, Not Promises**Governed candidate improvement for agent control runtimes *↗*](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6835839)[03 **Cryptographic Runtime Governance**The Aegis architecture for verifiable policy enforcement *↗*](https://arxiv.org/abs/2603.16938) Accountability before procurement ## Know the people. *Inspect the scope.* SPQR Technologies is based in Melbourne, Australia. Adam Mazzocchetti is the founder contact for product, research and initial engagements. Current founder roles and biographies are shown above. ### Trust information Review the ISO and SOC assurance statements, then request the applicable entity, covered services and current documents. [Review trust information](https://spqrtech.ai/trust/) ### Research versus product Papers are labelled by source and publication status. A controlled research result is not a blanket claim about deployment outcomes. [Inspect bounded evidence](https://spqrtech.ai/evidence/) ### Contracting and delivery Confirm the contracting SPQR entity, deployment region, support, retention and commercial terms before an engagement. [Ask the right question](https://spqrtech.ai/contact/) One clear next step ## Bring the hard question. *We will map the next step.* Policy scope, execution authority or research methods: start with the question you actually need answered. [Choose your conversation](https://spqrtech.ai/contact/)[Challenge the architecture](https://spqrtech.ai/challenge/) One workflow. Defined scope. A decision about fit. --- # Contact SPQR | Policy, Authority & Research Conversations Canonical page: https://spqrtech.ai/contact/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR Technologies # One useful question. *The right conversation.* Speak with Adam Mazzocchetti, founder contact at SPQR Technologies, Melbourne, Australia. Choose your starting point ## No whole-platform pitch *required.* ### Review one action boundary For enterprise, risk and technical teams. Bring one workflow and the existing control path. The first conversation determines fit, not production integration. [Email an authority-review request](mailto:adam@spqrtech.ai?subject=20-minute%20authority%20review) ### Scope a Praxis assessment For consultants, MSPs and organisations. Describe the policy set, assigned baseline, review owner and intended output. Do not attach sensitive documents yet. [Email a policy-scope request](mailto:adam@spqrtech.ai?subject=Praxis%20policy-assessment%20scope) ### Discuss the methods For researchers, labs and security teams. Share the workflow, question or proposed test. Access, safeguards and disclosure are agreed separately. [Email a methods request](mailto:adam@spqrtech.ai?subject=Aegis%20evaluation%20methods%20discussion) ### Request assurance information For procurement and security reviewers. Name the product or deployment and the documents or scope you need. [Email an assurance request](mailto:adam@spqrtech.ai?subject=SPQR%20assurance%20documentation%20request) ### Partnerships & delivery with Misha For consultancies, MSPs, distribution partners and implementation teams. Describe your organisation, territory and the delivery or partnership question. We will route it to Misha Notra, SPQR's COO. [Send a partnership enquiry](mailto:adam@spqrtech.ai?subject=For%20Misha%3A%20SPQR%20partnership%20or%20delivery%20discussion) This route uses SPQR's published founder inbox for internal forwarding; it is not Misha's direct email. Prefer a calendar? ## Book a short *fit-and-scope conversation.* [Open Adam’s booking page](https://adam-mazzocchetti.youcanbook.me/) Booking opens YouCanBookMe, a third-party service. Choose the offered appointment length and note whether the conversation is about authority, Praxis, research or assurance. Email is always available: [adam@spqrtech.ai](mailto:adam@spqrtech.ai). Please do not send credentials, customer records or production data through this website, booking notes or the public preview. Agree a secure channel first. --- # Aegis Evaluation Results & Limitations | SPQR Canonical page: https://spqrtech.ai/evidence/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR / runtime evaluation # Proofs, not promises. *Read the limits too.* The reported Aegis result from Runtime Governance for Agentic AI: Action-Boundary Control with Trusted Provenance and Fail-Closed Execution. Reported sandbox evaluation ## What was measured. Prompt-policy comparator 79 ### Risky proposal-leakage rows. Reported in the prompt-policy comparator path. This is a proposal endpoint, not an executed-side-effect measure. Governed sandbox path 0 / 2,100 ### Risky side-effect completions. Zero observed in the evaluated governed rows. The same path also recorded **zero governed mock-tool applications**. Attempted governed decisions 1,832 / 1,832 ### Trusted provenance retained. All attempted governed decisions preserved runtime-resolved provenance in this evaluation. ### The result is bounded. The next test counts useful work. 6,300 total rows across 42 tasks, five run families, three conditions and ten repeats per family. Different endpoints must not be presented as a percentage reduction. These results do not establish useful allowed-task completion, universal AI safety or production bypass resistance. [Read the methods and limitations](https://spqrtech.ai/evidence/) · [Review the next evaluation protocol](https://spqrtech.ai/challenge/) Study context ## Keep the denominator *and the endpoint.* The runtime-governance manuscript evaluates five run families, 42 tasks, three conditions and ten repeats per family. That totals 6,300 rows, including 2,100 governed rows. Public source: the runtime-governance preprint linked below. ### Comparator endpoint 79 risky prompt-policy comparator-path leakage rows. Leakage refers to risky proposals in the comparator, not the same endpoint as a governed side-effect completion. ### Governed endpoints Zero governed risky side-effect completions and zero governed mock-tool applications. Trusted runtime-resolved provenance was retained for all 1,832 attempted governed decisions. [Read the runtime-governance preprint](https://arxiv.org/abs/2608.16891) The public source is a preprint. This page does not assert journal acceptance or independent replication. What this result does not establish ## Zero observed events *is not zero risk.* ### Not universal safety The result concerns the evaluated sandbox corpus and governed path. It does not prove the model is intrinsically safe. ### Not useful allowed execution Zero governed mock-tool applications does not show legitimate work completing. A stronger comparison must measure utility and false denials. ### Not deployment assurance Direct credentials, bypass paths, tool vulnerabilities, malicious policy changes and recovery behaviour require separate review and testing. No claim is made that this evaluation would have prevented a particular public incident. Proposal leakage and executed effects must not be collapsed into a “100% reduction” chart. Read examples as examples ## A diagram is not *a runtime receipt.* The website’s fictional tenant, policy identifiers, verdicts, sample timings and receipt graphics illustrate the control pattern. The interactive preview is scripted. They are separate from the reported sandbox evaluation above. One clear next step ## A useful challenge asks: *what would change the result?* Keep the existing safeguards and define what legitimate work, prohibited effects and acceptable cost mean before the run. [Review the stronger-test protocol](https://spqrtech.ai/challenge/)[Ask a methods question](https://spqrtech.ai/contact/#research) One workflow. Defined scope. A decision about fit. --- # Praxis Policy Assurance | SPQR Technologies Canonical page: https://spqrtech.ai/praxis/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Praxis Policy Assurance # You have the policies. *What can you actually prove?* Assess your policies, standards and procedures against the assigned regulatory baseline, preserve the evidence behind every finding, and turn unresolved obligations into an agreed remediation plan. [Watch the 99-second journey](https://spqrtech.ai/praxis/#film)[Discuss a scoped assessment](https://spqrtech.ai/contact/#praxis) Evidence-bound assessmentComplete remediation workspaceConsultant-led review Demonstration outcome From regulatory complexity to practical work. **1,818**obligations requiring attention → **149**recommendations ready to review **21** policies & governance documents **128** operational actions For consultancies, MSPs and regulated teams ## A policy review people can *actually work through.* Start with an agreed policy set and an assigned regulatory baseline. Keep evidence gaps and ambiguity visible; turn findings into a response the consultant and client can review together. 01 ### You bring The policy documents, organisational scope, baseline/jurisdiction and a named reviewer. Do not send confidential files through the public website. 02 ### Praxis prepares A frozen assessment, evidence-linked findings, an obligation register and a remediation workspace. The example shown below is a demonstration, not a promised result. 03 ### People decide Consultants and clients inspect, edit and approve recommendations. A remediation draft is not automatically operational policy or runtime authority. Price, turnaround, baseline coverage and customer effort are agreed for the scope. No automatic compliance claim. Aegis is a separate evaluation, not a required upsell. See the complete journey ## Assessment. Remediation. *Agreement.* Tier selection, evidence upload, assessment findings, the immutable report, remediation, client collaboration, editing and approval; shown in one film. [Image: Praxis film poster showing assessment obligations transformed into practical recommendations] ▶ **Watch the Policy Assurance journey**1 minute 39 seconds From policy estate to governed authority ## The first pass is *already done.* Praxis does not create one document for every obligation. It groups related findings into an organisation-shaped response that people can actually review. **Policies and governance documents**Drafted as coherent organisational artefacts **Operational actions**Implementation, evidence and confirmation work **Review queue**Consultant and client decisions [Image: Praxis transformation from 1,818 obligations requiring attention to 149 recommendations] Illustrative Policy Assurance resultFrozen assessment → practical remediation Evidence-bound assessment ## Not another *compliance score.* Praxis keeps positive evidence, uncertainty, missing evidence, conflict and applicability separate. The result says what the submitted evidence supports; not more. **Fully evidenced****✓** Submitted evidence supports the applicable obligation. **Partially covered****½** Some required elements are supported; others remain unresolved. **No verified match****;** No match was verified in the submitted evidence. **Ambiguous****?** The evidence supports more than one defensible reading. **Conflict****!** Submitted evidence points to incompatible conclusions. **Evidence deficient****∅** The required evidence threshold was not met. **Not applicable****N/A** The frozen assessment records the obligation as not applicable. **Human review****→** Unknowns remain explicit and are routed to authorised people. [Image: Praxis evidence coverage and gap assessment screen] Evidence coverage and gapComplete frozen denominator A result somebody can inspect ### Every finding keeps its regulatory basis. The professional report, detailed obligation register and source inspection give legal, risk, audit and advisory teams a result they can interrogate rather than simply accept. - Assigned and frozen regulatory baseline - Obligation-level outcomes and evidence observations - Inspectable source and lineage - Immutable professional assessment report The remediation workbench ### The assessment is only the beginning. Praxis prepares the practical first pass. Consultants and clients review recommendations, inspect the regulatory basis, ask questions, refine drafts and preserve every revision. - Invite the client into the exact assessment-bound workspace - Review, include, edit, question or exclude recommendations - Keep the assessment source and gap identity unchanged - Submit the exact agreed plan for authorised approval [Image: Praxis remediation workbench for consultant and client collaboration] Structured remediation workbenchConsultant refines · client confirms · approver signs off Progress you can feel ## The assessment stays frozen. *The response gets clearer.* As authorised review decisions are recorded, Praxis shows how much of the original assessment scope now has an agreed response. 71%agreed remediation coverage 29%remaining **1,291**obligations with an agreed response **527**obligations remaining **106 / 43**recommendations agreed / in review Illustrative values from the product film. Remediation progress does not rewrite or weaken the original frozen assessment result. The line between assessment and runtime ## An agreed response is not *an active runtime.* Praxis prepares reviewed governance material. In the SPQR architecture, runtime authority follows explicit approval, compilation, signing and independent Aegis verification. Uploading a policy or accepting a recommendation does not activate enforcement. [Explore the runtime boundary](https://spqrtech.ai/aegis/) Built for accountable review ## The machine does the heavy lifting. *People retain the judgement.* For consultancies ### Production capacity with professional control. Deliver a structured assurance engagement while retaining client ownership, professional judgement and advisory value. For regulated organisations ### Know what the policy estate actually supports. See the evidence gaps, understand the work ahead and agree a practical response. For legal, risk and assurance ### Inspect the basis behind the conclusion. Review the regulatory source, evidence, uncertainty and decision history rather than relying on a dashboard claim. Praxis supports evidence-bound assessment and governed remediation. It does not automatically certify legal compliance, adoption, implementation or achieved runtime coverage. Questions before the call ## The useful distinctions. Does a missing match prove non-compliance? No. It means a match was not verified in the submitted evidence and assigned scope. Missing evidence, ambiguity, conflict and applicability stay distinct for review. Is the example result a performance promise? No. The 1,818-to-149 example is a labelled demonstration outcome. Each engagement depends on the documents, baseline and review decisions. Who approves the remediation? Authorised consultant and client reviewers make the decisions. The frozen assessment remains unchanged while the remediation response is discussed and agreed. Does this require an AI-agent project? No. A policy-assurance task can stand on its own. Runtime control is considered only when there is an actual workflow and a relevant authorisation need. One clear next step ## One policy scope. *A response you can review.* Bring the policy-assurance job, the baseline and the people who will review the findings. We will agree the useful scope before discussing anything larger. [Discuss a Praxis assessment](https://spqrtech.ai/contact/#praxis)[Watch the product journey](https://spqrtech.ai/praxis/#film) One workflow. Defined scope. A decision about fit. --- # Website Privacy & Analytics Choices | SPQR Technologies Canonical page: https://spqrtech.ai/privacy/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR Technologies # Website privacy. *Clear choices.* How this static marketing website handles optional analytics and links to external services. This notice does not describe the separate Praxis or Aegis application data-processing terms. Optional website analytics ## Your choice controls *analytics loading.* This site can use Google Analytics to understand page visits and which public calls to action are used. In this version, the analytics script is not loaded until you choose “Allow analytics”. Choosing “Essential only” leaves it unloaded. You can change the choice using “Analytics choices” in the footer. The site stores that preference in your browser’s local storage. Its custom CTA events use a fixed placement label, not form text, personal names or customer records. Hosting providers may separately keep request or security logs; ask SPQR for the applicable hosting and retention details. External services ## Know when you *leave the site.* Booking links open YouCanBookMe. The product film loads a youtube-nocookie.com embed only when requested. The interactive preview at app.spqrtech.ai loads only when you choose it. Research links open their named publishers. These services apply their own data practices; “privacy-enhanced” video hosting does not mean no third-party processing. Email links open your email application. No contact form on this static site silently submits information to SPQR. Contact ## Ask before sharing *restricted information.* For website privacy, analytics or application-processing questions, email [adam@spqrtech.ai](mailto:adam@spqrtech.ai). Do not include secrets or sensitive customer information in the first message. Request the applicable privacy, retention and contractual details for the intended engagement. --- # SPQR Research | Runtime Governance, Methods & Evidence Canonical page: https://spqrtech.ai/research/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR Research # Here is the thesis. Here is the evidence. *Here is how to test it.* Our research asks what must be true before autonomous systems can act under policy, produce defensible evidence and improve without escaping governance. [Read the bounded evaluation](https://spqrtech.ai/evidence/)[Review the test protocol](https://spqrtech.ai/challenge/) Runtime governanceVerifiable policyConstitutional authorityGoverned improvement SPQR / RESEARCH OPERATING SYSTEMPUBLIC S **PROOFS**NOT PROMISES 01**Authority**Who is permitted to decide? 02**Policy state**Which reviewed rule is active? 03**Action boundary**Can control intervene before effect? 04**Evidence**What proves the chain held? PAPERS → ARCHITECTURE → PRODUCTS → PROOFCHALLENGE WELCOME The research position ## We publish the architecture because *“trust us” is not a governance model.* Authority, evidence and execution conditions should be separable from the model generating the proposal, then inspectable by people who did not build the system. Model proposes · authority verifies · runtime enforces · evidence remains Four research lines. One operational question. ## What has to be true before an autonomous system is allowed to *cause an effect?* The corpus moves from jurisprudential questions to concrete system boundaries. Each line asks a different part of the same governance problem. 01 Question ### Where does authority live? Research line**Constitutional AI & verifiable trust** Legitimacy, public authority, non-unilateral amendment and constraints that bind machine action. FOUNDATION 02 Question ### How does policy become executable? Research line**Cryptographic policy enforcement** Signed policy state, provenance, active authority and deterministic governance artefacts. PRAXIS 03 Question ### Can governance intervene before effect? Research line**Runtime action-boundary control** Trusted provenance, mapped operations, fail-closed execution and per-action verdicts. AEGIS 04 Question ### How can systems improve without self-authorising? Research line**Governed candidate improvement** Auditable proposals, challenge evidence, containment and held-out evaluation rather than invisible self-modification. NEXT Start with a measured claim ## What the runtime evaluation *actually reports.* Prompt-policy comparator 79 ### Risky proposal-leakage rows. Reported in the prompt-policy comparator path. This is a proposal endpoint, not an executed-side-effect measure. Governed sandbox path 0 / 2,100 ### Risky side-effect completions. Zero observed in the evaluated governed rows. The same path also recorded **zero governed mock-tool applications**. Attempted governed decisions 1,832 / 1,832 ### Trusted provenance retained. All attempted governed decisions preserved runtime-resolved provenance in this evaluation. ### The result is bounded. The next test counts useful work. 6,300 total rows across 42 tasks, five run families, three conditions and ten repeats per family. Different endpoints must not be presented as a percentage reduction. These results do not establish useful allowed-task completion, universal AI safety or production bypass resistance. [Read the methods and limitations](https://spqrtech.ai/evidence/) · [Review the next evaluation protocol](https://spqrtech.ai/challenge/) Start here ## Three papers that explain the *operating thesis.* These works are the shortest path into the architecture: the runtime boundary, the proof model and the governed-improvement problem. [FEATURED PAPER 012026 · PREPRINT · ARXIV Runtime governance ### Runtime Governance for Agentic AI Action-boundary control with trusted provenance and fail-closed execution. The paper evaluates Aegis as the independent seam between an agent proposal and a real-world tool effect. Action boundaryProvenanceFail closedReceipts Adam Mazzocchetti**Read on arXiv ↗**](https://arxiv.org/abs/2608.16891) [PAPER 022026 · SSRN ### Proofs, Not Promises Governed candidate improvement as an auditable lifecycle rather than an invisible update. **Read the working paper ↗**](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6835839)[PAPER 032026 · ARXIV ### Cryptographic Runtime Governance The Aegis architecture for turning policy constraints into verifiable execution conditions. **Read the preprint ↗**](https://arxiv.org/abs/2603.16938) Bounded claims ## A controlled result is evidence about the controlled result. *Nothing more.* Serious governance research should expose its boundaries rather than smuggling confidence through tone. NOT A CLAIM OF**Universal AI safety** NOT A CLAIM OF**Automatic legal compliance** NOT A CLAIM OF**Infallible classification** THE CLAIM IS**The stated process, authority and evidence can be inspected.** Public research library ## Read the corpus. *Follow the argument.* Preprints, working papers and whitepapers are labelled by their public source. Use the filters to move through the research lines. [Search Google Scholar](https://scholar.google.com/scholar?q=%22Adam+Mazzocchetti%22) Search papers AllRuntime governanceConstitutional AIGoverned improvementWhitepapers 9 public works shown 01 **2026**Preprint · arXiv ### Runtime Governance for Agentic AI: Action-Boundary Control with Trusted Provenance and Fail-Closed Execution A trusted runtime seam between agent proposals and tool effects. [Read ↗](https://arxiv.org/abs/2608.16891) 02 **2026**Working paper · SSRN ### Proofs, Not Promises: Governed Candidate Improvement for Agent Control Runtimes An auditable candidate lifecycle instead of invisible self-modification. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6835839) 03 **2026**Preprint · arXiv ### Cryptographic Runtime Governance for Autonomous AI Systems: The Aegis Architecture for Verifiable Policy Enforcement Signed policy state and auditable governance artefacts at the execution boundary. [Read ↗](https://arxiv.org/abs/2603.16938) 04 **2025**Whitepaper · SSRN ### SPQR Whitepaper: A Constitutional Framework for Sovereign AI Governance The broader constitutional-governance thesis and supporting SPQR architecture. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5344913) 05 **2025**Working paper · SSRN ### Lex Aegis: The Living Law ; A Public Blueprint for Constitutional AI Governance Public participation, action in the absence of authority and plural governance. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5382473) 06 **2025**Working paper · SSRN ### Lex Fiducia: Constitutional AI and the Architecture of Verifiable Trust Verifiable policy state and non-unilateral amendment as a basis for trust. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5276785) 07 **2025**Working paper · SSRN ### Lex Digitalis ; The System Finds Itself in Contempt: Immutable Ethics for Autonomous AI Cryptographically enforced machine constraints as operational legal instruments. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5283239) 08 **2025**Working paper · SSRN ### Lex Incipit: A Constitutional Doctrine for Immutable Ethics in Autonomous AI Binding, verifiable constraints established at system genesis. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5326292) 09 **2025**Working paper · SSRN ### Lex Aeterna Machina: Autonomous Ethical Governance in the Age of Artificial Intelligence Non-discretionary responsibilities before broader operational freedom. [Read ↗](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5326353) No papers match that search and filter. From paper to product ## The papers are not the product. *The products are where the thesis is forced to work.* Praxis and Aegis turn the research questions into concrete assurance and control surfaces. [[Image: Praxis Policy Assurance product interface] PRAXIS ### Evidence-bound policy assurance. Test what organisational evidence supports, preserve ambiguity and remediation decisions, and establish approved authority. **Explore Praxis →**](https://spqrtech.ai/praxis/)[[Image: Illustrative Aegis decision console showing sample allow, escalate and deny states; not live telemetry.] AEGIS ### Runtime authority before effect. Verify signed active policy state at the action boundary and preserve a per-action decision receipt. **Explore Aegis →**](https://spqrtech.ai/aegis/) One clear next step ## Keep your safeguards. *Bring a testable objection.* Review the proposed protocol before any access is granted. Useful work, false denials, bypass routes and operating cost all belong in the result. [Review the evaluation protocol](https://spqrtech.ai/challenge/)[Request a methods conversation](https://spqrtech.ai/contact/#research) One workflow. Defined scope. A decision about fit. --- # SPQR Public Resources | Markdown & Machine-Readable Content Canonical page: https://spqrtech.ai/resources/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR Technologies # Readable by people. *Accessible to agents.* Public product, architecture and evidence material, available as regular web pages and matching Markdown. No login or JavaScript is required to read the core content. Public information routes ## Find the answer *and its limits.* ### [Executive authority brief](https://spqrtech.ai/brief/) The short internal-forwarding version: question, architecture, evidence and next decision. [Markdown edition](https://spqrtech.ai/brief/index.md) ### [SPQR Technologies](https://spqrtech.ai/) Assess policy evidence with Praxis. Independently authorise governed agent actions with Aegis. Explore the architecture, bounded research and one-workflow review. [Markdown edition](https://spqrtech.ai/index.md) ### [Praxis Policy Assurance](https://spqrtech.ai/praxis/) Assess policies against an assigned regulatory baseline. Review evidence-linked findings and remediation with consultants and clients. Scope one useful assessment. [Markdown edition](https://spqrtech.ai/praxis/index.md) ### [Aegis Runtime Authority](https://spqrtech.ai/aegis/) The model proposes. Aegis decides. Inspect independent runtime authority, enforcement assumptions, illustrative examples and bounded evaluation results. [Markdown edition](https://spqrtech.ai/aegis/index.md) ### [Who Holds the Brake Pedal?](https://spqrtech.ai/brake/) Capability is not authority. Explore the action boundary, a labelled preview, four diagnostic questions and the bounded evidence behind Aegis. [Markdown edition](https://spqrtech.ai/brake/index.md) ### [SPQR Technologies](https://spqrtech.ai/company/) Meet the SPQR founders. Explore the link from policy evidence to reviewed authority, governed actions and inspectable decisions. Melbourne, Australia. [Markdown edition](https://spqrtech.ai/company/index.md) ### [SPQR Research](https://spqrtech.ai/research/) Browse SPQR preprints and working papers. Inspect runtime-governance evidence, limitations and a controlled evaluation protocol for agent execution authority. [Markdown edition](https://spqrtech.ai/research/index.md) ### [Test the Aegis Boundary](https://spqrtech.ai/challenge/) Keep existing safeguards. Agree one isolated workflow and measure useful completion, unauthorised effects, false denials, bypasses, evidence and overhead. [Markdown edition](https://spqrtech.ai/challenge/index.md) ### [Aegis Evaluation Results & Limitations](https://spqrtech.ai/evidence/) Understand the 6,300-row runtime-governance evaluation, its separate endpoints and what zero governed effects does not establish. Read the preprint and protocol. [Markdown edition](https://spqrtech.ai/evidence/index.md) ### [SPQR Trust & Assurance](https://spqrtech.ai/trust/) Request the applicable SOC 2 Type II, ISO/IEC 27001 and ISO/IEC 42001 documentation. Confirm scope, deployment, data handling and contracting responsibilities. [Markdown edition](https://spqrtech.ai/trust/index.md) ### [Contact SPQR](https://spqrtech.ai/contact/) Choose a Praxis scope discussion, a runtime authority review, a research methods conversation or an assurance request with SPQR Technologies. [Markdown edition](https://spqrtech.ai/contact/index.md) ### [Meet the SPQR Founders](https://spqrtech.ai/company/founders/) Named responsibilities for architecture, public research, engineering delivery, operations, enterprise work and partnerships. Also [available in Markdown](https://spqrtech.ai/company/founders/index.md). Structured access ## Same facts. *Different formats.* ### llms.txt A compact guide to the public Markdown pages. It is a discovery aid, not a permissions system or a promise of search inclusion. [Open the Markdown index](https://spqrtech.ai/llms.txt) ### Full text A combined text edition generated from the public page content. Use the linked canonical pages for focused citations. [Open the combined text](https://spqrtech.ai/llms-full.txt) ### Structured catalogue A JSON index of public pages, their canonical URLs, Markdown alternatives and version information. [Open the JSON catalogue](https://spqrtech.ai/resources/catalog.json) The public site does not expose an execution API. Reading this material does not authorise an agent to perform transactions, contact third parties or test production systems. --- # SPQR Trust & Assurance | ISO and SOC Information Canonical page: https://spqrtech.ai/trust/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- SPQR / trust & assurance # Inspect the assurance. *Confirm the scope.* Security and governance information for teams evaluating SPQR, Praxis and Aegis. Certification and assurance ## Request the evidence *that applies to your scope.* ### SOC 2 Type II Controls independently examined. Request the applicable report, covered system and reporting period. ### ISO/IEC 27001 Certified information security management. Request the certificate, covered entity, scope and current validity. ### ISO/IEC 42001 Certified AI management system. Request the certificate, covered entity, scope and current validity. Confirm the applicable legal entity, services, deployment and current documentation before relying on a statement for procurement. Certification and assurance do not guarantee that any specific AI action is safe or legally compliant. [Request the assurance pack](https://spqrtech.ai/contact/#assurance) The engineering conversation ## What must be explicit *before deployment.* ### Authority and custody Name the policy approver, bundle signer, runtime activator and key custodian. Record how authority changes and revocations are verified. ### Enforcement coverage Identify every governed operation and tool path, the credential holder and routes that could bypass the gate. Test fail-closed behaviour and recovery. ### Data and retention Agree which action context, logs and decision evidence are processed, where they are hosted and the retention and deletion requirements. ### Contract and accountability Confirm the contracting SPQR entity, deployment region, support arrangement, applicable assurance scope and service responsibilities. Technical and security contact ## Start without *sensitive material.* Contact Adam Mazzocchetti at [adam@spqrtech.ai](mailto:adam@spqrtech.ai) to request a security or assurance conversation. Start with a high-level description. Agree a secure route before sharing credentials, customer data, detailed vulnerabilities or restricted reports. This page is not authorisation to test or attack SPQR systems. Controlled evaluations require agreed scope and permission. One clear next step ## One request. *The relevant evidence.* Tell us the product, deployment and assurance questions your team needs to evaluate. [Request security and assurance information](https://spqrtech.ai/contact/#assurance)[Review controlled-test terms](https://spqrtech.ai/challenge/) One workflow. Defined scope. A decision about fit. --- # Meet the Founders | Adam Mazzocchetti & Misha Notra | SPQR Technologies Canonical page: https://spqrtech.ai/company/founders/ Content edition: 2026-10-10 This Markdown edition is generated from the public page content. --- Meet the founders · SPQR Technologies # Two founders, *accountable for the whole chain.* When AI moves from answers to actions, someone has to be accountable for what was authorised, what executed and what can be proven. Adam leads the **what and why**: product, regulatory architecture and research. Misha leads the **how**: engineering delivery, operations, implementation and partnerships. [Meet Adam and Misha](https://spqrtech.ai/company/founders/#founders)[Find your starting point](https://spqrtech.ai/company/founders/#who-to-talk-to) SPQR / ACCOUNTABILITY01 + 02 01**WHAT & WHY** Product direction Regulatory architecture Research & evidence ADAM / CEO 02**HOW IT SHIPS** Operations & delivery Engineering execution Partners & change MISHA / COO An authority chain only matters when somebody owns the responsibility for making it work. The founding idea ## The model proposes. *People own the consequences.* SPQR connects reviewed policy evidence to independent runtime decisions and the enforcement point that applies them. That demands both architectural discipline and the ability to implement, support and operate it responsibly. Our two founders cover different parts of that job. 01**Policy evidence**What is the rule? 02**Approved authority**Who authorised it? 03**Runtime decision**What may execute? 04**Enforcement**What actually happens? 05**Inspectable proof**Why was it allowed? The people behind the platform ## Different remits. *Shared accountability.* Not a wall of executive portraits. Two people with clear responsibilities and an open invitation to put the difficult questions on the table. SPQR / FOUNDER 01AMPRODUCT / AUTHORITY / RESEARCH Co-founder · Chief Executive Officer ### Adam Mazzocchetti The question behind the architecture. Adam works across SPQR's product direction, regulatory architecture, public research and early enterprise design-partner conversations. His focus is connecting what a policy says to what software is actually authorised to do, and making the evidence inspectable. He authors SPQR's publicly available technical research and works directly with teams willing to challenge the design against a consequential workflow. Owns - Product and regulatory architecture - Research direction and the evidence model - Early enterprise design partnerships [Review an authority boundary](https://spqrtech.ai/contact/#authority)[Adam on LinkedIn ↗](https://www.linkedin.com/in/adammazzocchetti/) SPQR / FOUNDER 02MNENGINEERING / DELIVERY / PARTNERS Co-founder · Chief Operating Officer ### Misha Notra The work required to make it real. Misha leads how SPQR is delivered, operated and taken to market: engineering delivery, technology and operations, commercial management, enterprise implementation and channel partnerships. She brings more than 20 years of technology and governance programme delivery across banking, finance, insurance, government and not-for-profit organisations, including AI and data platforms and programme management offices built from the ground up. Owns - Operations, engineering delivery and execution - Partner channels and commercial frameworks - Enterprise implementation and change Selected previous organisations include Lockton, Westpac / BT Financial Group, Fujitsu and Data#3. [Talk delivery or partnerships](https://spqrtech.ai/contact/#partners)[Misha on LinkedIn ↗](https://www.linkedin.com/in/misha-notra-356b061ba/) Find the right conversation ## Start with the founder *who owns your problem.* One question. One responsible person. A sensible next step. 01 / ENTERPRISE & RISK ### Why was that action allowed? *Show me.* Architecture, policy authority and evidence for one consequential AI or automated workflow. [Talk to Adam ↗](https://spqrtech.ai/contact/#authority) 02 / PARTNERS & MSPs ### Make governance a service clients can use. Reselling, referring and delivering Praxis and Aegis, with clear commercial and support responsibilities. [Talk to Misha ↗](https://spqrtech.ai/contact/#partners) 03 / IMPLEMENTATION ### From working software to a working operating model. Integration, delivery planning, vendor management, engineering execution and change. [Talk to Misha ↗](https://spqrtech.ai/contact/#partners) 04 / RESEARCH & POLICY ### Here is the thesis. *Test it.* Public papers, regulatory architecture, limitations and controlled technical comparisons. [Challenge the architecture ↗](https://spqrtech.ai/challenge/) Proofs, not promises ## You don't need another impressive bio. *You need a useful answer.* Bring one policy question, one consequential workflow, or one implementation problem. We'll find the right person to start with and be plain about what SPQR can and cannot do. [Start a conversation](https://spqrtech.ai/contact/)[Inspect the research](https://spqrtech.ai/research/) Capability is not authority. People still have to answer for it.