Skip to main content

Quality Requirements

This section details the quality goals and the measures taken to satisfy them.

10.1 Quality Goals (Prioritized)​

GoalDescriptionMeasure (Example)
SeparationModular boundaries between core logic and infrastructure.Zero-import of SQLAlchemy logic in the framework-m-core package.
ThroughputHigh-performance handling of financial or event-driven data.Integration with TigerBeetle and NATS JetStream for scale.
IsolationSecure multi-tenant deployment support.Tenant-scoped database queries and stateless JWT/OIDC authentication.
TestabilityAbility to mock any external dependency for testing.Global Protocol-based DI container with override fixtures.

10.2 Security Hardening (Procedures & Policies)​

Framework M follows a Security by Default philosophy, leveraging its hexagonal architecture and metadata-driven core to enforce security at every layer.

10.2.1 Input Validation & Sanitization​

All incoming data is validated using Pydantic models. This ensures that data conforms to the expected schema before it ever reaches the domain logic.

  • Primary Unified DI: We use the dependency-injector container and Pydantic for rigid request/parameter validation across API, CLI, and background worker contexts.
  • SQL Injection Prevention: The DatabaseAdapter uses SQLAlchemy's parameterized queries exclusively. Direct string concatenation in SQL is strictly forbidden.
  • XSS Prevention: As an API-first framework (Headless), Framework M does not render HTML on the server. All data delivered to the frontend is raw JSON, and the frontend (React/Refine) handles escaping.

10.2.2 Authentication & Secret Management​

  • Unified Authentication: Supports pluggable strategies (JWT, OIDC, Session) via the AuthService.
  • JWT Validation: Standard implementation verifies signatures and expiration. Native support for multi-issuer OIDC verification.
  • Secrets Management: Sensitive configuration is managed via the EnvSecretAdapter. Production environments should use secure vaults injected via environment variables.

10.2.3 Authorization (RLS & RBAC)​

Our authorization model is dual-layered:

  1. RBAC (Role-Based Access Control): Verified at the API entry point based on the DocType's permission metadata.
  2. RLS (Row-Level Security): Enforced at the database layer via our SchemaMapper. Every query automatically includes filters for the owner (Tenant/User) context, preventing data leakage between tenants.

10.2.4 Network Security​

  • CORS: Restricted via framework_config.toml or the CORS_ALLOWED_ORIGINS environment variable.
  • Secure Cookies: Enabled for all session-based authentication when running over HTTPS.
  • Enforcement: HTTPS must be enforced at the Nginx/Ingress level for production deployments.

10.3 Observability & AI Readiness​

  • Observability: Metrics and logs are standardized via protocols to enable OpenTelemetry or custom logging providers.
  • AI Readiness: The metadata-driven architecture enables automated RAG (Retrieval-Augmented Generation) corpus generation through the Studio CLI.