ADR-047: CODITECT-PLATFORM Foundation Architecture Discovery

Executive Summary

This document captures the architectural discovery process for CODITECT-PLATFORM, a scalable enterprise foundation designed to support:

Individual users to multi-subsidiary enterprises
White-label platform deployment
Multi-country/jurisdiction compliance
Integrated accounting and subscription management
Future evolution into FUTUREPRISE product family

Interview Status: ✅ COMPLETE Questions Answered: 46 / 46 Last Updated: 2026-01-01T12:30:00Z

Organization Structure
User & Access Management
Multi-Tenant Architecture
Billing & Subscriptions
Accounting Foundation
Data Isolation & Compliance
White-Label & Branding
Integration & APIs
Reporting & Analytics
Platform Operations

How to Use This Document

For Discovery Sessions

Work through questions sequentially or by domain
Record responses in the Response field
Add notes in the Rationale field for context

For Future Customer Onboarding

Questions marked with 🔧 can be configured per-customer
Questions marked with 🏗️ affect platform architecture
Questions marked with 💰 impact billing/pricing

1. Organization Structure

Q1.1 🏗️ Organization Types Supported

Question: What types of organizations will CODITECT-PLATFORM serve?

Option	Description
A	Individual - Solopreneurs, freelancers, single-user accounts
B	Team - Small groups (2-20 users), single department
C	Company - Mid-size business (20-500 employees), single entity
D	Enterprise - Large organization (500+ employees), single legal entity
E	Multi-Subsidiary - Corporate group with multiple legal entities
F	White-Label Partner - B2B customers deploying platform for their customers
G	All of the above - Full spectrum support

Response: [G] All of the above

Rationale:

Full spectrum support required: Individual → Team → Company → Enterprise →
Multi-Subsidiary → White-Label Partner. This is foundational to FUTUREPRISE
vision and Oracle NetSuite-inspired scalability. Platform must handle single
users up to complex corporate hierarchies with white-label deployment capability.

Q1.2 🏗️ Entity Hierarchy Depth

Question: How many levels of organizational hierarchy are needed?

Option	Hierarchy
A	2-level: Tenant → User
B	3-level: Organization → Team → User
C	4-level: Organization → Department → Team → User
D	5-level: Platform → Organization → LegalEntity → OperatingUnit → Team → User
E	6-level: Platform → Organization → LegalEntity → OperatingUnit → Department → Team → User

Response: [E] 6-level hierarchy

Rationale:

Maximum flexibility required for enterprise multi-subsidiary support. The 6-level
hierarchy mirrors Oracle NetSuite's organizational model:
- Platform: White-label instance (CODITECT-PLATFORM or partner-branded)
- Organization: Top-level subscriber/customer account
- LegalEntity: Subsidiary with tax ID, jurisdiction, fiscal calendar
- OperatingUnit: Division or business unit with P&L responsibility
- Department: Cost center for expense allocation
- Team: Collaborative work group
- User: Individual with role-based access at each level

Q1.3 🏗️ Legal Entity Requirements

Question: What legal entity attributes must be tracked?

Option	Attributes
A	Name, Tax ID only
B	A + Country, Currency, Timezone
C	B + Address, Jurisdiction, Regulatory Status
D	C + Fiscal Year, Reporting Calendar, Intercompany Settings
E	D + Transfer Pricing Rules, Consolidation Hierarchy

Response: [E] Full legal entity attributes

Rationale:

Complete legal entity tracking required for multi-national enterprise support:
- Name, Tax ID: Basic identification
- Country, Currency, Timezone: Localization
- Address, Jurisdiction, Regulatory Status: Compliance
- Fiscal Year, Reporting Calendar: Financial period management
- Intercompany Settings: Cross-entity transaction rules
- Transfer Pricing Rules: Arm's length pricing for tax compliance
- Consolidation Hierarchy: Parent-child for financial consolidation

This enables ASC 606 compliance, multi-GAAP reporting, and proper intercompany
elimination during financial close.

Q1.4 🔧 Subsidiary Relationships

Question: How should subsidiaries relate to parent organizations?

Option	Description
A	Flat - All entities equal, no parent-child
B	Single Parent - One parent, multiple children (no grandchildren)
C	Nested Hierarchy - Unlimited depth parent-child
D	Matrix - Entities can have multiple parents

Response: [D] Matrix relationships

Rationale:

Matrix relationships support complex corporate structures:
- Joint ventures with shared ownership
- Shared service centers serving multiple entities
- Complex holding structures with cross-ownership
- Regional allocation of shared resources

Implementation: Many-to-many relationship table (EntityRelationship) with
relationship_type (parent, owner, service_provider, etc.) and ownership_percentage.
More complex than simple parent_id FK but enables real-world corporate structures.

Q1.5 🔧 Cross-Entity Visibility

Question: Can users see data across multiple legal entities?

Option	Description
A	Isolated - Users see only their assigned entity
B	Consolidated View - Read-only view of related entities
C	Intercompany Operations - Can create transactions across entities
D	Full Access - Complete access based on role only

Response: [D] Full access based on role and granular permissions

Rationale:

Role-based access with granular permission controls across ALL domains:
- Accounting: GL, AP, AR, intercompany transactions
- Projects: View, edit, manage based on team/entity assignment
- Resources: Workstations, repositories, compute allocation
- Administration: User management, configuration, billing

Key requirement: Permissions are NOT siloed by domain. A unified RBAC system
must control access across financial, operational, and technical resources.
This enables scenarios like:
- CFO sees consolidated financials but not code repositories
- Developer accesses projects across entities but not AP/AR
- Project Manager views costs across assigned projects only

Implementation: Permission scoping at Entity, OperatingUnit, Department, Team,
and Resource levels with inheritance and override capability.

2. User & Access Management

Q2.1 🏗️ Authentication Methods

Question: Which authentication methods must be supported?

Option	Methods
A	Email/Password only
B	A + OAuth (Google, GitHub, Microsoft)
C	B + SAML 2.0 SSO
D	C + OIDC, LDAP/AD
E	D + Hardware tokens, Passwordless (WebAuthn)

Response: [E] Full authentication stack

Rationale:

Enterprise-grade authentication supporting all scenarios:
- Email/Password: Default for individuals, small teams
- OAuth (Google, GitHub, Microsoft): Developer-friendly SSO
- SAML 2.0: Enterprise SSO (Okta, Azure AD, OneLogin)
- OIDC: Modern enterprise identity providers
- LDAP/AD: On-premise Active Directory integration
- Hardware tokens: YubiKey, security keys for high-security
- WebAuthn/Passkeys: Passwordless future-proofing

Implementation priority: Email/Password + OAuth first, then SAML/OIDC for
enterprise tier, hardware/WebAuthn as premium security add-on.

Q2.2 🏗️ Role Hierarchy - System Level

Question: What system-level (platform admin) roles are needed?

Role	Permissions
A	super_admin - Full platform access, can impersonate any user
B	platform_admin - Manage tenants, cannot access tenant data
C	support - View tenant data for troubleshooting
D	sales - View subscriptions, billing, create trials
E	finance - View revenue, invoices, payments
F	readonly - View platform metrics only

Selected Roles: [A, B, C, D, E, F] All system roles

Rationale:

All system-level roles required with ADAPTIVE PERMISSION CONFIGURATION:

1. ROLE TEMPLATES BY ORGANIZATION TYPE:
   - Individual/Team: Pre-configured broad permissions (owner does everything)
   - Company: Department-based templates (finance, engineering, ops)
   - Enterprise: Granular role builder with inheritance

2. UI REQUIREMENTS:
   - Click-configurable dropdowns (not JSON/code)
   - Permission matrix view (role × resource × action)
   - Visual inheritance tree showing effective permissions
   - "Copy from template" and "Copy from role" functions

3. EVOLUTION SUPPORT:
   - Start simple → add granularity as org grows
   - Permission audit trail (who changed what, when)
   - Role comparison tool (diff two roles)
   - Bulk permission updates across roles

4. PRE-CONFIGURED TEMPLATES:
   - Solopreneur: Single "owner" role with full access
   - Startup: Owner, Admin, Developer, Viewer
   - SMB: Add Finance, HR, Project Manager
   - Enterprise: Full role builder with custom permissions

Implementation: RoleTemplate model + Permission model with scope + easy-config UI.

Q2.3 🏗️ Role Hierarchy - Tenant Level

Question: What tenant-level roles are needed?

Role	Permissions
A	owner - Full tenant control including billing, can delete tenant
B	admin - Manage users, teams, projects (no billing)
C	manager - Manage assigned teams/projects only
D	member - Standard user access
E	viewer - Read-only access
F	guest - External collaborator with limited access
G	custom - Configurable per-tenant roles

Selected Roles: [G] Custom configurable roles (includes A-F as templates)

Rationale:

Fully customizable tenant-level roles with predefined templates:

PREDEFINED TEMPLATES (starting points):
- owner: Full control + billing + delete
- admin: User/team/project management (no billing)
- manager: Scoped to assigned teams/projects
- member: Standard operational access
- viewer: Read-only
- guest: External collaborator (time-limited, specific resources)

CUSTOM ROLE CAPABILITIES:
- Clone from template and modify
- Build from scratch with permission picker
- Scope to entity/department/team/project levels
- Set time-based expiry (contractor roles)
- Define approval workflows (who can assign this role)

ROLE GOVERNANCE:
- Role lifecycle (draft → active → deprecated)
- Maximum permissions cap (can't exceed creator's permissions)
- Conflicting permission detection
- Role usage analytics (how many users, last assigned)

Aligns with Q2.2 adaptive permission configuration philosophy.

Q2.4 🏗️ Permission Granularity

Question: How granular should permissions be?

Option	Description
A	Role-based only - Permissions tied to role, no customization
B	Role + Feature flags - Roles plus toggleable features
C	RBAC - Roles with permission sets
D	ABAC - Attribute-based (user attributes + resource attributes)
E	PBAC - Policy-based with rules engine

Response: [E] Policy-based access control (PBAC)

Rationale:

Full policy-based access control with rules engine for maximum flexibility:

POLICY STRUCTURE:
- Subject: Who (user, role, group, service account)
- Resource: What (entity, project, document, API endpoint)
- Action: How (create, read, update, delete, approve, execute)
- Conditions: When/Where (time, location, amount, status, attributes)
- Effect: Allow or Deny

EXAMPLE POLICIES:
1. "Finance Managers can approve invoices up to $10,000 in their legal entity"
2. "Developers can deploy to staging anytime, production only during change windows"
3. "External auditors can view GL entries but not download attachments"
4. "Project leads can add team members if project budget allows"

IMPLEMENTATION APPROACH:
- Policy definition language (JSON/YAML or visual builder)
- Policy evaluation engine (Open Policy Agent or custom)
- Policy simulation ("what if" testing before activation)
- Policy versioning and rollback
- Conflict resolution (explicit deny wins, most specific wins)

PERFORMANCE CONSIDERATIONS:
- Policy caching per user session
- Pre-computed effective permissions for common paths
- Async policy evaluation for non-critical paths

Builds on RBAC foundation but adds conditional logic for enterprise scenarios.

Q2.5 🔧 Permission Scope

Question: What scopes should permissions support?

Scope	Description
A	Global - Applies to entire tenant
B	Entity - Scoped to legal entity
C	Team - Scoped to team
D	Project - Scoped to project
E	Resource - Scoped to specific resources
F	All of the above

Response: [F] All scopes supported

Rationale:

Full scope hierarchy for permission resolution:

SCOPE HIERARCHY (most specific wins):
1. Resource → specific document, repo, workstation
2. Project → project-level permissions
3. Team → team-wide permissions
4. Department → department-wide (from Q1.2)
5. OperatingUnit → business unit level
6. Entity → legal entity level
7. Organization → organization-wide
8. Global → tenant-wide default

INHERITANCE MODEL:
- Permissions inherit DOWN the hierarchy
- More specific scope OVERRIDES parent scope
- Explicit DENY at any level blocks access

EXAMPLE:
- Global: "members can view projects"
- Entity: "members in US-Sub can edit projects"
- Team: "DevOps team members can delete projects"
- Resource: "Only @john can access secret-config.yaml"

IMPLEMENTATION:
- Scope stored as hierarchical path: org/entity/dept/team/project/resource
- Query: Find all policies matching any prefix of resource path
- Cache: Pre-compute effective permissions per user per scope level

Q2.6 🔧 User Lifecycle Management

Question: What user lifecycle features are needed?

Feature	Description
A	Invitation System - Email invites with expiry
B	Provisioning - SCIM auto-provisioning
C	Deprovisioning - Auto-disable on termination
D	Access Reviews - Periodic certification
E	Delegation - Temporary access grants
F	All of the above

Response: [F] Full user lifecycle management

Rationale:

Complete user lifecycle automation for enterprise compliance:

1. INVITATION SYSTEM:
   - Email/link invites with configurable expiry (24h, 7d, 30d)
   - Bulk invite via CSV upload
   - Invite approval workflow (manager must approve)
   - Re-invite and reminder automation

2. SCIM PROVISIONING:
   - SCIM 2.0 endpoint for IdP integration
   - Auto-create users from Okta, Azure AD, OneLogin
   - Attribute mapping (department → team, title → role)
   - Group sync (IdP groups → platform teams)

3. DEPROVISIONING:
   - Real-time disable on IdP termination signal
   - Grace period option (24h for data handoff)
   - Ownership transfer workflow (reassign projects, docs)
   - Audit trail of deprovisioned access

4. ACCESS REVIEWS:
   - Scheduled certification campaigns (quarterly, annual)
   - Manager certifies direct reports' access
   - Risk-based reviews (privileged access more frequent)
   - Auto-revoke if not certified within window

5. DELEGATION:
   - Temporary access grants with auto-expiry
   - Vacation/leave coverage assignments
   - Approval workflow for sensitive delegations
   - Delegation audit trail

Supports SOC 2, ISO 27001, and SOX compliance requirements.

3. Multi-Tenant Architecture

Q3.1 🏗️ Data Isolation Model

Question: What level of data isolation is required?

Option	Description
A	Shared Database, Shared Schema - Tenant ID column filter
B	Shared Database, Separate Schema - Per-tenant PostgreSQL schema
C	Separate Database - Dedicated database per tenant
D	Separate Cluster - Dedicated infrastructure per tenant
E	Hybrid - Shared for small, dedicated for enterprise

Response: [E] Hybrid isolation model

Rationale:

Tiered data isolation matching organization complexity and compliance needs:

TIER 1 - SHARED (Individual, Team, Startup):
- Shared database, shared schema
- Tenant ID column on all tables
- Row-level security (RLS) policies
- Cost-effective, fast provisioning
- Suitable for: Trial, Starter, Professional tiers

TIER 2 - SCHEMA ISOLATION (Company, SMB):
- Shared database, separate PostgreSQL schema
- Schema-per-tenant for data segregation
- Shared infrastructure, logical isolation
- Suitable for: Business tier with compliance needs

TIER 3 - DATABASE ISOLATION (Enterprise):
- Dedicated database per tenant
- Can be same cluster or dedicated instance
- Full backup/restore independence
- Suitable for: Enterprise tier, regulated industries

TIER 4 - INFRASTRUCTURE ISOLATION (White-Label, Government):
- Dedicated cluster/VPC
- Customer-managed keys (BYOK)
- Region-specific deployment
- Suitable for: White-label partners, FedRAMP, healthcare

MIGRATION PATH:
- Start at Tier 1, migrate up as customer grows
- Zero-downtime migration tooling required
- Data export/import automation
- DNS/routing updates for dedicated instances

Q3.2 🏗️ Tenant Identification

Question: How should tenants be identified in requests?

Option	Description
A	JWT Claim - Tenant ID in authentication token
B	Subdomain - tenant.coditect.ai
C	Custom Domain - tenant's own domain
D	Header - X-Tenant-ID header
E	Path - /tenant/{tenant_id}/...
F	Multiple - Support A + B + C

Response: [F] Multiple identification methods

Rationale:

Flexible tenant identification supporting all deployment scenarios:

1. JWT CLAIM (Primary - Always Present):
   - tenant_id embedded in access token
   - Validated on every authenticated request
   - Works regardless of domain/subdomain
   - Required for API access

2. SUBDOMAIN (Standard SaaS):
   - acme.coditect.ai, startup.coditect.ai
   - Auto-provisioned on tenant creation
   - SSL via wildcard cert (*.coditect.ai)
   - Tenant lookup: subdomain → tenant_id

3. CUSTOM DOMAIN (Enterprise/White-Label):
   - app.acme.com, platform.partner.io
   - Customer provides domain, we provide CNAME
   - SSL via Let's Encrypt or customer cert
   - Domain mapping table: domain → tenant_id

RESOLUTION ORDER:
1. Check JWT claim (authenticated requests)
2. Check custom domain mapping
3. Check subdomain pattern
4. Fallback to default/login page

WHITE-LABEL SUPPORT:
- Partner's customers never see "coditect" branding
- Full custom domain: app.partnerbrand.com
- Partner manages their tenant's subdomains

SECURITY:
- Tenant ID in JWT is authoritative
- Domain/subdomain only for initial routing
- Cross-tenant requests blocked at middleware

Q3.3 🔧 Tenant Customization

Question: What can tenants customize?

Feature	Description
A	Branding - Logo, colors, email templates
B	Domain - Custom domain mapping
C	Features - Enable/disable platform features
D	Workflows - Custom approval workflows
E	Fields - Custom fields on entities
F	Integrations - Tenant-specific integrations
G	All of the above

Response: [G] Full tenant customization

Rationale:

Complete tenant customization for white-label and enterprise flexibility:

1. BRANDING:
   - Logo (header, favicon, email)
   - Color palette (primary, secondary, accent)
   - Typography (font family, sizes)
   - Email templates (welcome, invite, notifications)
   - Login page customization
   - Custom CSS injection (enterprise)

2. DOMAIN:
   - Custom domain mapping (app.customer.com)
   - Subdomain allocation (customer.coditect.ai)
   - SSL certificate management
   - DNS verification workflow

3. FEATURES:
   - Feature flags per tenant
   - Module enable/disable (workstations, repos, commerce)
   - Tier-based feature gating
   - Beta feature opt-in

4. WORKFLOWS:
   - Approval chains (sequential, parallel)
   - Escalation rules
   - SLA timers
   - Notification preferences
   - Custom workflow builder (enterprise)

5. CUSTOM FIELDS:
   - Add fields to: User, Project, Team, Entity
   - Field types: text, number, date, dropdown, multi-select
   - Required/optional, validation rules
   - Searchable/filterable flags

6. INTEGRATIONS:
   - OAuth app connections per tenant
   - Webhook endpoints
   - API key management
   - Integration marketplace (future)

Stored in TenantConfig model with JSON schema validation.

Q3.4 🏗️ Cross-Tenant Operations

Question: Are cross-tenant operations needed?

Option	Description
A	None - Complete tenant isolation
B	Marketplace - Shared content/templates between tenants
C	Partner Network - B2B connections between tenants
D	Consolidation - Parent tenant views child tenant data
E	B + C + D

Response: [E] Full cross-tenant capabilities

Rationale:

All cross-tenant operations for ecosystem and white-label support:

1. MARKETPLACE:
   - Shared templates (project templates, workflow templates)
   - Shared integrations (community connectors)
   - Shared skills/agents (CODITECT AI marketplace)
   - Publisher/subscriber model
   - Pricing: Free, paid, subscription
   - Review/rating system

2. PARTNER NETWORK:
   - B2B tenant connections (client ↔ vendor)
   - Shared projects across tenants
   - Guest access invitations
   - Data sharing agreements (contractual)
   - API-level integration between tenants
   - Use case: Agency manages multiple client tenants

3. CONSOLIDATION (White-Label):
   - Parent tenant (partner) views child tenants (customers)
   - Aggregated reporting across child tenants
   - Bulk operations (feature rollout, pricing updates)
   - Revenue share tracking
   - Support escalation path
   - Child tenant cannot see parent or siblings

SECURITY MODEL:
- Cross-tenant access requires explicit agreement
- Audit trail for all cross-tenant data access
- Data flows are unidirectional where appropriate
- Revocable connections with cleanup

IMPLEMENTATION:
- TenantRelationship model (parent, partner, marketplace_publisher)
- CrossTenantPermission model (what can be shared)
- SharedResource model (templates, integrations)

4. Billing & Subscriptions

Q4.1 💰 Pricing Models

Question: What pricing models must be supported?

Model	Description
A	Flat Rate - Fixed monthly/annual fee
B	Per Seat - Price per user
C	Usage-Based - Pay for what you use
D	Tiered - Feature-based tiers (Starter, Pro, Enterprise)
E	Hybrid - Base fee + usage/seats
F	Custom - Enterprise negotiated pricing
G	All of the above

Response: [G] All pricing models supported

Rationale:

Full pricing flexibility for diverse customer segments:

1. FLAT RATE:
   - Simple fixed monthly/annual fee
   - Best for: Starter tier, predictable costs
   - Example: $29/month for Starter plan

2. PER SEAT:
   - Price per active user
   - Tiers: Individual, Team (5-pack), Enterprise (unlimited)
   - Example: $15/user/month

3. USAGE-BASED:
   - Metered billing for consumption
   - Metrics: API calls, compute hours, storage GB, AI tokens
   - Example: $0.10 per 1K API calls

4. TIERED:
   - Feature-based tiers with clear upgrade path
   - Starter → Professional → Business → Enterprise
   - Each tier unlocks features + higher limits

5. HYBRID:
   - Base platform fee + usage/seat charges
   - Most common enterprise model
   - Example: $500/month base + $20/user + usage

6. CUSTOM:
   - Negotiated enterprise contracts
   - Volume discounts, committed spend
   - Custom SLAs, support tiers
   - Multi-year agreements

IMPLEMENTATION:
- PricingPlan model with plan_type enum
- PricingComponent model (base, per_seat, usage)
- UsageMeter model for tracking consumption
- Stripe integration for all models

Q4.2 💰 Billing Frequency

Question: What billing frequencies are needed?

Option	Description
A	Monthly only
B	Annual only
C	Monthly + Annual
D	C + Quarterly
E	D + Custom cycles

Response: [E] All frequencies including custom cycles

Rationale:

Complete billing frequency flexibility:

STANDARD FREQUENCIES:
- Monthly: Default for most plans, auto-renew on same day
- Quarterly: 3-month cycles, common for SMB
- Annual: Discounted (typically 15-20% vs monthly)

CUSTOM CYCLES:
- Multi-year: 2-year, 3-year enterprise contracts
- Fiscal year aligned: Start/end on customer's fiscal year
- Calendar year: Jan 1 - Dec 31 regardless of start date
- Custom duration: 6-month pilot, 18-month contract

BILLING DATE HANDLING:
- Anniversary billing: Bill on signup date each cycle
- Calendar billing: Bill on 1st of month (prorate first)
- Fiscal billing: Bill on customer's fiscal period start

PRORATION RULES:
- Upgrades: Immediate proration, charge difference
- Downgrades: Credit applied to next cycle
- Mid-cycle changes: Calculate remaining days

IMPLEMENTATION:
- Subscription model with billing_frequency enum
- billing_anchor_date for custom alignment
- Stripe Billing for standard, custom logic for complex

DISCOUNTS:
- Annual: 15-20% off monthly rate
- Multi-year: Additional 5-10% per year committed
- Prepaid: Additional discount for upfront payment

Q4.3 💰 Usage Metering

Question: What usage metrics need metering?

Metric	Description
A	API Calls - Per-request billing
B	Compute Time - Workstation hours
C	Storage - GB stored
D	Tokens - AI/LLM token consumption
E	Transactions - Per-transaction fees
F	Custom Metrics - Configurable meters

Selected Metrics: [A, B, C, D, E, F] All metrics + custom

Rationale:

Comprehensive usage metering for flexible billing:

STANDARD METERS:
1. API Calls:
   - Count per endpoint category (read, write, compute)
   - Rate limiting integration
   - Tiered pricing (first 10K free, then $0.10/1K)

2. Compute Time:
   - Cloud Workstation hours
   - GPU vs CPU differentiation
   - Idle timeout credits
   - Per-minute or per-hour billing

3. Storage:
   - GB-months for persistent storage
   - Hot vs cold storage tiers
   - Bandwidth (egress charges)
   - Snapshot/backup storage

4. AI/LLM Tokens:
   - Input tokens vs output tokens
   - Model tier pricing (GPT-4 vs Claude vs local)
   - Cached vs fresh requests
   - Agent execution time

5. Transactions:
   - Commerce transactions (checkout)
   - Document generations
   - Report exports
   - Integration sync events

CUSTOM METRICS:
- Admin-defined meters per tenant
- Webhook-based event counting
- Third-party integration usage
- White-label partner billing meters

IMPLEMENTATION:
- UsageMeter model (meter_id, unit, aggregation_type)
- UsageRecord model (tenant, meter, quantity, timestamp)
- Real-time aggregation with Redis
- Hourly rollup to PostgreSQL
- Stripe Metering API integration

Q4.4 💰 Multi-Currency Support

Question: What multi-currency features are needed?

Option	Description
A	Single Currency - USD only
B	Display Currency - Show prices in local, bill in USD
C	True Multi-Currency - Bill in customer's currency
D	C + Exchange Rate Management
E	D + Realized Gain/Loss Tracking

Response: [E] Full multi-currency with FX accounting

Rationale:

Complete multi-currency support for global operations:

1. CURRENCY MANAGEMENT:
   - Base currency per legal entity (from Q1.3)
   - Transaction currency per invoice/payment
   - Reporting currencies (consolidation)
   - 150+ currencies supported (ISO 4217)

2. EXCHANGE RATE HANDLING:
   - Daily rate feeds (ECB, Open Exchange Rates)
   - Historical rate storage for audit
   - Rate type: Spot, Average, End-of-period
   - Manual override capability
   - Rate lock at transaction time

3. BILLING IN CUSTOMER CURRENCY:
   - Invoice in EUR, GBP, JPY, etc.
   - Payment collection via Stripe multi-currency
   - Currency-specific payment methods (iDEAL, SEPA)
   - Price localization (psychological pricing)

4. FX ACCOUNTING:
   - Unrealized gain/loss on open invoices
   - Realized gain/loss at payment
   - Revaluation at period end
   - FX gain/loss GL accounts
   - Currency translation for consolidation

5. REPORTING:
   - P&L in base currency with FX impact
   - Balance sheet translation (current rate method)
   - Cumulative translation adjustment (CTA)
   - Currency exposure reports

IMPLEMENTATION:
- Currency model with decimal precision
- ExchangeRate model (from, to, rate, date, type)
- All monetary fields: (amount, currency_code)
- FX calculation service
- Stripe multi-currency checkout

Q4.5 💰 Payment Methods

Question: What payment methods must be supported?

Method	Description
A	Credit Card (Stripe)
B	ACH/Bank Transfer
C	Wire Transfer
D	Invoice (Net 30/60/90)
E	Purchase Orders
F	Prepaid Credits
G	All of the above

Response: [G] All payment methods

Rationale:

Full payment method support for all customer segments:

1. CREDIT CARD (Primary):
   - Stripe integration (Visa, MC, Amex, Discover)
   - Card on file for recurring billing
   - 3D Secure for SCA compliance (EU)
   - Card update notifications (expiry)

2. ACH/BANK TRANSFER:
   - Stripe ACH for US customers
   - Lower fees than card (0.8% vs 2.9%)
   - 3-5 day settlement
   - Suitable for larger amounts

3. WIRE TRANSFER:
   - International customers
   - Manual reconciliation workflow
   - Wire instructions per currency
   - Remittance advice matching

4. INVOICE (Net Terms):
   - Net 30, 60, 90 configurable
   - Enterprise customers
   - Manual approval workflow
   - Credit check integration
   - Dunning automation

5. PURCHASE ORDERS:
   - Enterprise procurement workflow
   - PO number on invoice
   - 3-way matching
   - Approval hierarchy

6. PREPAID CREDITS:
   - Credit balance account
   - Top-up via any payment method
   - Auto-replenish threshold
   - Credit expiry policies

IMPLEMENTATION:
- PaymentMethod model (type, details, default)
- Invoice model with payment_terms
- CreditBalance model for prepaid
- Stripe Payment Methods API
- Manual payment reconciliation workflow

Q4.6 💰 Revenue Recognition

Question: What revenue recognition requirements exist?

Option	Description
A	Cash Basis - Recognize when paid
B	Accrual - Recognize when earned
C	ASC 606 - Performance obligation-based
D	IFRS 15 - International standard
E	C + D - Multi-GAAP support

Response: [E] Multi-GAAP (ASC 606 + IFRS 15)

Rationale:

Full revenue recognition compliance for enterprise customers:

1. ASC 606 COMPLIANCE (US GAAP):
   - 5-step model:
     1. Identify contract
     2. Identify performance obligations
     3. Determine transaction price
     4. Allocate price to obligations
     5. Recognize revenue as obligations satisfied
   - Required for US public companies

2. IFRS 15 COMPLIANCE (International):
   - Similar 5-step model
   - Different handling of variable consideration
   - Required for non-US public companies

3. IMPLEMENTATION APPROACH:
   - Contract model with performance_obligations
   - RevenueSchedule for deferred revenue
   - RevenueRecognitionEvent for journal entries
   - Multi-element arrangement support
   - Variable consideration estimation

4. REPORTING:
   - Deferred revenue waterfall
   - Revenue by performance obligation
   - Contract asset/liability aging
   - Disclosure support

5. INTEGRATION:
   - Export to ERP (NetSuite, SAP)
   - Audit trail
   - Period-end close support
   - Retroactive adjustment handling

Supports professional services + subscription hybrid contracts.

5. Accounting Foundation

Q5.1 🏗️ Chart of Accounts

Question: What chart of accounts structure is needed?

Option	Description
A	Fixed - Predefined accounts only
B	Flexible - Unlimited custom accounts
C	Template-Based - Industry templates with customization
D	Multi-Segment - Account + dimensions (cost center, project, etc.)

Response: [D] Multi-segment chart of accounts

Rationale:

Enterprise-grade multi-segment chart of accounts:

1. ACCOUNT STRUCTURE:
   - Account Number: 4-digit minimum, expandable
   - Account Name: Description
   - Account Type: Asset, Liability, Equity, Revenue, Expense
   - Normal Balance: Debit or Credit
   - Currency: Account currency (for foreign ops)

2. SEGMENT DIMENSIONS:
   - Legal Entity: From Q1.3
   - Operating Unit: Department/Division
   - Cost Center: Expense allocation
   - Project: Project-level tracking
   - Product Line: Revenue attribution
   - Customer/Vendor: Subledger link
   - Custom: Up to 5 additional

3. SEGMENT COMBINATIONS:
   - Valid combination rules
   - Default values by entity
   - Cross-validation rules
   - Inactive combination blocking

4. TEMPLATES:
   - SaaS/Technology template
   - Professional Services template
   - Healthcare template
   - Manufacturing template
   - Custom from scratch

5. HIERARCHY:
   - Rollup accounts for reporting
   - Parent-child relationships
   - Summary vs posting accounts

IMPLEMENTATION:
- Account model with segment fields
- SegmentDefinition model
- SegmentValidation rules
- AccountTemplate for quick setup

Q5.2 🏗️ General Ledger Features

Question: What general ledger capabilities are needed?

Feature	Description
A	Journal Entries - Manual and automated
B	Multi-Currency GL - Foreign currency transactions
C	Intercompany - Cross-entity transactions
D	Allocations - Automatic cost allocations
E	Recurring Entries - Scheduled journals
F	All of the above

Response: [F] Full general ledger functionality

Rationale:

Complete general ledger for enterprise accounting:

1. JOURNAL ENTRIES:
   - Manual entry interface
   - Automated entries from subledgers
   - Reversing entries
   - Statistical entries (non-financial)
   - Batch upload (Excel, CSV)

2. MULTI-CURRENCY GL:
   - Transaction currency
   - Functional currency
   - Reporting currency
   - Revaluation processing
   - Translation for consolidation

3. INTERCOMPANY ACCOUNTING:
   - Auto-generate balancing entries
   - Intercompany accounts by entity pair
   - Due to/Due from tracking
   - Elimination entries for consolidation
   - Transfer pricing support

4. ALLOCATIONS:
   - Fixed percentage allocations
   - Statistical allocations (headcount, sq ft)
   - Step-down allocations
   - Allocation schedules
   - Allocation reversal

5. RECURRING ENTRIES:
   - Frequency: Daily, weekly, monthly, quarterly, annual
   - Amount: Fixed, percentage, calculated
   - Auto-reverse option
   - Expiration date

IMPLEMENTATION:
- JournalEntry header model
- JournalLine detail model
- AllocationRule model
- RecurringJournal model
- IntercompanyRule model

Q5.3 💰 Accounts Receivable

Question: What AR capabilities are needed?

Feature	Description
A	Customer Master - Customer records
B	Invoicing - Generate and send invoices
C	Cash Application - Match payments to invoices
D	Dunning - Collection workflow
E	Credit Management - Credit limits, holds
F	All of the above

Response: [F] Full AR functionality

Rationale:

Complete accounts receivable for subscription and service billing:

1. CUSTOMER MASTER:
   - Customer hierarchy (parent/child)
   - Multiple bill-to/ship-to addresses
   - Payment terms by customer
   - Credit limit and terms
   - Tax exemption certificates
   - Customer classification/grouping

2. INVOICING:
   - Subscription invoices (automated)
   - Usage invoices (metered)
   - Manual invoices (one-time)
   - Credit memos
   - Invoice delivery (email, portal)
   - Multi-currency invoicing

3. CASH APPLICATION:
   - Automatic matching (invoice # in remittance)
   - Manual matching interface
   - Partial payments
   - Overpayments/credits
   - Bank feed integration
   - Cash application rules engine

4. DUNNING:
   - Dunning levels (reminder → warning → final)
   - Escalation workflow
   - Customer communication templates
   - Grace periods
   - Service suspension triggers
   - Collection agency handoff

5. CREDIT MANAGEMENT:
   - Credit limit checking
   - Credit hold workflow
   - Credit score integration (optional)
   - Aging reports
   - Bad debt write-off
   - Reserve estimation

IMPLEMENTATION:
- Customer model with hierarchy
- Invoice model linked to subscription
- Payment model with application
- DunningQueue model
- CreditLimit model

Q5.4 💰 Accounts Payable

Question: What AP capabilities are needed?

Feature	Description
A	Vendor Master - Vendor records
B	Invoice Processing - Enter and approve bills
C	Payment Processing - Pay vendors
D	3-Way Matching - PO, receipt, invoice
E	1099 Reporting - Tax forms for US vendors
F	All of the above

Response: [F] Full AP functionality

Rationale:

Complete accounts payable for operational expenses:

1. VENDOR MASTER:
   - Vendor hierarchy (parent/subsidiaries)
   - Multiple remit-to addresses
   - Payment terms by vendor
   - Payment method preference
   - Tax ID / W-9 tracking
   - Vendor classification

2. INVOICE PROCESSING:
   - Manual invoice entry
   - Email inbox capture (OCR future)
   - Approval workflow (amount-based)
   - Coding to GL/project
   - Accrual support
   - Multi-currency invoices

3. PAYMENT PROCESSING:
   - Payment batch creation
   - Payment method: Check, ACH, Wire
   - Payment approval workflow
   - Positive pay file generation
   - Payment status tracking
   - Void/reissue workflow

4. 3-WAY MATCHING:
   - Purchase order matching
   - Receipt matching
   - Variance tolerance rules
   - Match exception workflow
   - Auto-match rules

5. 1099 REPORTING:
   - 1099-NEC, 1099-MISC tracking
   - Payment accumulation by vendor
   - 1099 form generation
   - E-file to IRS
   - Vendor portal for W-9

IMPLEMENTATION:
- Vendor model with hierarchy
- VendorInvoice model
- PaymentBatch model
- MatchingRule model
- Tax1099 model

Q5.5 🔧 Financial Close

Question: What period-end close capabilities are needed?

Feature	Description
A	Period Lock - Prevent posting to closed periods
B	Close Checklist - Task tracking
C	Reconciliations - Balance verification
D	Adjustments - Post-close adjustments
E	Consolidation - Multi-entity combination
F	All of the above

Response: [F] Full financial close functionality

Rationale:

Enterprise financial close for audit-ready financials:

1. PERIOD LOCK:
   - Period status: Open, Soft Close, Hard Close
   - Entity-specific close dates
   - GL/module-specific locks
   - Authorized unlock for corrections
   - Audit trail of period changes

2. CLOSE CHECKLIST:
   - Standard close tasks
   - Custom task addition
   - Task dependencies
   - Assignee and due dates
   - Status tracking
   - Supporting documentation

3. RECONCILIATIONS:
   - Account reconciliation templates
   - Bank reconciliation
   - Intercompany reconciliation
   - Variance explanation
   - Signoff workflow
   - Certifications

4. ADJUSTMENTS:
   - Top-side adjustments
   - Audit adjustments
   - Reclassifications
   - Prior period adjustments
   - Adjustment journal types

5. CONSOLIDATION:
   - Ownership percentage tracking
   - Elimination entries
   - Currency translation
   - Minority interest
   - Consolidation journal
   - Consolidated trial balance

IMPLEMENTATION:
- AccountingPeriod model
- CloseChecklist model
- Reconciliation model
- Consolidation model
- EliminationRule model

6. Data Isolation & Compliance

Q6.1 🏗️ Data Residency

Question: What data residency requirements must be supported?

Option	Description
A	Single Region - US only
B	Multi-Region - US, EU, APAC
C	Country-Specific - Data stays in customer's country
D	B + C + Customer-Managed Keys (BYOK)

Response: [D] Multi-region + country-specific + BYOK

Rationale:

Complete data residency support for global compliance:

1. REGIONAL DEPLOYMENT:
   - US: us-central1 (primary), us-east1 (DR)
   - EU: europe-west1 (primary), europe-west4 (DR)
   - APAC: asia-east1 (primary), asia-northeast1 (DR)
   - Canada: northamerica-northeast1 (future)

2. COUNTRY-SPECIFIC:
   - Germany: Dedicated infra for strict GDPR
   - Australia: Local data for APRA compliance
   - Japan: APPI compliance
   - Data never leaves specified region

3. DATA CATEGORIES:
   - Customer PII: Strictly regional
   - Financial data: Strictly regional
   - System logs: Regional with aggregation
   - Analytics: Anonymized global

4. BYOK (Bring Your Own Key):
   - Customer provides Cloud KMS key
   - CODITECT encrypts with customer key
   - Customer controls key lifecycle
   - Key rotation support
   - Key access auditing

5. MIGRATION SUPPORT:
   - Data migration between regions
   - Zero-downtime region change
   - Data export for portability

IMPLEMENTATION:
- Region enum on Tenant model
- DataCategory classification
- EncryptionKey model with BYOK support
- Region-specific infrastructure modules

Q6.2 🏗️ Compliance Frameworks

Question: What compliance frameworks must be supported?

Framework	Description
A	SOC 2 Type II - Security controls
B	GDPR - EU data protection
C	HIPAA - Healthcare data (US)
D	PCI DSS - Payment card data
E	ISO 27001 - Information security
F	All of the above

Response: [F] All compliance frameworks

Rationale:

Multi-framework compliance for enterprise customers:

1. SOC 2 TYPE II:
   - Trust service criteria: Security, Availability, Confidentiality
   - Annual audit
   - Controls: Access, encryption, monitoring
   - Evidence collection automation

2. GDPR:
   - Data subject rights (access, delete, portability)
   - Consent management
   - Data processing agreements
   - Breach notification (<72 hours)
   - Privacy impact assessments
   - DPO appointment for EU processing

3. HIPAA (Healthcare):
   - PHI identification and protection
   - Business Associate Agreements (BAAs)
   - Access controls and audit logs
   - Encryption (at rest, in transit)
   - Dedicated healthcare tier

4. PCI DSS (Payments):
   - Stripe handles card data (PCI compliant)
   - SAQ-A qualification (minimal scope)
   - No card data storage
   - Tokenization for recurring

5. ISO 27001:
   - Information Security Management System (ISMS)
   - Risk assessment
   - Security policies
   - Continuous improvement
   - Certification audit

IMPLEMENTATION:
- ComplianceFramework model
- TenantCompliance relationship
- ComplianceEvidence model
- Automated control testing
- Compliance dashboard

Q6.3 🔧 Audit Logging

Question: What level of audit logging is needed?

Option	Description
A	Authentication Only - Login/logout
B	A + Data Access - Who viewed what
C	B + Data Changes - Full audit trail
D	C + System Events - Administrative actions
E	D + Immutable Log - Tamper-proof storage

Response: [E] Immutable comprehensive audit log

Rationale:

Enterprise-grade audit logging for compliance:

1. AUTHENTICATION EVENTS:
   - Login success/failure
   - Logout
   - Password changes
   - MFA enrollment/use
   - Session timeout
   - Impersonation start/end

2. DATA ACCESS:
   - Record views (sensitive data)
   - Report generation
   - Export operations
   - Search queries
   - API access

3. DATA CHANGES:
   - Create/Update/Delete
   - Before/after values
   - Changed fields
   - Changed by user
   - Timestamp
   - Source (UI, API, system)

4. SYSTEM EVENTS:
   - Configuration changes
   - Permission changes
   - Role assignments
   - Feature flag changes
   - Integration connections
   - Tenant lifecycle events

5. IMMUTABILITY:
   - Write-once, append-only storage
   - Cryptographic chaining
   - Tamper detection
   - Off-site backup
   - 7+ year retention

IMPLEMENTATION:
- AuditLog model (append-only)
- AuditLogStream for real-time
- Hash chain for immutability
- Cloud Audit Logs integration
- SIEM export capability

Q6.4 🔧 Data Retention

Question: What data retention policies are needed?

Option	Description
A	Forever - No automatic deletion
B	Configurable - Tenant sets retention
C	B + Legal Hold - Suspend deletion for litigation
D	C + Compliance Minimums - Framework-based minimums

Response: [D] Configurable + Legal Hold + Compliance Minimums

Rationale:

Flexible data retention with compliance safeguards:

1. RETENTION POLICIES:
   - Default: 7 years (financial data)
   - Configurable per data type
   - Shorter for non-essential data
   - Entity-specific overrides

2. DATA CATEGORIES:
   | Category | Default | Minimum |
   |----------|---------|---------|
   | Financial records | 7 years | 7 years (SOX) |
   | Tax records | 7 years | 7 years (IRS) |
   | Audit logs | 7 years | 3 years (SOC 2) |
   | User activity | 3 years | 1 year |
   | System logs | 1 year | 90 days |
   | Deleted user data | 90 days | 30 days (GDPR) |

3. LEGAL HOLD:
   - Suspend deletion for specific records
   - Matter-based holds
   - Custodian notification
   - Hold release workflow
   - eDiscovery export

4. DELETION WORKFLOW:
   - Soft delete first
   - Retention period countdown
   - Legal hold check
   - Hard delete after retention
   - Deletion certificate

5. GDPR SPECIAL HANDLING:
   - Right to erasure requests
   - 30-day fulfillment
   - Exceptions for legal obligations
   - Deletion confirmation

IMPLEMENTATION:
- RetentionPolicy model
- LegalHold model
- DeletionQueue (async)
- DataCategoryTag on models
- Retention enforcement job

Q6.5 🔧 Data Export

Question: What data export capabilities are needed?

Feature	Description
A	UI Export - Download from interface
B	API Export - Programmatic bulk export
C	Scheduled Export - Automated periodic exports
D	Data Warehouse Feed - Direct to customer warehouse
E	GDPR Portability - Individual user data export
F	All of the above

Response: [F] All export capabilities

Rationale:

Complete data portability for customer control:

1. UI EXPORT:
   - Export from any list view
   - Format: CSV, Excel, PDF
   - Filtered export (current view)
   - Full export (all records)
   - Async for large datasets

2. API EXPORT:
   - Bulk export endpoints
   - Pagination for large datasets
   - Filter parameters
   - Rate limiting for fair use
   - Streaming for very large exports
   - API documentation

4. STANDARD FORMATS:
   - CSV (spreadsheet compatible)
   - JSON (developer friendly)
   - SQL (database restore)
   - XML (legacy systems)
   - Parquet (data warehouse)
   - PDF (reports)

5. GDPR PORTABILITY:
   - Individual user data export
   - Machine-readable format
   - 30-day fulfillment SLA
   - Self-service in user settings
   - Includes all personal data
   - Excludes other users' data

ADDITIONAL FEATURES:
- Data import (migration assistance)
- Schema documentation
- Relationship mapping
- Data dictionary export
- Encryption at rest and in transit

IMPLEMENTATION:
- ExportJob model (async processing)
- ExportTemplate for recurring exports
- CustomerStorageConnection model
- GDPRExportRequest model
- Export worker (Celery)

7. White-Label & Branding

Q7.1 🔧 White-Label Scope

Question: What can white-label partners customize?

Feature	Description
A	Branding Only - Logo, colors, name
B	A + Domain - Custom domain
C	B + Email Templates - Custom email sender
D	C + UI Customization - Custom CSS/themes
E	D + Feature Toggle - Show/hide features
F	E + API Branding - Custom API endpoints

Response: [F] Full white-label customization

Rationale:

Complete white-label capability for B2B partner deployment:

1. BRANDING:
   - Logo (header, favicon, loading screen)
   - Brand name throughout UI
   - Color palette (primary, secondary, accent)
   - Typography (font family)
   - Footer text and links
   - "Powered by" optional display

2. CUSTOM DOMAIN:
   - Partner's domain (app.partnerbrand.com)
   - SSL certificate management
   - DNS configuration guidance
   - Subdomain for partner's customers
   - Email domain alignment

3. EMAIL TEMPLATES:
   - Custom sender (noreply@partnerbrand.com)
   - Branded email templates
   - Custom email footer
   - Partner support contact
   - Transactional email customization

4. UI CUSTOMIZATION:
   - Custom CSS injection
   - Theme builder (light/dark)
   - Layout preferences
   - Custom landing page
   - Login page branding
   - Dashboard widgets

5. FEATURE TOGGLE:
   - Hide/show platform features
   - Custom feature naming
   - Partner-specific modules
   - Disable features not in scope
   - Beta feature control

6. API BRANDING:
   - Custom API subdomain (api.partnerbrand.com)
   - Branded API documentation
   - Custom error messages
   - Partner-specific endpoints
   - API response branding

IMPLEMENTATION:
- WhiteLabelConfig model per partner
- BrandingAssets storage (logos, CSS)
- DomainMapping with SSL
- EmailTemplate per partner
- FeatureToggle per partner
- APIGateway routing rules

Q7.2 💰 White-Label Revenue Model

Question: How will white-label partners be billed?

Model	Description
A	Revenue Share - % of partner's revenue
B	Per-User Platform Fee - Fixed fee per end-user
C	Flat Platform Fee - Monthly platform license
D	Usage-Based - Based on partner's usage
E	Hybrid - Base fee + revenue share

Response: [E] Hybrid (base fee + revenue share)

Rationale:

Hybrid revenue model balancing predictable revenue with growth alignment:

1. BASE PLATFORM FEE:
   - Monthly platform access fee
   - Covers infrastructure, support, updates
   - Tiered by partner size/tier:
     * Starter Partner: $500/month
     * Growth Partner: $2,000/month
     * Enterprise Partner: $5,000/month
   - Includes base usage allocation

2. REVENUE SHARE:
   - Percentage of partner's customer revenue
   - Tiered by volume:
     * First $50K/month: 20% share
     * $50K - $200K/month: 15% share
     * $200K+/month: 10% share
   - Calculated on net revenue (after refunds)
   - Monthly reconciliation

3. USAGE OVERAGE:
   - Compute beyond allocation
   - Storage beyond allocation
   - API calls beyond tier limits
   - Metered at standard rates

4. OPTIONAL ADD-ONS:
   - Priority support: +$500/month
   - Dedicated infrastructure: +$2,000/month
   - Custom development: Hourly rate
   - Training/onboarding: One-time fee

PARTNER TIERS:
- Starter: <100 end-users, basic support
- Growth: 100-1000 end-users, priority support
- Enterprise: 1000+ end-users, dedicated CSM

BILLING:
- Base fee: Invoiced monthly in advance
- Revenue share: Invoiced monthly in arrears
- Net 30 payment terms
- Partner dashboard for revenue tracking

IMPLEMENTATION:
- PartnerContract model
- RevenueShareTier model
- PartnerBilling service
- Partner revenue dashboard
- Automated share calculation

Q7.3 🔧 Partner Administration

Question: What admin capabilities do white-label partners get?

Capability	Description
A	User Management - Manage their customers' users
B	Billing Control - Set pricing for their customers
C	Feature Toggle - Enable/disable features
D	Branding Control - Update branding anytime
E	Support Access - View customer tickets
F	Analytics - View usage analytics
G	All of the above

Response: [G] All admin capabilities

Rationale:

Complete partner administration for autonomous operation:

1. USER MANAGEMENT:
   - View all customers and users
   - Create/invite customers
   - Impersonate users (with audit)
   - Reset passwords
   - Suspend/reactivate accounts
   - Bulk user operations

2. BILLING CONTROL:
   - Define pricing plans
   - Set custom pricing per customer
   - Apply discounts/promotions
   - View revenue reports
   - Manage payment methods
   - Handle refunds/credits

3. FEATURE TOGGLE:
   - Enable/disable features per customer
   - Create feature bundles
   - Manage beta access
   - Set usage limits
   - Custom feature naming

4. BRANDING CONTROL:
   - Update logo/colors anytime
   - Preview before publish
   - A/B test branding
   - Email template editor
   - Custom domain management
   - CSS customization

5. SUPPORT ACCESS:
   - View customer support tickets
   - Escalate to platform support
   - Knowledge base management
   - Canned responses
   - SLA tracking
   - Customer health scores

6. ANALYTICS:
   - Customer usage dashboard
   - Revenue analytics
   - Churn metrics
   - Feature adoption
   - API usage stats
   - Custom reports
   - Export capabilities

PARTNER PORTAL FEATURES:
- Single dashboard for all customers
- Multi-customer search
- Bulk operations
- Notification center
- Partner API for automation

IMPLEMENTATION:
- PartnerPortal frontend
- PartnerAdmin role with scoped permissions
- CustomerImpersonation with audit
- PartnerAnalytics service
- PartnerBilling module

8. Integration & APIs

Q8.1 🏗️ API Architecture

Question: What API architecture is needed?

Option	Description
A	REST only
B	REST + GraphQL
C	REST + gRPC
D	REST + GraphQL + WebSocket
E	All of the above

Response: [E] Full API stack (REST + GraphQL + gRPC + WebSocket)

Rationale:

Complete API architecture for all integration scenarios:

1. REST API (Primary):
   - Standard CRUD operations
   - Resource-based URLs
   - JSON request/response
   - OpenAPI 3.0 specification
   - Versioned endpoints (v1, v2)
   - Rate limiting
   - Use cases: Web apps, mobile, integrations

2. GraphQL API:
   - Flexible queries (fetch what you need)
   - Reduced over-fetching
   - Single endpoint
   - Schema introspection
   - Subscriptions for real-time
   - Use cases: Complex UIs, mobile apps

3. gRPC API:
   - High-performance binary protocol
   - Strongly typed (Protocol Buffers)
   - Bidirectional streaming
   - Service-to-service communication
   - Use cases: Internal microservices, high-throughput

4. WebSocket API:
   - Real-time bidirectional
   - Persistent connections
   - Event-driven updates
   - Use cases:
     * Live notifications
     * Collaborative editing
     * Workstation terminal
     * Chat/messaging
     * Real-time dashboards

IMPLEMENTATION PRIORITY:
- Phase 1: REST API (foundation)
- Phase 2: WebSocket (real-time features)
- Phase 3: GraphQL (frontend optimization)
- Phase 4: gRPC (internal services)

COMMON FEATURES:
- Unified authentication (JWT)
- Consistent error handling
- Request tracing
- Rate limiting
- API versioning
- SDK generation

IMPLEMENTATION:
- Django REST Framework (REST)
- Strawberry/Graphene (GraphQL)
- grpcio (gRPC)
- Django Channels (WebSocket)
- API Gateway (Kong/Envoy)

Q8.2 🔧 Integration Patterns

Question: What integration patterns must be supported?

Pattern	Description
A	Webhooks - Event notifications
B	Polling - Status check endpoints
C	ETL Export - Data warehouse feeds
D	iPaaS Connectors - Zapier, Make, n8n
E	Native Integrations - First-party connectors
F	All of the above

Response: [F] All integration patterns

Rationale:

Complete integration ecosystem for enterprise connectivity:

1. WEBHOOKS (Push):
   - Event-driven notifications
   - Configurable event types
   - Retry with exponential backoff
   - Signature verification (HMAC)
   - Webhook logs and debugging
   - Delivery status tracking

   EVENTS:
   - user.created, user.updated
   - subscription.created, subscription.cancelled
   - invoice.paid, invoice.overdue
   - project.created, project.completed
   - Custom events

2. POLLING (Pull):
   - Status check endpoints
   - Long-polling option
   - ETag/If-Modified-Since
   - Cursor-based pagination
   - Rate limiting awareness

3. ETL EXPORT:
   - Scheduled data exports
   - Incremental sync (CDC)
   - Full refresh option
   - Destinations:
     * BigQuery
     * Snowflake
     * Redshift
     * S3/GCS (Parquet, CSV)
   - Schema evolution handling

4. iPaaS CONNECTORS:
   - Zapier (official integration)
   - Make (Integromat)
   - n8n (self-hosted option)
   - Workato
   - Triggers and actions
   - OAuth for connection

5. NATIVE INTEGRATIONS:
   - Slack notifications
   - GitHub/GitLab repos
   - Google Workspace
   - Microsoft 365
   - QuickBooks/Xero accounting
   - Stripe/PayPal payments

IMPLEMENTATION:
- Webhook model with event types
- WebhookDelivery with retry
- ETLJob model
- OAuthConnection model
- Integration marketplace (future)

Q8.3 🔧 Authentication for APIs

Question: What API authentication methods are needed?

Method	Description
A	API Keys - Simple key-based auth
B	OAuth 2.0 - Token-based with refresh
C	JWT - Stateless tokens
D	mTLS - Mutual TLS for service accounts
E	All of the above

Response: [E] All authentication methods

Rationale:

Multiple auth methods for different use cases:

1. API KEYS:
   - Simple integration testing
   - Server-to-server without OAuth
   - Scoped permissions
   - Key rotation
   - Rate limiting per key
   - Use case: Quick integrations, testing

2. OAuth 2.0:
   - User-authorized access
   - Refresh tokens for long-lived access
   - Scopes for permission control
   - Authorization Code flow (web apps)
   - Client Credentials flow (service accounts)
   - Use case: Third-party apps, marketplace

3. JWT:
   - Stateless authentication
   - Short-lived access tokens (15 min)
   - Refresh tokens (7 days)
   - Claims for user context
   - Use case: Frontend apps, mobile

4. mTLS:
   - Certificate-based authentication
   - Mutual verification
   - No secrets transmitted
   - Certificate rotation
   - Use case: High-security service accounts, banking

IMPLEMENTATION:
- APIKey model with scopes
- OAuthApplication model
- JWTGenerator service
- mTLS support in API Gateway
- Unified permission evaluation

Q8.4 🏗️ Rate Limiting

Question: What rate limiting strategy is needed?

Option	Description
A	Global - Same limits for all
B	Per-Tier - Limits based on subscription
C	Per-Endpoint - Different limits per API
D	Adaptive - Dynamic based on load
E	B + C + D

Response: [E] Tiered + Per-Endpoint + Adaptive

Rationale:

Sophisticated rate limiting for fair use and system protection:

1. PER-TIER LIMITS:
   | Tier | Requests/min | Requests/day |
   |------|--------------|--------------|
   | Free/Trial | 60 | 1,000 |
   | Starter | 100 | 10,000 |
   | Professional | 500 | 100,000 |
   | Business | 1,000 | 500,000 |
   | Enterprise | Custom | Custom |

2. PER-ENDPOINT LIMITS:
   - Read endpoints: Higher limits
   - Write endpoints: Lower limits
   - Compute-intensive: Strict limits
   - Bulk operations: Very strict
   - Example:
     * GET /api/v1/projects: 100/min
     * POST /api/v1/projects: 20/min
     * POST /api/v1/reports/generate: 5/min

3. ADAPTIVE LIMITING:
   - Reduce limits during high load
   - Increase limits during low load
   - Priority queuing for paid tiers
   - Circuit breaker for downstream failures
   - Graceful degradation

4. RATE LIMIT HEADERS:
   - X-RateLimit-Limit: Max requests
   - X-RateLimit-Remaining: Requests left
   - X-RateLimit-Reset: Reset timestamp
   - Retry-After: When to retry (429)

5. SPECIAL HANDLING:
   - Webhook delivery: Separate limits
   - Batch operations: Request aggregation
   - Export jobs: Async queue, no limit
   - Admin operations: Bypass (with audit)

IMPLEMENTATION:
- Redis for rate limit counters
- Token bucket algorithm
- Rate limit configuration per endpoint
- Tier-based multipliers
- Load-based adjustment service

9. Reporting & Analytics

Q9.1 🔧 Standard Reports

Question: What standard reports are needed?

Report Category	Examples
A	Financial - P&L, Balance Sheet, Cash Flow
B	Subscription - MRR, Churn, LTV
C	Usage - API calls, Storage, Compute
D	Operational - Projects, Teams, Activity
E	Compliance - Audit, Access, Changes
F	All of the above

Response: [F] All report categories

Rationale:

Comprehensive reporting across all business domains:

1. FINANCIAL REPORTS:
   - Income Statement (P&L)
   - Balance Sheet
   - Cash Flow Statement
   - Trial Balance
   - General Ledger
   - AR Aging
   - AP Aging
   - Budget vs Actual

2. SUBSCRIPTION REPORTS:
   - Monthly Recurring Revenue (MRR)
   - Annual Recurring Revenue (ARR)
   - Churn Rate (logo and revenue)
   - Customer Lifetime Value (LTV)
   - Customer Acquisition Cost (CAC)
   - Net Revenue Retention (NRR)
   - Cohort Analysis
   - Subscription Growth

3. USAGE REPORTS:
   - API Call Volume
   - Storage Utilization
   - Compute Hours
   - Bandwidth Usage
   - Token Consumption
   - Feature Usage
   - User Activity

4. OPERATIONAL REPORTS:
   - Project Status
   - Team Productivity
   - Resource Allocation
   - Time Tracking
   - Milestone Progress
   - Risk Dashboard

5. COMPLIANCE REPORTS:
   - Audit Log Export
   - Access Reviews
   - Permission Changes
   - Data Access Log
   - Compliance Checklist
   - Security Events

IMPLEMENTATION:
- Report model with template
- ReportSchedule for automation
- ReportExecution model
- Report builder UI
- SQL-based custom reports

Q9.2 🔧 Custom Analytics

Question: What custom analytics capabilities are needed?

Feature	Description
A	Dashboards - Visual data display
B	Custom Reports - User-defined reports
C	Data Explorer - Ad-hoc queries
D	Alerting - Threshold notifications
E	All of the above

Response: [E] Full analytics suite

Rationale:

Self-service analytics for business users:

1. DASHBOARDS:
   - Pre-built dashboard templates
   - Custom dashboard builder
   - Widgets: Charts, tables, metrics, gauges
   - Real-time data refresh
   - Dashboard sharing
   - Embedded dashboards

2. CUSTOM REPORTS:
   - Drag-and-drop report builder
   - Column selection
   - Filters and grouping
   - Calculated fields
   - Report scheduling
   - Export formats

3. DATA EXPLORER:
   - Natural language queries (future)
   - SQL mode for power users
   - Query history
   - Saved queries
   - Data dictionary
   - Query performance limits

4. ALERTING:
   - Metric-based alerts
   - Threshold conditions
   - Anomaly detection (future)
   - Alert channels: Email, Slack, SMS
   - Alert escalation
   - Alert acknowledgment

IMPLEMENTATION:
- Dashboard model with widgets
- ReportBuilder service
- QueryEngine with sandboxing
- Alert model with conditions
- Notification service integration

Q9.3 🔧 Data Visualization

Question: What visualization capabilities are needed?

Feature	Description
A	Charts - Bar, line, pie, scatter
B	Tables - Data grids with sorting/filtering
C	Maps - Geographic visualization
D	Pivot Tables - Multi-dimensional analysis
E	All of the above

Response: [E] Full visualization suite

Rationale:

Rich visualization for data exploration:

1. STANDARD CHARTS:
   - Bar charts (vertical, horizontal, stacked)
   - Line charts (trend, multi-series)
   - Pie/Donut charts
   - Area charts
   - Scatter plots
   - Combo charts

2. ADVANCED CHARTS:
   - Waterfall charts (financial)
   - Funnel charts (conversion)
   - Gauge charts (KPIs)
   - Heatmaps (correlation)
   - Treemaps (hierarchy)
   - Sankey diagrams (flow)

3. DATA TABLES:
   - Sortable columns
   - Filterable columns
   - Column reordering
   - Row grouping
   - Inline editing (optional)
   - Export to Excel/CSV

4. GEOGRAPHIC:
   - World map with regions
   - Country/state drill-down
   - Heatmaps by location
   - Point markers
   - Route visualization

5. PIVOT TABLES:
   - Drag-and-drop dimensions
   - Measures and aggregations
   - Drill-down capability
   - Conditional formatting
   - Export to Excel

IMPLEMENTATION:
- Chart library (Apache ECharts)
- Table library (AG Grid)
- Map library (Mapbox/Leaflet)
- Pivot library (PivotTable.js)
- Visualization config model

10. Platform Operations

Q10.1 🏗️ Deployment Model

Question: What deployment models must be supported?

Option	Description
A	SaaS Only - Multi-tenant cloud
B	A + Dedicated - Single-tenant cloud
C	B + On-Premise - Customer data center
D	C + Hybrid - Split data plane

Response: [D] All deployment models

Rationale:

Multiple deployment models for enterprise flexibility:

1. SaaS (Multi-Tenant):
   - Standard cloud deployment
   - Shared infrastructure
   - Cost-effective
   - Automatic updates
   - Suitable for: Starter, Professional, Business

2. Dedicated (Single-Tenant Cloud):
   - Isolated cloud infrastructure
   - Customer-specific VPC
   - Custom compliance configs
   - BYOK encryption
   - Suitable for: Enterprise, regulated industries

3. On-Premise:
   - Customer's data center
   - Full data sovereignty
   - Air-gapped option
   - Customer-managed updates
   - Suitable for: Government, defense, high-security

4. Hybrid:
   - Agent-based data plane
   - Secure tunnel to control plane
   - Local data processing
   - Cloud orchestration

PRICING:
- SaaS: Standard subscription
- Dedicated: +50% premium
- On-Premise: Enterprise license + support
- Hybrid: Custom pricing

Q10.2 🏗️ High Availability

Question: What availability SLA is required?

SLA	Description
A	99% - 7.3 hours downtime/month
B	99.9% - 43.8 minutes downtime/month
C	99.95% - 21.9 minutes downtime/month
D	99.99% - 4.4 minutes downtime/month
E	Different by tier - Higher tier = higher SLA

Response: [E] Tiered SLA by plan

Rationale:

SLA tiered by subscription level to match value and cost:

TIER 1 - STARTER/PROFESSIONAL:
- SLA: 99.5% (3.6 hours/month)
- Support: Business hours
- Credits: 10% for SLA breach
- Planned maintenance: Included in downtime

TIER 2 - BUSINESS:
- SLA: 99.9% (43.8 minutes/month)
- Support: Extended hours (6am-10pm)
- Credits: 25% for SLA breach
- Planned maintenance: Excluded from downtime

TIER 3 - ENTERPRISE:
- SLA: 99.95% (21.9 minutes/month)
- Support: 24/7
- Credits: 50% for SLA breach
- Planned maintenance: Advance notice, excluded

TIER 4 - DEDICATED/PREMIUM:
- SLA: 99.99% (4.4 minutes/month)
- Support: 24/7 with dedicated CSM
- Credits: 100% for SLA breach
- Planned maintenance: Customer-scheduled

SLA MEASUREMENT:
- Measured monthly
- Excludes: Customer-caused, force majeure
- Calculation: (Total - Downtime) / Total × 100

SLA CREDITS:
| Uptime      | Credit |
|-------------|--------|
| 99.0-99.9%  | 10%    |
| 95.0-99.0%  | 25%    |
| 90.0-95.0%  | 50%    |
| < 90.0%     | 100%   |

IMPLEMENTATION:
- UptimeMonitor service
- SLAReport model
- CreditCalculation service
- Status page (statuspage.io)
- Incident tracking
- RCA (Root Cause Analysis) process

Q10.3 🔧 Tenant Provisioning

Question: How should new tenants be provisioned?

Option	Description
A	Self-Service - Instant signup and access
B	Sales-Assisted - Manual approval required
C	Hybrid - Self-service for starter, sales for enterprise
D	API Provisioning - Programmatic tenant creation
E	C + D

Response: [E] Hybrid + API provisioning

Rationale:

Flexible provisioning for all customer acquisition channels:

1. SELF-SERVICE (Starter/Professional):
   - Instant signup via website
   - Email verification
   - Credit card required
   - Immediate access
   - 14-day trial option
   - Automatic provisioning

   FLOW:
   Sign up → Verify email → Add payment → Instant access

2. SALES-ASSISTED (Enterprise):
   - Custom pricing negotiation
   - Security review
   - Legal/contract review
   - Custom onboarding
   - Dedicated CSM assignment
   - Manual provisioning

   FLOW:
   Demo request → Discovery → Proposal → Contract → Provisioning

3. HYBRID APPROACH:
   - Starter/Pro: Self-service
   - Business: Self-service or sales
   - Enterprise: Sales required
   - Upgrade path: Self → Sales

4. API PROVISIONING:
   - White-label partners provision customers
   - Marketplace integrations
   - Automated workflows
   - Programmatic tenant creation

   API ENDPOINTS:
   POST /api/v1/tenants
   {
     "name": "Customer Corp",
     "email": "admin@customer.com",
     "plan": "professional",
     "billing": { ... }
   }

   FEATURES:
   - API key authentication
   - Webhook on completion
   - Async for large provisioning
   - Idempotency keys

PROVISIONING AUTOMATION:
- Database/schema creation
- Default configuration
- Welcome email
- Onboarding checklist
- Sample data (optional)
- Integration setup

IMPLEMENTATION:
- TenantProvisioner service
- ProvisioningJob (async)
- SalesOpportunity model
- PartnerAPI for white-label

Q10.4 🔧 Tenant Lifecycle

Question: What tenant lifecycle operations are needed?

Operation	Description
A	Activation - Enable new tenant
B	Suspension - Disable for non-payment
C	Reactivation - Re-enable after payment
D	Offboarding - Graceful data export and deletion
E	Migration - Move tenant between tiers/regions
F	All of the above

Response: [F] All of the above

Rationale:

Complete tenant lifecycle management required for enterprise-grade platform:
- Activation: New tenant onboarding with provisioning
- Suspension: Non-payment, policy violation, or security concerns
- Reactivation: Payment resolution with data integrity
- Offboarding: GDPR-compliant data export and secure deletion
- Migration: Tier upgrades, region moves, and white-label transitions
Full lifecycle automation enables operational efficiency at scale.

Q10.5 🏗️ Disaster Recovery

Question: What disaster recovery capabilities are needed?

Option	Description
A	Backup Only - Daily backups, manual restore
B	A + Point-in-Time - Restore to any point
C	B + Warm Standby - Secondary region ready
D	C + Hot Standby - Active-active multi-region

Response: [D] Hot Standby - Active-active multi-region

Rationale:

Enterprise-grade disaster recovery with active-active multi-region:
- Daily backups with 30-day retention minimum
- Point-in-time recovery for data corruption scenarios
- Warm standby in secondary region (RPO < 1 hour)
- Hot standby active-active for mission-critical tenants (RPO < 1 min)
- Tiered DR by subscription: Standard (backup), Professional (warm),
  Enterprise (hot)
- Automated failover with DNS-based traffic routing
- Regular DR drills and documented runbooks
- Compliance with SOC 2 and ISO 27001 business continuity requirements

Response Summary

Answered Questions

Section	Answered	Total	Completion
1. Organization Structure	5	5	100% ✅
2. User & Access Management	6	6	100% ✅
3. Multi-Tenant Architecture	4	4	100% ✅
4. Billing & Subscriptions	6	6	100% ✅
5. Accounting Foundation	5	5	100% ✅
6. Data Isolation & Compliance	5	5	100% ✅
7. White-Label & Branding	3	3	100% ✅
8. Integration & APIs	4	4	100% ✅
9. Reporting & Analytics	3	3	100% ✅
10. Platform Operations	5	5	100% ✅
Total	46	46	100% ✅

Architectural Decisions Log

Decision 1: [Pending]

Question:
Decision:
Date:
Rationale:

Next Steps

Complete discovery interview (all 46 questions)
Synthesize responses into entity relationship diagram
Draft data model with proposed tables
Create migration plan from current RBAC to platform architecture
Estimate implementation timeline
Review and approve with stakeholders

Appendix A: Entity Hierarchy Reference

Proposed 6-Level Hierarchy

Platform (CODITECT-PLATFORM)
├── Organization (Customer/Subscriber)
│   ├── LegalEntity (Subsidiary with Tax ID, Jurisdiction)
│   │   ├── OperatingUnit (Division/Department/Cost Center)
│   │   │   ├── Department (Cost center)
│   │   │   │   ├── Team
│   │   │   │   │   └── User (with Role per Team)
│   │   │   │   └── Project
│   │   │   └── ...
│   │   └── OperatingUnit
│   │       └── ...
│   └── LegalEntity
│       └── ...
└── Organization
    └── ...

Current 3-Level Hierarchy (Implemented)

Tenant (Organization)
├── Team
│   ├── User (via TeamMembership)
│   └── Project
└── User (via TenantMembership)

Appendix B: Role Hierarchy Reference

Proposed Role Structure

System-Level Roles (Platform):

super_admin
platform_admin
support
sales
finance
readonly

Tenant-Level Role Templates:

owner
admin
manager
member
viewer
guest
custom (configurable)

ADR-009: Multi-Tenant SaaS Architecture
ADR-010: Cloud Workstations Architecture
ADR-053: Cloud Context Sync Architecture
ADR-061: Provisioning Strategies

Approved By: Hal Casteel, CEO/CTO Date: 2026-01-01

Executive Summary​

Table of Contents​

How to Use This Document​

For Discovery Sessions​

For Future Customer Onboarding​

1. Organization Structure​

Q1.1 🏗️ Organization Types Supported​

Q1.2 🏗️ Entity Hierarchy Depth​

Q1.3 🏗️ Legal Entity Requirements​

Q1.4 🔧 Subsidiary Relationships​

Q1.5 🔧 Cross-Entity Visibility​

2. User & Access Management​

Q2.1 🏗️ Authentication Methods​

Q2.2 🏗️ Role Hierarchy - System Level​

Q2.3 🏗️ Role Hierarchy - Tenant Level​

Q2.4 🏗️ Permission Granularity​

Q2.5 🔧 Permission Scope​

Q2.6 🔧 User Lifecycle Management​

3. Multi-Tenant Architecture​

Q3.1 🏗️ Data Isolation Model​

Q3.2 🏗️ Tenant Identification​

Q3.3 🔧 Tenant Customization​

Q3.4 🏗️ Cross-Tenant Operations​

4. Billing & Subscriptions​

Q4.1 💰 Pricing Models​

Q4.2 💰 Billing Frequency​

Q4.3 💰 Usage Metering​

Q4.4 💰 Multi-Currency Support​

Q4.5 💰 Payment Methods​

Q4.6 💰 Revenue Recognition​

5. Accounting Foundation​

Q5.1 🏗️ Chart of Accounts​

Q5.2 🏗️ General Ledger Features​

Q5.3 💰 Accounts Receivable​

Q5.4 💰 Accounts Payable​

Q5.5 🔧 Financial Close​

6. Data Isolation & Compliance​

Q6.1 🏗️ Data Residency​

Q6.2 🏗️ Compliance Frameworks​

Q6.3 🔧 Audit Logging​

Q6.4 🔧 Data Retention​

Q6.5 🔧 Data Export​

7. White-Label & Branding​

Q7.1 🔧 White-Label Scope​

Q7.2 💰 White-Label Revenue Model​

Q7.3 🔧 Partner Administration​

8. Integration & APIs​

Q8.1 🏗️ API Architecture​

Q8.2 🔧 Integration Patterns​

Q8.3 🔧 Authentication for APIs​

Q8.4 🏗️ Rate Limiting​

9. Reporting & Analytics​

Q9.1 🔧 Standard Reports​

Q9.2 🔧 Custom Analytics​

Q9.3 🔧 Data Visualization​

10. Platform Operations​

Q10.1 🏗️ Deployment Model​

Q10.2 🏗️ High Availability​

Q10.3 🔧 Tenant Provisioning​

Q10.4 🔧 Tenant Lifecycle​

Q10.5 🏗️ Disaster Recovery​

Response Summary​

Answered Questions​

Architectural Decisions Log​

Decision 1: [Pending]​

Next Steps​

Appendix A: Entity Hierarchy Reference​

Proposed 6-Level Hierarchy​

Current 3-Level Hierarchy (Implemented)​

Appendix B: Role Hierarchy Reference​

Proposed Role Structure​

Related Documentation​

Executive Summary

Table of Contents

How to Use This Document

For Discovery Sessions

For Future Customer Onboarding

1. Organization Structure

Q1.1 🏗️ Organization Types Supported

Q1.2 🏗️ Entity Hierarchy Depth

Q1.3 🏗️ Legal Entity Requirements

Q1.4 🔧 Subsidiary Relationships

Q1.5 🔧 Cross-Entity Visibility

2. User & Access Management

Q2.1 🏗️ Authentication Methods

Q2.2 🏗️ Role Hierarchy - System Level

Q2.3 🏗️ Role Hierarchy - Tenant Level

Q2.4 🏗️ Permission Granularity

Q2.5 🔧 Permission Scope

Q2.6 🔧 User Lifecycle Management

3. Multi-Tenant Architecture

Q3.1 🏗️ Data Isolation Model

Q3.2 🏗️ Tenant Identification

Q3.3 🔧 Tenant Customization

Q3.4 🏗️ Cross-Tenant Operations

4. Billing & Subscriptions

Q4.1 💰 Pricing Models

Q4.2 💰 Billing Frequency

Q4.3 💰 Usage Metering

Q4.4 💰 Multi-Currency Support

Q4.5 💰 Payment Methods

Q4.6 💰 Revenue Recognition

5. Accounting Foundation

Q5.1 🏗️ Chart of Accounts

Q5.2 🏗️ General Ledger Features

Q5.3 💰 Accounts Receivable

Q5.4 💰 Accounts Payable

Q5.5 🔧 Financial Close

6. Data Isolation & Compliance

Q6.1 🏗️ Data Residency

Q6.2 🏗️ Compliance Frameworks

Q6.3 🔧 Audit Logging

Q6.4 🔧 Data Retention

Q6.5 🔧 Data Export

7. White-Label & Branding

Q7.1 🔧 White-Label Scope

Q7.2 💰 White-Label Revenue Model

Q7.3 🔧 Partner Administration

8. Integration & APIs

Q8.1 🏗️ API Architecture

Q8.2 🔧 Integration Patterns

Q8.3 🔧 Authentication for APIs

Q8.4 🏗️ Rate Limiting

9. Reporting & Analytics

Q9.1 🔧 Standard Reports

Q9.2 🔧 Custom Analytics

Q9.3 🔧 Data Visualization

10. Platform Operations

Q10.1 🏗️ Deployment Model

Q10.2 🏗️ High Availability

Q10.3 🔧 Tenant Provisioning

Q10.4 🔧 Tenant Lifecycle

Q10.5 🏗️ Disaster Recovery

Response Summary

Answered Questions

Architectural Decisions Log

Decision 1: [Pending]

Next Steps

Appendix A: Entity Hierarchy Reference

Proposed 6-Level Hierarchy

Current 3-Level Hierarchy (Implemented)

Appendix B: Role Hierarchy Reference

Proposed Role Structure

Related Documentation