إنتقل إلى المحتوى الرئيسي

🏛️ BayanCore Product Blueprint

Welcome to the BayanCore Product Blueprint, the definitive Documentation-as-Code (DaC) repository outlining the product strategy, compliance, technical architecture, and operations for BayanCore — the Saudi-native business operating system.

BayanCore is designed from the ground up to address the specific operational and regulatory needs of Saudi Arabian enterprises, serving as a modern, compliance-first, and AI-assisted execution environment on top of an ERPNext core.

🎯 Purpose of this Blueprint​

This documentation serves as the master specification and architectural record for the entire BayanCore ecosystem. Rather than housing functional code, this repository dictates what to build, how to align with Saudi regulations, and how to verify correctness.

Core Product Tenets​

  1. Compliance by Design: Seamless, built-in integrations for ZATCA Phase 2, PDPL data residency, GOSI, Wage Protection System (WPS), and Saudi labor law.
  2. Saudi-Native Intelligence: Localized AI assistants operating strictly inside KSA boundaries (OCI Riyadh/Jeddah) handling Saudi dialect and bilingual workflows.
  3. Arabic-First UX: Premium "Liquid Glass" interface designed natively for Right-to-Left (RTL) Arabic interaction, avoiding surface-level LTR translations.
  4. ERPNext Kernel: ERPNext is used as the transactional ledger engine, while BayanCore provides the experience, security, and intelligence middleware on top.

🧭 How to Navigate the Documentation​

The blueprint is structured into logical categories designed for different stakeholders:

docs/
├── product/                 # The "Who", "Why", and strategic business context
├── architecture/            # Bounded contexts, system designs, and data architectures
├── compliance/              # Non-negotiable Saudi regulatory mappings and specs
├── ai/                      # The "Brain" — AI topology, capabilities, MLOps, and NLP
├── ui-design/               # UI design system, UX strategy, and screen inventories
├── engineering/             # Coding standards, Git workflows, CI/CD, and infra specs
├── decisions/               # Architecture Decision Records (ADRs) explaining the "Why"
└── operations/              # Operational runbooks and disaster recovery plans

✍️ Contribution Guide​

This repository follows a Documentation-as-Code (DaC) workflow. To propose changes, additions, or updates:

  1. Branching Strategy: Create a branch named feature/doc-name or fix/doc-link.
  2. Formatting: Use standard GitHub Flavored Markdown (GFM). Always use lowercase, descriptive names for new markdown files.
  3. ADRs: When proposing architectural changes, create an Architecture Decision Record (ADR) using the template in decisions/template and list it in the ADR Index.
  4. Links: Always use relative links to reference other documentation pages to prevent broken routing after Docusaurus build compiles.
  5. Review Process: Submit a Pull Request. All PRs trigger a validation run that checks for broken links and compliance guidelines.

🇸🇦 BayanCore Group — Built for Saudi Vision 2030. All data remains strictly within the Kingdom.