Wiki

Constitution and Requirements Rationale

Why RGP exists, how the constitution shapes the product, and what makes the governance model different from adjacent tools.

Repository View Source

Constitution and Requirements Rationale

Why RGP Exists

RGP was built to solve a structural problem: most organizations execute important work across a fragmented mix of forms, issue trackers, chat tools, automation systems, CI/CD pipelines, review queues, spreadsheets, agent tools, and ad hoc approval paths. That fragmentation causes four recurring failures:

  • the unit of work is ambiguous
  • ownership and approval are inconsistent
  • automation and agent execution are powerful but poorly governed
  • reporting is retrospective and disconnected from the real execution trail

The constitution answers that by making the request the system-of-record object for work and by placing governance ahead of execution.

The Constitutional Position

The constitution defines RGP as the authoritative control plane for governed work. In practical terms, that means:

  • execution platforms are subordinate to governance
  • runtime systems can execute, but they do not decide authoritative request state
  • reviews, approvals, promotions, and audit history live in one place
  • human and agent collaboration are native, not bolted on
  • analytics must be traceable back to governed execution evidence

This is the core difference between RGP and workflow tools that primarily optimize task completion or developer convenience.

Value Proposition

RGP’s value comes from combining several concerns that are usually split across many products:

1. Governed Work Intake

Requests are created from immutable published template versions with explicit validation, routing, review requirements, expected artifact types, and promotion requirements.

2. Human and Agent Collaboration

Requests can be directly assigned to agent-capable integrations, including persistent multi-turn sessions. The collaboration is treated as a governed part of the request history, not as an external side conversation.

3. Unified Governance

Ownership, checks, reviews, approvals, promotions, and deployment evidence all live on the request lineage.

4. Traceable Analytics

The platform exposes delivery, workflow, agent, cost, performance, and organizational analytics that tie back to governed work records rather than disconnected dashboards.

5. Self-Definition

Templates, workflow bindings, integration bindings, and policy-driven routing make the system evolvable without redefining the core object grammar.

How RGP Is Differentiated

RGP is intentionally not just:

  • a ticketing tool
  • a workflow engine
  • a chat interface for agents
  • a CI/CD orchestrator
  • an analytics dashboard

It is differentiated by the way it composes those capabilities under governance.

Compared to Ticketing Systems

Ticketing systems are good at capture and coordination, but they rarely enforce immutable template versions, promotion governance, or execution traceability across humans and agents.

Compared to Workflow Orchestrators

Workflow engines are good at execution, but they are not usually authoritative for ownership, approval, and audit semantics.

Compared to AI Chat Tools

Agent tools often optimize for interactive productivity. RGP treats that interaction as a governed execution surface that must be reviewable, resumable, and attributable.

Compared to Delivery Analytics Products

Analytics-only tools infer delivery performance from external systems. RGP’s model is to make the governed request and its execution trail the primary source, then build analytics from that source.

Why the Constitution Matters

The constitution is not decorative documentation. It prevents drift in three ways:

  • it defines responsibility boundaries between governance and execution
  • it locks the canonical object model and terminology
  • it forces measurable, auditable behavior instead of hidden system behavior

That is why the repo treats the constitution, requirements, and build packs as authoritative sources rather than aspirational notes.

Requirements Philosophy

The requirements expand the constitution into testable platform obligations:

  • request lifecycle and mutation controls
  • template authoring and immutable publication
  • organization and portfolio administration
  • agent sessions and integrations
  • review, approval, promotion, and deployment controls
  • analytics, performance, and observability
  • testing, security, and traceability

The goal is not merely feature breadth. It is to guarantee that governed work remains:

  • explicit
  • explainable
  • enforceable
  • auditable
  • measurable

Who Benefits

RGP is most valuable where work is high-consequence and cross-functional, for example:

  • regulated operational changes
  • governed AI and automation rollouts
  • multi-team release and approval workflows
  • enterprise delivery organizations that need request-to-execution traceability

First-Version Summary

The first version demonstrates the constitutional thesis in code:

  • governed request intake
  • template workbench
  • organization and portfolio model
  • agent session continuity
  • review and promotion gates
  • analytics and observability
  • comprehensive automated validation

That combination is the product’s actual value proposition: governed work, not just executed work.