Every service, registered and owned

Companion runs nine intelligence services between a raw observation and a delivered interpretation. Each is registered with its purpose, inputs, outputs, the controls that constrain it, its failure modes, the evidence it produces, and a named accountable owner. No service operates unregistered.

Can a signal be challenged?

Yes. Any party with standing — an insurer, a regulator, a pet owner — can contest a signal or interpretation. Source Governance is the procedure that answers the challenge with evidence, not assertion. The signal is replayed, decomposed to its observations, and traced to the partner source that produced each one.

Run the challenge below. Each step resolves against the same append-only record the platform reasons over — nothing is reconstructed for the occasion.

{{ f.body }}

Who owns the data?

The contributor retains ownership. Companion provides continuity, interpretation, and exchange. Ownership is never transferred — Companion holds a scoped, contractual right to use, and stewards the continuity built from what is contributed.

Ownership and stewardship are different things. The model below separates them explicitly, and the explorer lets you descend any observation to the rights that govern it.

A governance lifecycle, not a pipeline

Every stage a datum passes through answers three governance questions: who owns it, who may access it, and what control applies. Ownership is constant across all seven stages — only stewardship and access change.

Six domains, each owned

Security is organised as six governed domains, not a list of features. Each carries a purpose, the controls that implement it, the evidence it produces, and a named accountable owner — the same structure as every other section of this platform.

Held where it is required to be held

Privacy and residency are conditions of operating, not features. Each area below states the current posture and the future-state direction explicitly — Companion does not claim what is not yet implemented.

Where does Companion run?

The cloud provider is an implementation choice. The trust story is that Companion can be operated, governed, and audited at institutional scale regardless of where it is deployed. The platform runs to one architectural contract across every environment.

Select a deployment to inspect its purpose, components, data flow, controls, evidence, and accountable owner — the same interrogability as every other surface.

{{ d.cloud }}

{{ d.name }}

{{ d.tagline }}

{{ depCur.cloud }} · Inspection

{{ depCur.name }}

{{ depCur.purpose }}

Data flow · ingress → egress

{{ f.stage }}

{{ f.svc }}

→

Components

{{ c }}

Controls

{{ c }}

⊙ Evidence

⊙ Owner · {{ depCur.ownerName }}

How much can the platform support?

Engineering, not marketing. Each dimension states what the platform handles today, what has been validated under test, and the architectural ceiling the design targets. The architecture scales horizontally; the envelope describes headroom, not promises.

What happens when things go wrong?

Reliability is not a single availability number. It is how the platform behaves under failure — how incidents are managed, how the exchange recovers, how continuity is preserved, and how change is governed. Six domains, each with a purpose, the controls that implement it, the evidence it produces, and a named owner.

Stated honestly: current and planned

Companion does not claim certifications it does not hold. Each area below states what is enforced in production today and what is planned — nothing more. This conservatism is itself a trust signal.

The risks we acknowledge

Mature platforms state their risks publicly. Each risk below carries a likelihood, an impact, the control that mitigates it, and a named owner — and every mitigation and owner is interrogable, just like the rest of the platform.

The questions people actually ask

Grouped by who is asking. Every answer resolves to something demonstrable elsewhere in this platform — not a reassurance, a reference.