# Themelio compatibility and parallel operation

The retained application lives under `compat/themelio` and runs as
`themelio-compat`. The new service scaffold lives under `services/themelio`.
Both can appear in the same environment. Their deployment names and responsibilities
must remain explicit in operational instructions.

## Documentation links

The retained web footer and sidebar open the current documentation through `/documentation`.
The server resolves its destination from the configured `THEMELIO_URL` at request
time: local development uses `https://docs.localtest.me/`, and staging uses
`https://docs.staging.pharosfactory.ai/`. The Contribute link opens `/contributing/`
on the same documentation host.

Set the runtime `THEMELIO_DOCUMENTATION_URL` to an HTTP(S) base URL for other
installations or to override these defaults. A base path is supported. An
unrecognised environment without an explicit URL returns an unavailable response.
These links use runtime configuration and require no environment-specific image build.

## Shared infrastructure and separate authority

The applications can share AAI, GitLab and Waldur. Each operation needs one active
writer and an explicit handover when ownership changes. Their databases and runtime
credentials follow their own documented boundaries. Read the
[compatibility decision](../../decisions/0043-themelio-compat-service.md), its
[implementation guide](../../dd/0043-themelio-compat-service.md) and the
[current architecture](../../../ARCHITECTURE.md) together.

| Capability | Current documentation owner | Qualification to check |
| --- | --- | --- |
| Retained Themelio web and actors | Compatibility implementation guide | Enabled routes, provider credentials and environment restrictions |
| Canonical Party authentication | Beto Party Governance | Enrolled authentication edge, verified bindings and real AAI qualification |
| Source-managed Project and membership | Beto Project | Source enrolment, freshness, access checks and published contract version |
| New Themelio service | Service scaffold | Explicit context registration before claiming a business capability |
| Workload execution | Owning Metallo context | Connected owner ports, paused processes and native runtime qualification |

The [Party](../../../services/beto/contexts/party_governance/README.md) and
[Project](../../../services/beto/contexts/project/README.md) READMEs distinguish the
current slices from their planned evolution. This table identifies where to look;
an environment's rollout and tests establish what is running.

## Retained documentation

The original pages retain their routes and Git history. Each carries a compatibility
notice. Their historical requirements, examples and deployment assumptions need
review before use in a new platform feature.

- [Product introduction](../product/introduction/index.md)
- [Architecture and flows](../product/architecture/overview.md)
- [Operations](../product/operations/index.md)
- [Historical ADRs](../adr/index.md) and [design documents](../dd/index.md)
- [Glossary](../glossary.md)

The [current decision catalogue](../../decisions/README.md) remains the authority
for platform decisions. Historical copies preserve the original record; their
presence does not accept an old proposal for the new architecture.

## Handover checklist

For each capability, record its current writer, replacement owner, transferred
state and identifier bindings, enrolment conditions, recovery behaviour and tested
cutover/rollback procedure. Qualify the replacement with its real providers before
enabling writes. Update the owning context and operational guide at the same time.