RFC-0012: XaaS Resource Policy and Active Metering

• Status: Implemented
• Author(s): @revant.one
• Created: 2026-04-19
• Updated: 2026-04-21

Summary

This RFC establishes Framework M as a foundation for building XaaS (X-as-a-Service) platforms. It moves beyond simple "SaaS multi-tenancy" to a Resource Agnostic architecture that unifies Identity, Entitlement, and Metering. This enables the framework to power anything from AIaaS (tokens) and IaaS (compute) to traditional business services, ensuring that the "Platform" logic scales to AWS/GCP levels without polluting the "Service" logic.

Motivation

Traditional web frameworks treat multi-tenancy as a shallow "User-to-Org" mapping. For a true resource provider (XaaS), this is insufficient:

• Resource Universality: A "Resource" can be a database row, an AI token, a vCore-second, or a billable event.
• Hyperscale Policy: Authorization decisions must account for dynamic hierarchies and real-time usage (quotas) at scale.
• Accounting vs. Logic: The service executing the work (Data Plane) should not be responsible for the accounting of that work (Control Plane).

The goal is to provide a "Zero-Cliff" bridge for building platforms that are Metrically Aware and Policy Enforced by default.

Detailed Design

1. Resource Evaluator (PermissionProtocol)

The existing PermissionProtocol acts as the universal Policy Decision Point (PDP). It is resource-blind and evaluates policies based on the context of the tenant_id.

• Entitlements: "Does Tenant X have the 'High Performance' tier for Resource Y?"
• Quotas: "Is the concurrent execution count within the allocated limit?"
• Hierarchical Context: Root-level policies that cascade to projects and sub-tenants using TenantContext.lineage.

By using adapters like SpiceDB, Cedar, or Lagos, the framework can enforce complex ReBAC/ABAC policies that scale to millions of resources.

The service provides functionality; the MeteringProtocol provides the audit trail for accounting and the facts for quota enforcement.

class UsageEvent(BaseModel):
    tenant_id: str
    feature_name: str
    quantity: float
    timestamp: datetime
    metadata: dict[str, Any] | None = None

class MeteringProtocol(Protocol):
    """Protocol for recording and querying resource usage events."""

    async def record_usage(self, event: UsageEvent) -> None:
        """Record usage fact. Decoupled from transactional database performance."""
        ...

    async def get_usage(
        self,
        tenant_id: str,
        feature_name: str,
        start_time: datetime,
        end_time: datetime,
    ) -> float:
        """Get aggregated usage for quota enforcement and billing."""
        ...

3. Hierarchical Resource Trees

Tenancy is not flat; it is a tree of resource ownership.

• Root: The Billing Entity.
• Children: Projects, Departments, or Environments.
• Lineage: The TenantContext carries a lineage: list[str] which the PermissionProtocol resolver uses to climb the tree and find the "Winning" policy (e.g., a "Parent" quota capping all "Child" usage).

The XaaS Maturity Model (Zero-Cliff)

Component	Internal / Indie	Production (Postgres)	Hyperscale (Lagos)
Identity	Local / LDAP / SSO	OIDC / Zitadel	Global Control Plane
Policy	Simple RBAC	OPA / ABAC	SpiceDB / Lagos / Cedar
Metering	No-Op / Audit Log	Postgres DocType + RLS	ClickHouse / Lagos Sink
Resource	Business Objects	API Actions	Elastic Resources

[!NOTE] The Standard Pack implementation utilizes the Postgres DocType + RLS strategy for metering, managed via DocType-backed schemas. This ensures transactional consistency for the audit trail while maintaining the framework's "Zero-Cliff" scaling. Lagos and ClickHouse integrations are showcased in the How-to guides as patterns for external "Hyperscale" sinks.

Key Concepts

The "Service" is a Managed Resource

In this model, the Framework-M application acts as a "Service Provider" (Data Plane). It trusts the Control Plane (Onboarding/Billing/Management) to populate the permissions and interpret the metering events.

Platform-level Accountability

By externalizing Onboarding and using a resource-agnostic Metering Protocol, the application becomes "Accountable." It provides the metrics needed for real-time billing, usage-based scaling, and automated tiering.

The Tenancy Spectrum

This architecture is designed to support a spectrum of residency and trust within a single deployment. By adjusting the Policy and Metering weights at the adapter level, a platform can serve mixed-mode tenants:

Tenant Type	Trust Level	Metering Behavior	Enforcement
Internal	High	No-Op / Invisible	Zero-Cap (Infinite)
Arm's Length	Medium	Audit Log / Event	Soft-Cap (Chargeback)
External	Low	Active Metering	Hard-Cap (Billing)

Unified Developer Experience

The developer code remains identical across the spectrum. The service logic simply "Emits" and "Checks." The Control Plane determines the outcome based on the tenant's classification. This allows an enterprise to use the same Framework M application for internal operations, cross-department chargebacks, and external commercial XaaS.

Implementation Plan

1. Core Interface: Define MeteringProtocol and update TenantContext.
2. Standard Metering: Finalize UsageMeterService and PostgresMeteringAdapter (Standard Pack defaults).
3. Active Enforcement: Implement QuotaPolicyHandler for hierarchical quota checks.
4. Hyperscale Guidance: Create Diátaxis How-to guides for bridging events to external hyperscale sinks like Lagos or ClickHouse.