Executive summary
Business context
An R&D architecture for a bilingual community companion that keeps authorization, moderation, and audit events deterministic.
Responsibility: Product and solution architecture
Problem
What had to change
Community automation can become unsafe or opaque when conversational AI is allowed to make permission, identity, or moderation decisions.
Constraints
The architecture inputs
- Narrative relationships must never grant platform authority.
- AI must not autonomously punish members.
- The first release must stay small, auditable, bilingual, and reversible.
- Discord permissions and data access must follow least privilege.
- Define the product boundary and staged delivery roadmap.
- Separate deterministic authorization from bounded AI orchestration.
- Choose transport paths based on actual event and interaction requirements.
Architecture
From existing state to target state
Existing state
A broad companion vision combined commands, recommendations, relationships, safety, events, research, and conversational AI in one roadmap.
Target state
A command-first foundation exposes approved information through deterministic handlers. Later AI capabilities use a bounded orchestrator with strict tools and human approval for consequential actions.
Decision record
Alternatives, decisions, and trade-offs
Alternatives considered
- Launch recommendations, relationship systems, and conversational AI together - rejected as too broad for a safe MVP.
- Use a passive event connection for every feature - rejected because explicit commands can use HTTP interactions with less privilege.
Key decisions
- Start with five information commands and approved bilingual content.
- Use HTTP interactions for explicit commands; add passive event connectivity only when a later feature requires it.
- Keep authorization, validation, moderation, state changes, and audit events deterministic.
Trade-offs
- The narrow first release demonstrates reliability before personalization depth.
- Human approval adds friction to consequential actions in exchange for safety and accountability.
Delivery approach
How the design moved toward release
- Release information commands first.
- Add one community workflow only after health checks, logging, and rollback are proven.
- Introduce opt-in AI features behind explicit tools and data controls.
Production readiness
Operations and security
Operational considerations
- Health checks, structured logs, auditability, least privilege, and rollback are release requirements.
- Rate-limit responses are honored rather than retried blindly.
Security considerations
- Credentials remain outside source control.
- Permissions are independent from personal or narrative relationships.
- Member data is opt-in and erasable.
Recovery
Rollback and failure strategy
- Disable bounded features without taking down deterministic information commands.
- Keep moderation and permission changes behind human authorization.
- Roll back to the last known command set when a release fails.
Outcome
What can be claimed
The architecture and MVP boundary are defined and validated as R&D. No production adoption, safety, or performance outcome is claimed.
Lessons
What transfers to the next system
- Product scope is a safety control.
- Deterministic boundaries make AI behavior easier to reason about and audit.
- Transport choices should follow event requirements, not framework preference.