Skip to main content

Platform Foundations

The core entities in TradeOS and how they relate.

C
Written by Catalin Fetean
Updated over 3 weeks ago

Audience: Everyone
Outcomes: Shared mental model; correct isolation; least-privilege access

Glossary (core entities)

  • Organization (Org) — tenant boundary; owns users, settings, contracts, orders, invoices, disputes, scores.

  • User — belongs to exactly one org at a time; has a role and KYC status.

  • Partner link — approved trust relationship between two orgs; required for cross-org contracts.

  • Contract — structured agreement; lifecycle: draft → review → approve/reject → sign → active.

  • Order — execution unit under a contract; contains milestones & deliverables.

  • Milestone — scope + acceptance criteria + (optional) escrow release amount.

  • Deliverable — uploaded artifact(s) attached to an order/milestone.

  • Payment — card/bank/crypto transaction recorded against an order.

  • Escrow — custodial account or smart contract releasing funds by milestone.

  • Dispute — formal conflict tied to an order; resolved by admin decision.

  • Invoice — document of record for charges/refunds.

  • Reputation — per-org score derived from delivery, disputes, refunds.

Relationships (canonical diagram)

flowchart LR OrgA[Organization A] -- partner link --> OrgB[Organization B] OrgA --- UsersA[Users] OrgB --- UsersB[Users] OrgA <---> Contract OrgB <---> Contract Contract --> Order Order --> Milestone --> Escrow Order --> Deliverable Order --> Payment --> Webhooks[(Provider Webhooks)] Order --> Dispute --> Reputation Order --> Invoice

Tenancy & data boundaries

  • Every request executes in a single-org context (the org in your session).

  • Cross-org operations require an active partner link and explicit consent flows.

  • Reports/exports never cross org boundaries unless both parties allow it.

  • Switching orgs

    • UI: Profile → Switch organization

    • API: log in to the desired org; the session cookie scopes calls.

  • Data residency: Org metadata includes region (for storage/invoices). Plan-based options available.

  • Edge cases:

    • A user in multiple orgs must switch contexts; there’s no “global” view.

    • Attempting cross-org without a partner link returns 403.

Roles & permissions (RBAC)

  • Owner — billing & policies; full access.

  • Admin — manage users, partner links, KYC, disputes; create/approve contracts.

  • Member — day-to-day execution: drafts, orders, deliverables.

Server guardrail

function requireRole(...roles: Array<'owner'|'admin'|'member'>) { return (req, res, next) => { if (!req.user) return res.status(401).json({ message: 'Auth required' }); if (!roles.includes(req.user.role)) return res.status(403).json({ message: 'Insufficient role' }); next(); }; }

Identifiers & references

  • Internal IDs: org_123, usr_42, ct_987, ord_456, inv_1122.

  • Always add a business-meaningful reference for idempotency & reconciliation.

Anti-patterns

  • Using emails as persistent IDs.

  • Storing PII in free-text fields (use structured fields).

QA checklist

  • Cross-org call without partner link ⇒ 403.

  • Member cannot access admin-only endpoints ⇒ 403.

  • Switching org changes visible contracts/orders accordingly.


Did this answer your question?