Poge Documentation

Poge is an AI-native Software Development Lifecycle (SDLC) orchestration platform. It provides a unified workspace where product managers, designers, engineers, and QA collaborate — alongside specialized AI agents — to transform business intent into high-quality, maintainable software.

Rather than accelerating code generation in isolation, Poge focuses on the decisions that precede code: what to build, why, and how it fits into a larger system. Every requirement, architectural decision, and implementation detail is connected through a shared Knowledge Graph, ensuring that context is preserved and propagated across the entire development lifecycle.

Design Philosophy

Poge is built around three principles:

• Context over code. The bottleneck in software development is rarely writing code — it is maintaining shared understanding across teams and time. Poge treats context as a first-class artifact.
• Multiplayer by default. Unlike single-player AI coding tools, Poge is designed for asynchronous, multi-role collaboration. Every decision is explicit, reviewable, and traceable.
• Rigor at every stage. Specialized AI agents enforce clarity, surface gaps, and flag inconsistencies — not just during implementation, but from requirements through validation.

Architecture Overview

Poge is organized into four sequential modules — Refinery, Foundry, Planner, and Validator — each corresponding to a distinct phase of the SDLC. Modules share state through the Knowledge Graph, which maintains live relationships between requirements, specifications, and implementation artifacts.

Quickstart

This guide walks through the minimum steps to create a project and produce your first Work Order from a product requirement.

Step 1 — Create a Project

A Project is the top-level container in Poge. All modules, agents, and artifacts belong to a project.

POST /v1/projects
{
  "name": "My First Project",
  "description": "Optional project description"
}

Step 2 — Define a Requirement in Refinery

Open the Refinery module and create a new PRD. You can start from a blank document or provide a seed prompt. The Refinery agent will ask clarifying questions to eliminate ambiguity.

POST /v1/projects/{project_id}/refinery/documents
{
  "title": "User Authentication",
  "seed": "Users should be able to sign in with email and password."
}

Step 3 — Generate a Blueprint in Foundry

Once a PRD is marked as complete, pass it to Foundry to generate a structured Blueprint. Foundry decomposes the requirement into a hierarchy of Feature Nodes.

POST /v1/projects/{project_id}/foundry/blueprints
{
  "source_document_id": "{prd_id}"
}

Step 4 — Generate Work Orders in Planner

Planner reads the Blueprint and your existing codebase context to produce Work Orders — discrete, implementation-ready task definitions.

POST /v1/projects/{project_id}/planner/work-orders
{
  "blueprint_id": "{blueprint_id}",
  "codebase_context_id": "{context_id}"
}

Knowledge Graph

The Knowledge Graph is the central data structure of Poge. It maintains typed, directional relationships between all artifacts produced across modules — requirements, blueprints, feature nodes, work orders, and feedback.

When an upstream artifact changes — for example, a requirement is updated in Refinery — the Knowledge Graph propagates impact analysis downstream, surfacing which blueprints, feature nodes, and work orders may need to be revised. This propagation is the mechanism by which Poge preserves alignment across the full development lifecycle.

Node Types

Edge Semantics

Edges in the Knowledge Graph carry semantic meaning. Common edge types include IMPLEMENTS, DERIVES_FROM, CONFLICTS_WITH, and SUPERSEDES. Agents use edge traversal to reason about impact and consistency.

Feature Node

A Feature Node is the atomic unit of a Blueprint. It represents a discrete piece of functionality — scoped narrowly enough to be implementable by a single Work Order, but rich enough to carry its own context, constraints, and acceptance criteria.

Feature Nodes are organized in a hierarchy. A parent node describes a capability; child nodes describe the sub-features required to deliver it. This hierarchy is generated by the Foundry agent and can be edited by the team before Planner consumes it.

Feature Node Schema

{
  "id": "fn_01j...",
  "title": "Email/password sign-in",
  "description": "Allow users to authenticate using verified email and bcrypt-hashed password.",
  "acceptance_criteria": [
    "Returns 401 on invalid credentials",
    "Rate-limited to 5 attempts per minute per IP",
    "Issues a signed JWT on success"
  ],
  "constraints": ["Must comply with OWASP authentication guidelines"],
  "parent_id": "fn_00j...",
  "status": "draft"
}

Work Order

A Work Order is an implementation task generated by the Planner module. It bridges the gap between a Feature Node (what to build) and the codebase (how to build it), by including an implementation plan grounded in the current state of the repository.

Work Order Schema

{
  "id": "wo_02k...",
  "feature_node_id": "fn_01j...",
  "title": "Implement email/password authentication endpoint",
  "implementation_plan": {
    "files_to_create": ["src/auth/handlers/signin.ts"],
    "files_to_modify": ["src/auth/router.ts", "src/middleware/rateLimit.ts"],
    "dependencies": ["jsonwebtoken", "bcrypt"],
    "notes": "Extend existing middleware chain. Do not introduce a new router."
  },
  "estimated_complexity": "medium",
  "status": "pending"
}

AI Agents

Poge deploys specialized AI agents at each module boundary. Unlike general-purpose coding assistants, Poge agents are scoped to a specific role and operate on structured inputs from the Knowledge Graph.

All agents share read access to the Knowledge Graph and write access only within their designated module scope. Cross-module writes are mediated by the graph propagation layer.

Refinery

Refinery is the requirements management module. Its primary output is a Product Requirements Document (PRD) — a structured, AI-assisted document that captures the goals, constraints, and acceptance criteria of a product or feature.

The Clarifier agent actively participates in document authoring, asking questions, surfacing implicit assumptions, and flagging requirements that are too vague to be implemented without further specification.

Key Operations

• Create and version PRD documents
• Extract discrete Requirement nodes into the Knowledge Graph
• Mark requirements as draft, in-review, or approved
• Detect conflicts between requirements within the same project

Output

An approved PRD in Refinery becomes the source input for Foundry's Blueprint generation. The relationship is recorded in the Knowledge Graph as a DERIVES_FROM edge.

Foundry

Foundry converts an approved PRD into a Blueprint — a structured, hierarchical decomposition of the product into Feature Nodes. Each Feature Node carries its own description, acceptance criteria, and constraints.

The Architect agent performs this decomposition, applying architectural heuristics to suggest appropriate granularity and surface design tradeoffs that the team should review before implementation begins.

Key Operations

• Generate a Feature Node hierarchy from a PRD
• Edit, merge, or split Feature Nodes
• Attach architectural decisions with rationale
• Mark the Blueprint as ready for Planner consumption

Output

A finalized Blueprint is the input to Planner. Each Feature Node in the Blueprint will correspond to one or more Work Orders.

Planner

Planner bridges specification and implementation. Given a Blueprint and a codebase context, it generates Work Orders — implementation task definitions that include file-level plans, dependency notes, and complexity estimates.

Unlike tickets in a traditional issue tracker, Work Orders are grounded in the actual state of the repository at the time of generation. This allows the Planner agent to avoid suggesting changes that conflict with existing patterns or introduce unnecessary dependencies.

Key Operations

• Ingest codebase context via GitHub OAuth (read-only)
• Generate Work Orders from Feature Nodes
• Assign Work Orders to team members or AI coding agents
• Track Work Order status: pending, in-progress, done

Validator

Validator closes the feedback loop. It ingests user feedback from external sources — support tickets, app store reviews, user interviews, usage analytics — classifies each signal, and maps it back to the Feature Nodes it implicates.

This creates a direct pipeline from real-world usage back into the development process, allowing teams to prioritize iterations based on actual impact rather than assumption.

Key Operations

• Ingest feedback via webhook, CSV import, or manual entry
• Classify signals by type: bug, feature-request, usability, performance
• Map feedback to affected Feature Nodes in the Knowledge Graph
• Generate prioritized iteration proposals for Refinery

Feedback Signal Schema

{
  "id": "fs_04m...",
  "source": "app-store-review",
  "raw_text": "The login screen freezes when I tap the button twice quickly.",
  "classification": "bug",
  "severity": "high",
  "mapped_feature_nodes": ["fn_01j..."],
  "created_at": "2026-03-14T09:22:00Z"
}

API Overview

The Poge API is a REST API. All requests are made over HTTPS. Request and response bodies use JSON. The base URL for all API endpoints is:

https://api.poge.me/v1

Authentication

All API requests require a Bearer token in the Authorization header. Tokens are issued per workspace and scoped to a set of permissions.

Authorization: Bearer poge_sk_live_...

Token Types

Endpoints

The following table summarizes the available endpoints in the Alpha release. Detailed request/response schemas are available on request.

For full schema documentation and sandbox access, contact us.

Security Model

Poge is designed with the assumption that it will handle sensitive product information, proprietary codebase context, and internal decision records. Security is not a feature layer — it is a foundational constraint of the system.

Poge is pursuing ISO 27001 (ISMS) certification. The security controls described in this section reflect the requirements of that standard as applied to the Poge platform.

Access Control

Access in Poge is governed by a role-based access control (RBAC) model scoped to the workspace and project level.

Workspace Roles

Codebase Access

When connecting a GitHub repository for codebase context, Poge requests read-only OAuth scope. Poge never writes to, force-pushes, or modifies repository contents. The access token is stored encrypted at rest and is never exposed via the API.

Data Handling

Encryption

All data is encrypted in transit using TLS 1.3. Data at rest is encrypted using AES-256. Encryption keys are managed using envelope encryption with per-workspace key isolation.

AI Model Data Usage

Poge uses large language models (LLMs) to power its AI agents. The following policies apply to data sent to model providers:

• Customer data is never used to train or fine-tune external models.
• Prompts and completions are not retained by model providers beyond the duration of the API request.
• Model providers are selected and contracted under data processing agreements (DPAs) compatible with GDPR and applicable Japanese privacy law.

Data Residency

In the Alpha release, all data is stored in the Asia Pacific (Tokyo) region. Regional isolation and data export options are planned for a future release.

Retention

Project data is retained for the duration of the subscription. Upon account termination, all workspace data is deleted within 30 days. Deletion logs are retained for audit purposes for 90 days.

Changelog

All notable changes to Poge are documented here. Poge follows a date-based versioning scheme during the Alpha period. Breaking changes are marked explicitly.