Our Technology

The engineering behind our products.

Explore selected systems that support how PIA protects, remembers, reasons, creates and acts. These capabilities form part of a wider technology portfolio and are developed across our products at different stages.

Explore the systems ↓

Our Charter is an engineering obligation.

The American AI Charter sets expectations for the whole company: human authority, truthful evidence, privacy, independent review and the freedom to question or change course. Our engineering translates those commitments into defined responsibilities, permission boundaries, review processes and evidence of what actually happened. Each section below connects a technology to the Charter principles it is designed to support and states its current development position.

Read the founding Charter →

01 / System responsibilities

PIA Protect

Intelligent assistance when something feels wrong.

Help people examine suspicious messages, links, invoices and requests, understand the concern, and decide what to do next.

Protection architecture; release-specific

Supplied material → Risk + context → Clear explanation → Human decision — Conceptual responsibilities. Permission enforcement and independent audit remain separate.

Explore the technical explanation

PIA Protect is the customer-facing protection identity within the PIA family. It is designed to help people assess suspicious material and consequential choices, with clear explanations and proportionate safeguards. Its purpose is to strengthen the person's judgment while preserving their authority.

The architecture separates the material being examined from the instructions that govern the assistant. A message, invoice or webpage can contain useful evidence, but its contents should not acquire permission to change accounts, disclose information or execute an action. Fluent or urgent language is treated as material to assess.

Protection is also separated from enforcement. PIA Protect explains concerns and possible next steps. Permission controls govern any connected action; AUDI provides a distinct review function; recovery arrangements address incidents. These are cooperating responsibilities rather than several names for the same feature.

The design calls for care proportionate to the consequence: money, identity, health, safety, privacy and irreversible effects require stronger evidence and human judgment. Where the evidence is incomplete, the response should communicate uncertainty. No protection system can promise perfect detection, and warnings should remain intelligible rather than coercive.

Charter connections

Article X · Protection of the person Article IV · Human sovereignty Article VII · Intelligence without domination

Protection should inform the person, use proportionate controls and preserve a human decision.

Current development position

PIA Protect is the current protection identity. Specific functions and customer availability depend on the product release; this overview is not a claim of universal deployment or immunity.

02 / System responsibilities

PIA Orbit

From an ordinary-language brief to organised creation.

Coordinate build work, separate review and saved checkpoints so a website can develop through a connected conversation.

In internal use; customer access planned

Customer brief → Coordinated work → Separate review → Owner decision — Conceptual workflow. Saved checkpoints connect the work; product integration is planned.

Explore the technical explanation

PIA Orbit is our development coordination system. It brings a lead coordinator, parallel build tasks, separate review and saved checkpoints into a connected workflow. We use it internally to develop websites and digital experiences.

A creative brief often becomes several related tasks: content, interface, implementation, checking and refinement. Orbit's coordination approach keeps those tasks connected to a shared objective and to identifiable outputs. Parallel work can contribute to the result without making every worker the authority for the whole project.

Build activity, review and acceptance have different roles. A worker can produce a candidate; review examines it; acceptance establishes which result is carried forward. Checkpoints preserve the state of the work so that an unfinished task can be resumed without treating an earlier attempt as the final result.

The planned customer experience brings this approach into PIA Office and PIA Premium: describe a website in ordinary language, review a working draft and refine it through conversation. Customer access remains in development. Creation, acceptance and publication should remain distinguishable, and consequential release decisions remain subject to the applicable human authority.

Charter connections

Article XI · Human work and learning Article V · The right to understand Article XIII · Governance and correction

Extend people's ability to create while keeping the work, review and release decisions understandable.

Current development position

Current internal use is reported by the founder and supported by historical workflow records. Office and Premium integration is a planned direction, not a released customer website-building service.

03 / System responsibilities

PACE

PIA Adaptive Compute Engine.

Match the combination of reasoning, tools, context, time and resources to the work and its consequences.

Architecture + evidenced foundations

Task + constraints → Resource choice → Work plan → Evidence review — Resource choices do not enlarge permissions. Diagram is conceptual, not a routing specification.

Explore the technical explanation

PACE is the architecture for choosing how much effort a task deserves and how that effort should be organised. A quick answer, a careful investigation and a consequential action call for different combinations of reasoning, tools, evidence and review.

The design considers more than model selection. Complexity, urgency, available context, error consequence, quality expectations and resource constraints can influence the work plan. User preferences such as speed, depth or cost should inform that plan without silently weakening necessary safeguards.

Resource allocation is kept separate from permission. A deeper reasoning path or additional workers may improve analysis, but it does not grant access to another account, authorise spending or remove an approval requirement. Compute is a means of doing the authorised work, not a source of new authority.

The quality of the result must still be judged against the task and its evidence. More computation is not proof of correctness. The architecture therefore connects resource choices with the required standard of work and the evidence available, rather than assuming that the most expensive route is always the most appropriate.

Charter connections

Article V · The right to understand Article X · Protection of the person Article XII · Stewardship

Use resources responsibly and take greater care where error would have greater consequence.

Current development position

PACE is a documented architecture with supporting foundations and telemetry evidence. That evidence does not establish that every adaptive route is deployed in every product.

04 / System responsibilities

Memory & Continuity

Remember usefully. Leave room to change.

Separate current work, saved knowledge and preferences so continuity helps the person without fixing them in an old profile.

Limited foundations; broader architecture

Current task → Relevant context → Saved continuity → User correction — Distinct information purposes, governed retrieval and correction; not a database schema.

Explore the technical explanation

Useful continuity is more than retaining a transcript. PIA's memory architecture distinguishes the current task from information intended to persist, with attention to purpose, permission and correction. A project can remain resumable without every detail becoming permanent personal history.

The architecture separates task state, saved memory, preferences, profile information and evidence records because they serve different purposes. Retrieval should bring forward relevant context for the present job rather than treating every retained item as equally current or appropriate.

Explicit corrections should take precedence over inferred preferences. A past choice is not an irrevocable instruction, and sensitive facts or authority should not be invented from behavioural patterns. Specialist work draws on a governed continuity layer so that separate tasks do not create conflicting customer identities.

Control of memory extends beyond what appears on a screen. Inspection, correction, limits and removal are design requirements, with technical and legal constraints stated where applicable. Deletion and removal of references require implementation work; the architecture alone is not proof that every retention path already behaves identically.

Charter connections

Article VI · Memory without imprisonment Article III · Liberty of judgment Article V · The right to understand

Continuity should serve the person, preserve meaningful correction and allow a new beginning.

Current development position

Limited state and continuity foundations are evidenced. Broader memory controls remain subject to implementation and release verification.

05 / System responsibilities

Privacy & Data Control

Useful context, carefully shared.

Limit information exposure to what the authorised task needs, while preserving boundaries between people, organisations and providers.

Documented architecture; path-specific controls

Authorised task → Context boundary → Selected material → Provider response — Conceptual information boundary. Exact provider handling follows the applicable product and contract.

Explore the technical explanation

PIA's privacy architecture is designed around selective connection. External models and services can be useful without every service receiving the entire customer relationship. The aim is to provide the context needed for an authorised task while keeping other information outside that task.

The architecture treats selection of context as a deliberate boundary. Information supplied to an external service should be relevant to the task and consistent with the applicable permission and provider terms. Access to a connected service is not a reason to forward unrelated documents, remembered facts or organisational data.

Organisational separation also requires enforceable controls. The Office engineering baseline describes tenant ownership, server-controlled roles and separate retrieval or policy paths where applicable. A conversational instruction to keep two companies apart is not a substitute for access controls.

Minimum-context design and provider obligations address different parts of privacy. Technical boundaries govern what is sent and who may access it; contracts and product terms govern provider handling and secondary use. The depth of implementation must be checked for the actual route and release. This architecture is not a claim that data never leaves PIA or that every provider has identical retention terms.

Charter connections

Article VI · Memory and control Article X · Protection of privacy Article V · The right to understand

Make information use purposeful, bounded and understandable to the person it affects.

Current development position

Minimum-context privacy is documented architecture. Implementation depth and provider conditions vary by integration and product release.

06 / System responsibilities

Specialist Intelligence

One PIA relationship, with depth where it matters.

Bring specialist knowledge, tools and workflows into a consistent relationship without creating new identities or hidden authority.

Documented architecture + foundations

One PIA relationship → Specialist context → Bounded tools → Shared continuity — Specialist depth changes the context and methods, not the customer's identity or authority.

Explore the technical explanation

Travel planning, business work and research require different context and methods. PIA's specialist architecture allows that depth to sit behind a consistent customer relationship. The person should not have to manage a disconnected collection of assistants to carry their work forward.

Specialist routes contribute domain knowledge, tools, workflow structure and provider connections. They are context and capability layers; they are not a reason to create a separate customer identity or a competing set of instructions about who the person is.

Capability discovery and claims control have complementary roles. A capability record describes what a route is intended or able to do; public wording still needs to reflect the current evidence, dependencies and release conditions. A planned integration should not become a live product claim merely because it appears in a catalogue.

Specialist depth remains bounded by shared permissions and continuity. A travel route does not gain spending authority simply because a trip involves bookings. A research route does not gain unrestricted access to private material. The distinction is between a better-informed way of doing the task and a larger mandate to act.

Charter connections

Article V · The right to understand Article IX · Knowledge and evidence Article IV · Human authority

Make specialist assistance coherent and honest about its capabilities while preserving the person's authority.

Current development position

The specialist architecture is supported by documented capability, delegation and shared-identity foundations. Available routes and integrations remain release-specific.

07 / System responsibilities

Governed Actions & Evidence

Know what was authorised, and what actually happened.

Keep access, permission, execution and proof distinct so consequential work remains reviewable.

Built foundations; action-specific availability

Proposed effect → Authority gate → Execution attempt → Evidence + outcome — Conceptual action lifecycle. Unknown and partial outcomes remain valid states.

Explore the technical explanation

A connected account creates technical access. It does not provide unlimited authority to act. PIA's action architecture separates the proposed effect, the authority for that effect, the execution attempt and the evidence of the outcome.

Before a consequential action, the design considers what will change, who or what will be affected and whether the relevant authority applies. Reading and drafting can be treated differently from publication, payment, deletion or security changes. A material change to the recipient, amount, scope, timing or effect requires the authority decision to be reconsidered.

Protected execution is intended to pass an authority or policy boundary outside ordinary conversational generation. A persuasive answer is not itself an enforcement mechanism. This separation provides a place to permit, hold or decline an action according to the actual product controls.

After execution, states such as prepared, attempted, submitted, confirmed, partial and unknown remain distinct. A provider acknowledgement may establish submission without proving the real-world result. If a consequential action may already have happened, the system should reconcile provider state before retrying and risking a duplicate. Evidence should support what the interface says is complete.

Charter connections

Article IV · Independent human authority Article V · The right to understand Article X · Consequential care Article XIII · Review and correction

Tie consequential work to explicit authority and distinguish a completed action from an unverified claim.

Current development position

Current evidence supports action definitions, receipt-support structures and selected connected-action foundations. Availability and enforcement must be established for each product route.

08 / System responsibilities

AUDI

Independent scrutiny within the PIA governance architecture.

Examine authority, evidence and contradictions through a review role separate from the work being examined.

Current governance function

Work + records → Independent review → Evidence findings → Correction + check — Functional separation of review, not external certification or a claim of universal automatic enforcement.

Explore the technical explanation

AUDI is the current identity of the PIA Auditor function. Its purpose is to scrutinise evidence, authority, receipts and control integrity without simply becoming another worker carrying out the action under review.

The architecture separates doing the work from deciding whether its claims are supported. An operational system may report that an action was authorised and completed; review examines the applicable authority, the evidence of execution, inconsistencies and the limits of what can be concluded.

Independent review requires more than a reassuring second answer. The review role needs an appropriate evidence basis and separation from the operational decision it is assessing. A finding may identify an unresolved contradiction, require further investigation or recommend correction or containment through the applicable governance process.

AUDI's independence describes its intended functional separation within the company's governance architecture. It does not mean external third-party certification or statutory audit. Human oversight, enforceable controls and recovery responsibilities remain distinct. The depth of review and the controls available must be proportionate to the consequence and supported by the actual release.

Charter connections

Article XIII · Governance, audit and correction Article V · The right to understand Article IV · Independent safeguard

Make claims examinable and errors correctable, with scrutiny separated from ordinary operational work.

Current development position

AUDI is the current PIA Auditor governance identity. This is not a claim of external audit certification, perfect detection or autonomous enforcement in every product.

Safety architecture

Two names for exceptional situations

These terms describe different parts of the safety architecture: a coordinated response to a serious incident, and a protected-action hold when authority or control cannot be trusted.

Houston / Mission Control

“Houston, we've got a problem.”

Incident-response design; release-specific

Houston is the customer's signal that something may be seriously wrong: suspected compromise, unusual financial activity or a major operational problem. Mission Control is the coordinated response procedure, designed to stabilise the affected area, hold new consequential actions where necessary, preserve evidence and guide verified recovery while keeping the person informed.

Incident reported → Stabilise + preserve → Coordinated recovery → Verify before release — Conceptual incident-response procedure; actual containment depends on supported controls.

Explore the responsibilities

A serious incident may justify a broader emergency hold if a narrower boundary cannot be shown safe. Where possible, unaffected services remain available. The response can only enforce controls that the product and connected providers actually support.

In practice

A business owner notices suspicious account activity and asks for help. The response establishes what can be verified, contains supported action paths and coordinates the next authorised steps.

Current development position

This is a documented incident-response design. Availability and the actions it can hold depend on the product and its connected services.

FrankenPia

Pause the changes. Preserve what is safe.

Protected-action hold design; release-specific

FrankenPia is the name for a scoped protected-action hold when there is evidence of suspicious authority, possible compromise or a serious control failure. The design pauses affected publishing, payment, deletion or other consequential changes while demonstrably safe functions and the unaffected website can remain available.

Questionable authority → Affected changes held → Safe service continues → Verified recovery — Conceptual scoped hold. Safe service continues only where isolation can be demonstrated.

Explore the responsibilities

An unlocked phone or familiar chat does not, by itself, prove authority for destructive changes. New instructions should be checked against the authorised scope and consequence. A hold is released through verified recovery and the required human authority; a reassurance from the same suspect session is not enough.

In practice

An unattended device begins sending unexpected instructions to alter a business website. The intended safeguard holds the affected changes while authority is checked, instead of taking a healthy public site offline by default.

Current development position

This is documented containment architecture. Availability, detection and enforcement depend on the product implementation.

Charter connections: Article IV, Article V, Article X, Article XIII.

Principles become credible when they shape the work.

The Charter provides the standard. Architecture defines the responsibilities and boundaries. Testing, review and release evidence establish what each product can currently deliver.

Some implementation details are commercially confidential. This overview explains system responsibilities, architectural principles and development status without publishing proprietary implementation methods or sensitive security details.

Explore the products Read the Charter