02. Architecture and Inner-Source

To maintain high operating leverage, Zeta implements strict architectural boundaries that protect our core platform codebases from bespoke custom drift. This chapter details our inner-source loop and platform protection rules.

1. Protecting the Core: Zero Direct Platform Intakes

Under Org 8.0, the core platform engineering teams (the Product Line squads) are completely insulated from direct client-project delivery pressures:

• The No-Intake Rule: There is no concept of a client-project "intake ticket" sent to a core platform engineering team. Core platform developers do not write customer-specific custom features or integration code.
• The Configuration Standard: All client-facing customizations must be executed as declarative configurations, parameter settings, or sandboxed extensions built on the Engagement Win Team (EWT) release squads inside the Engagement Factory.
• Preventing Code Forking: Standard platforms maintain strict binary write-access control. No delivery squad can directly modify core repository code or create custom forks of platform binaries for client-specific SOWs.

2. The Inner-Source Contribution Loop

When a client engagement identifies a genuine gap in standard platform capabilities that cannot be resolved through configuration, the team must follow the formal Inner-Source Contribution Loop:

 1. GAP IDENTIFICATION ──────► Delivery Squad identifies missing capability.
                                     │
                                     ▼
 2. PAC REVIEW ──────────────► Platform Architecture Council (PAC) validates gap.
                                - If generic: Authorizes inner-source PR path.
                                - If bespoke: Rejects PR path; directs configuration.
                                     │
                                     ▼
 3. SQUAD DEVELOPMENT ───────► Delivery Squad writes the platform-generic patch.
                                     │
                                     ▼
 4. MAINTAINER REVIEW ───────► Core Platform Maintainers review code against standards.
                                - SLA: Maintainers must review within 48 hours.
                                     │
                                     ▼
 5. MERGE & UPGRADE ─────────► Code merged to single core; available to all customers.

2.1 The Role of Platform Maintainers

Each core platform repository is guarded by a dedicated group of Platform Maintainers housed within the Product Line units:

• Quality Gatekeepers: Maintainers do not write feature code; they review, test, and validate inner-source contributions against strict performance, security, and extensibility standards.
• Review SLAs: To prevent delivery bottlenecks, Platform Maintainers operate under a strict 48-hour SLA to review, provide feedback, or merge submitted inner-source Pull Requests (PRs).

By enforcing this disciplined inner-source loop, Zeta ensures that custom client-project funding is successfully capitalized into reusable, compounding core platform assets that benefit all multi-tenant customers.