Repository topology
Status: Accepted · Version: 0.1
Organisation pattern: titip-labs/. Names below are repository names. This repository is control-plane (local checkout may be named titip-control-plane).
First wave
Create and develop these. Do not wait for the full tree.
| Repository | Description |
|---|---|
control-plane |
Titip’s product and engineering authority plane: specifications, architecture decisions, domain contracts, security rules, release gates, and delivery plans. Not the main runtime. |
app |
Titip mobile application for creating trusted contacts, asset inventories, life-check settings, messages, and controlled legacy instructions. No backend domain logic. |
web |
Public website and secure web experiences for onboarding, trusted-contact verification, recipient claims, and product education. Not only a marketing site. |
backend |
Core application API and domain orchestration for users, vaults, policies, trusted contacts, and controlled release workflows. Modular monolith. |
ai |
Privacy-preserving assistance for asset discovery, checklists, and instruction drafting. Not a release decider. Stage 5. |
infrastructure |
Infrastructure as code, environments, deployment, secrets integration, networking, data stores, encryption services. Prototype: app, backend, Postgres, object storage, email, KMS, basic telemetry. Not a full production estate. |
knowledge |
Curated guidance, templates, safety rules, and jurisdiction-aware education. Not a RAG dump. Not legal advice. |
Backend modules in the first wave
auth, users, contacts, vaults, assets, policies, lifecheck, escalation, releases, notifications, audit, admin.
life-check, vault, delivery (releases), notifications, and trusted-contact behaviour stay here until a boundary is real.
Later repositories
Do not create these until the domain is stable and a boundary is justified.
| Repository | Why it would exist |
|---|---|
identity |
If authentication and verification need an isolated trust boundary |
vault |
Secure storage and access control for encrypted guidance and recipient-scoped packages |
life-check |
Presence engine extracted from the monolith |
delivery |
Recipient-scoped release engine extracted from releases |
contacts |
If contact verification volume or policy needs its own service |
notifications |
Multi-channel sending extracted behind the same NotificationRequest abstraction |
observability |
Dashboards and detection on top of the audit contract. Does not replace audit |
security |
Threat-model artefacts, abuse cases, privacy reviews, penetration-test evidence |
integrations |
Provider adapters: SMS, WhatsApp, email, identity proofing, signing, partners |
docs |
Public developer documentation, if control-plane documents are no longer the right public surface |
Dependency rule
Runtime repositories depend on contracts in this repository. This repository does not depend on runtime repositories. If implementation discovers a missing rule, the change lands here before the behaviour ships.