R-TITAN
ITBack to site

Documentation

A concise reference to the R-TITAN architecture: operational profiles, control decisions, document lifecycle and stated limits. For the full technical dossier, get in touch.

Last updated: 27 September 2026

Scope of this page

This documentation describes the operating model. It does not attest that a specific function is active in the environment you have access to: the actual state is always the one shown by the console.

Operational profiles

The profile determines how much autonomy is granted and which controls apply. It is proposed by the interface and verified by the server: it cannot be imposed from the browser.

G3_BASELINE_SINGLE

Baseline G3

Frozen single-agent baseline; reference path and controlled fallback.

GOVERNED_STANDARD

Governed Standard

Operational autonomy with proportionate controls and limited composition.

MISSION_CRITICAL_MULTI_AGENT

Mission Critical

Supervisor and specialists with delegation, verification and red teaming.

Gateway decisions

Every relevant action receives an explicit decision, shown with its reason. No request ends in silence.

Allowed

ALLOW

The action proceeds within the authorised perimeter. It is not a judgement on the quality of the result.

Review required

REQUIRE_REVIEW

A human decision is needed before proceeding. No automatic execution.

Denied

DENY

The action is blocked. No automatic downgrade to a less controlled profile.

Abstention

ABSTAIN

The system states it cannot conclude. A valid outcome, shown as such.

Document lifecycle

Storage, technical admission and analysis authorisation remain three distinct steps. An uploaded document is not automatically an analysable document.

  1. 1UploadThe file enters a separate private area. The server computes the digest of the bytes it received.
  2. 2QuarantineNo processing until checks on type, size and content are complete.
  3. 3AdmissionThe document becomes available only after those checks. If a check does not respond, it stays out.
  4. 4Authorised analysisExecution starts only with profile, perimeter and limits declared in advance.
  5. 5EvidenceEvery execution leaves a verifiable trace, including when it ends in an error or an abstention.

Application interface

The console communicates with a server layer exposing a limited set of operations. The list is given for description only: access requires authentication and authorisation verified on every request.

GET/api/v1/capabilitiesEnvironment, permitted profiles and reasons for unavailability
GET/api/v1/documentsList of documents in the authorised workspace
POST/api/v1/uploadsUpload to private archive with server-side verification
GET/api/v1/runsList of recorded runs
POST/api/v1/runsRegistration of a run, with idempotency key
GET/api/v1/runs/{id}Status of a run and its sequence of events

Stated limits

  • The analysis engine is connected to the platform in pilot mode: missions on public or synthetic documents are run and produce outputs that are not certified. Where the runtime is not configured, a mission remains recorded with status RUNTIME_NOT_CONFIGURED.
  • The connectors listed in the «Ecosystem» section are planned and start disabled. The official legal sources consulted by the engine are limited to an allow-list of domains.
  • No regulatory compliance certification is claimed or implied.
  • A cryptographic digest proves byte correspondence against the reference, not publisher identity nor autonomous legal validity.
  • System outputs are analysis support and do not replace the assessment of a qualified professional.

Full technical dossier

Detailed architecture, test metrics, validation boundaries and source register are collected in a technical dossier available on reasoned request. Write to founder@r-titan.com

Contact

For any request concerning this page: founder@r-titan.com