Our Trust Model

Trust in AI systems requires more than technical capability. It requires unambiguous rules about who holds authority, when decisions are made, and how accountability is permanently recorded.

Majormatic is built on a single non-negotiable principle: AI is infrastructure, Human is authority. The platform executes structured computation. You make every decision. No output is finalised without your explicit action. No logic updates silently. No learning happens without your approval.

Governance Pillars

โœ‹

Human is Final Authority

Every output remains a draft until a human explicitly acknowledges and finalises it. The platform enforces this at the architecture level โ€” there is no configuration or tier that bypasses it.

Why it matters: Prevents silent delegation of professional responsibility to software. Professional accountability cannot be assigned to an algorithm.
๐Ÿ›ก๏ธ

Platform-Enforced Rules

Governance happens at the Kernel level, not through user discretion. Policy, validation, supervision, and execution risk classification are enforced automatically and cannot be opted out of.

Why it matters: Consistent enforcement regardless of user behaviour, workload pressure, or tier level.
๐Ÿ“Š

Complete Audit Trails

Every execution creates immutable records. What ran, when, with what inputs, what governance checks applied, which supervision patterns were recorded, and who finalised the output.

Why it matters: Enables compliance review, legal defensibility, and dispute resolution โ€” by any auditor, at any time.
โš–๏ธ

Clear Liability Boundaries

Finalisation creates a permanent, explicit boundary. Before finalisation, outputs are platform-managed drafts. After, they are user-owned decisions with a sealed audit signature.

Why it matters: Establishes unambiguously who is responsible when outputs are used professionally, reviewed by clients, or subject to regulatory scrutiny.

Full Lifecycle Governance

Every execution passes through a defined, enforced lifecycle. Each state has distinct rules. ACKNOWLEDGED and FINALISED are not the same state.

DRAFT

Platform-Generated Draft

The Kernel executes and produces a validated output. It is structurally validated against the app's result schema. The output is delivered to you as a draft. It is editable and not yet committed to any record.

Editable by user ยท Not finalised ยท Not charged if validation fails
โ†“
REVIEW

Under Human Review

You review the draft. This is where your Human Layer inputs โ€” notes, amendments, flags, overrides โ€” are recorded. All human inputs are tracked separately, highlighted in the output, and carried forward into exports.

Human Layer inputs recorded ยท Supervision patterns may be added ยท Still editable
โ†“
ACKNOWLEDGED

User Edit Locked

Explicit acknowledgement locks the output to ordinary editing. This is NOT immutability โ€” it is a professional commitment that the output has been reviewed and is ready for finalisation or export. Timestamp and user identity are recorded.

Edit-locked ยท NOT yet immutable ยท Export-ready ยท Pending finalisation
โ†“
FINALISED

Immutable System-of-Record

Finalisation seals the record. The output becomes immutable. An audit signature is applied. This is the system-of-record state โ€” suitable for compliance submission, legal use, and regulatory inspection.

Immutable ยท Audit-sealed ยท Legally defensible ยท System-of-record
โ†“
ARCHIVED โ†’ PURGED

Retention & Purge

After the active workspace window (30 days by default), records transition to archived state. Vault extension is available for monetised continuity. Records are purged according to retention policy unless extended. Strict data minimisation is enforced.

Policy-governed ยท Vault extension available ยท No indefinite default retention

Supervision Patterns

Supervision patterns are your recorded professional judgements. They are a first-class data type โ€” tracked, typed, and governed with their own confidentiality tiers.

FLAG

Marks a concern, uncertainty, or item requiring further attention. Carried forward in the pipeline truth.

COMMENT

Adds professional context, clarification, or explanatory notes to the output record.

OVERRIDE

Documents where you have explicitly departed from the platform-generated output and why.

DECISION

Records a formal professional judgement applied at this stage โ€” the most authoritative pattern type.

Confidentiality Tiers

Not all supervision patterns are equal. Confidentiality tiers control who can view each pattern:

STANDARD

Normal professional notes. Visible to all authorised workspace users.

SENSITIVE

Stronger restrictions. Visible only to specified roles within the workspace.

RESTRICTED

Highly confidential. Visible only to the owner and explicitly authorised reviewers. Excluded from governance aggregation by default.

Core principle: Supervision patterns are always transparent to the owner. No shadow profiling. No hidden signals. The owner always has full visibility of every pattern recorded against their work.

Execution Risk Classification

Every execution is classified by risk level before it proceeds. Risk determines the governance requirements.

LOW

Standard single-approval execution. Confirmation from the executing user is sufficient.

MEDIUM

Review required before finalisation. Output must pass an additional review step.

HIGH

Multi-stage approval required. Execution proceeds through additional governance checkpoints.

CRITICAL

Multi-expert approval required. Multiple qualified users must sign off before the record is sealed.

Risk classification is determined by the platform at execution time based on the app, the inputs, the data classification, and the jurisdiction context. It cannot be manually overridden by users.

Kernel Doctrine โ€” Non-Negotiable Rules

The following rules are structural properties of the platform. They apply at every tier, for every user, without exception:

LOCKED

No Auto-Learning

The platform does not learn automatically from executions. Supervised patterns are collected signals only. They do not update execution logic without explicit human review and versioned deployment.

LOCKED

No Silent Updates

No logic change, governance update, or execution behaviour change is deployed silently. Every change goes through signal aggregation โ†’ human review โ†’ versioned deployment with audit log.

LOCKED

No Kernel Mutation

The Kernel โ€” the sole execution authority โ€” cannot be modified by any developer, app, user, or automated process. Kernel logic changes require explicit human approval and are logged immutably.

LOCKED

Human Approval Required for All System Changes

Any change to platform logic, governance defaults, or execution rules must be approved by a qualified human authority before deployment. Approval records are mandatory and rollbacks are always auditable.

Who Is Responsible for What

Platform Responsibilities

  • Enforce lifecycle governance and output validation
  • Execute apps according to ABI specifications
  • Apply security, access controls, and RBAC
  • Maintain immutable audit trails
  • Classify execution risk and enforce governance matrix
  • Protect data according to privacy and retention commitments
  • Ensure no silent updates and no auto-learning

User Responsibilities

  • Review outputs before acknowledgement
  • Assess fitness for professional use
  • Record supervision patterns accurately
  • Accept professional liability for finalised outputs
  • Comply with applicable professional standards and regulations
  • Maintain account and session security

Developer Responsibilities

  • Define accurate, complete ABI specifications
  • Ensure domain expertise is current and valid
  • Maintain app accuracy as laws, regulations, and standards change
  • Follow Appstream publishing policies and governance requirements

Trust in Practice

Our governance model is designed for professional environments where mistakes have real consequences โ€” legal liability, regulatory breaches, financial error. We do not ask users to "trust the AI." We provide infrastructure that makes trust verifiable, recorded, and defensible.

Example: Legal Matter Analysis

When a solicitor uses Majormatic to analyse a matter:

  1. They select the app, provide structured inputs, confirm the cost
  2. The platform executes through governed pipeline stages; statutory references are verified against UK Gov APIs
  3. A validated draft is delivered with sources attached
  4. The solicitor reviews, adds supervision patterns (FLAGs, COMMENTs, a DECISION), and acknowledges
  5. They finalise โ€” the record is sealed, immutable, and audit-signed
  6. An export package is produced: output + human inputs + source references + full audit trace

Result: The platform provided governed computation. The solicitor made the professional decision, recorded their judgements, and takes professional responsibility for the finalised output. The audit trail proves this unambiguously.

Related Topics

Governance You Can Demonstrate

Every execution is supervised, every output is a draft until finalised, every record is immutable.