Wrati Trust Framework & Safety Architecture

01Executive Summary

Wrati is a relationship platform built in India for people of every age. This document describes the architecture behind it: how identity is verified, how content is screened, how moderation decisions are made and reviewed, and how privacy and security are designed into the product rather than added to it.

It is a description of engineering, not a compliance certification. Where a capability is planned rather than built, this document says so.

02The Trust Problem

Matching two people is a solved problem. Establishing whether either is who they claim to be is not. Platforms where strangers meet face fake profiles, identity fraud, spam, harassment and harmful content — and each is a trust problem before it is a technology problem.

Trust is also asymmetric. The cost of a bad interaction falls overwhelmingly on the person who was targeted, which means a platform cannot treat safety as a support function measured after the fact.

03Platform Architecture

Wrati runs a TypeScript application layer over PostgreSQL, with PostGIS for geospatial discovery and pgvector for semantic similarity held alongside the relational data. Real-time messaging, presence and call signalling run over Socket.IO; peer-to-peer audio and video use WebRTC. A separate Python service handles machine-learning workloads, keeping model execution off the request path.

Background work — reconciliation, scheduled communications — runs through a job queue rather than inside HTTP requests, so slow or failing external systems cannot degrade the product surface.

04Verification

Members can verify that they are the person shown in their photographs. Verification produces a signal on the profile and nothing more: it confirms a likeness, not an identity document, and not a person's intentions. The document is explicit about this because an overstated verification badge is itself a safety risk — it invites people to lower their guard.

05AI Safety

Images and message text are screened automatically before delivery. Screening covers explicit imagery, text extracted from images, and content rules including attempts to move people off-platform. Repeat and recycled imagery is detected through perceptual similarity.

Every one of these systems produces false positives and false negatives. They are filters that reduce harm at volume, not adjudicators — which is why the moderation process below exists.

06Moderation

The moderation process uses deliberately neutral vocabulary, because the language a platform uses becomes the language of an accusation.

• — Report — a member submits a safety report
• — Allegation — recorded as an account of what someone experienced; nothing is established
• — Safety Review — assessed against policy, with any evidence submitted
• — Moderation Decision — no action, content removal, warning, restriction or suspension
• — Appeal — a decision can be contested (self-service appeals are planned; grievance contacts reach a person today)

07Behavioural Trust Signals

Wrati derives trust signals from platform behaviour to help surface risk earlier. These are privacy-conscious by design: they inform internal review and product safeguards.

Wrati does not operate a public accusation feed. Members cannot post allegations about one another for others to read. An uncontrolled accusation system is the fastest route from a safety feature to a harassment tool, and it falls hardest on people least able to defend themselves.

08Privacy by Design

Privacy controls are granular and belong to the member: who may message them, whether read receipts and typing indicators are shared, whether online status is visible, and whether their messages may be forwarded.

Consent is separated by purpose. Agreeing to service communications does not grant marketing consent, connecting a social account does not grant permission to publish from it, and withdrawing marketing consent never suppresses payment receipts or security notices.

09Security

Transport is encrypted; passwords are stored only as salted hashes; verification codes are hashed, expiring and single-use. Authorisation for paid features and privileged actions is enforced server-side, so a modified client, a direct API call or a forged real-time event is refused the same way.

Media shared in conversations is not publicly addressable. Access requires a signed link that expires, is bound to the person it was issued to, and cannot be edited to reach a different file. Payment outcomes are never accepted from the browser: provider callbacks are signature-verified and processed exactly once.

10Human Oversight and Appeals

Automated systems flag and filter; they do not have the final word on enforcement against an account. Reports and safety events are reviewed by people through internal tooling.

A self-service appeals flow is not yet built. Until it is, the published grievance route reaches a named officer. Stating this plainly matters more than appearing complete — someone contesting a decision needs to know where to go.

11Data Governance

Personal data is held across account, profile, location, communication, payment, safety and device categories, each with a defined purpose. Deleted accounts are retained for a limited window and then permanently purged along with associated records.

Specific retention periods are pending legal assessment and are deliberately not stated in this document rather than estimated.

12Privacy Principles — India and Europe

Wrati's architecture is designed to support applicable Indian data-protection and digital-safety requirements, including a published Grievance Officer, in-product reporting, human review, consent records and account deletion. Applicability subject to legal assessment.

Wrati is developing its European privacy architecture with GDPR principles in mind. Wrati does not claim GDPR compliance or certification. There is no EU-region hosting, no appointed EU representative and no Data Protection Officer at present; EU infrastructure and regional data residency are roadmap items.

13Technology Roadmap

Planned work includes dedicated object storage with a CDN, multi-region deployment including EU-region hosting, regional data residency, a self-service data export, and a formal appeals flow.

The verification, moderation and trust-signal capabilities Wrati has built are internal today. Offering them as external APIs is a direction under exploration, not a commercial product: Wrati has no external API customers.