Open-source personal project
ForgeGraph
ForgeGraph shows a difficult system working across product UX, backend workflow, durable data, execution, and AI.
ForgeGraph is an open-source personal project built by GreyX. It makes the full craft inspectable: how a complex system is designed, implemented, debugged, and prepared for deployment.
Commands become durable state before execution. AI and tools run behind governed boundaries; people keep final authority.
Browser -> Next.js -> Django -> Postgres -> Go Engine -> LLMs- 01 · REST + WebSocketOperator consoleNext.js · Creates commands and reflects backend-owned state.
The operator starts the path; the interface never becomes the source of truth.
- 02 · Persist + dispatchControl planeDjango · Validates access, policy, idempotency, and every durable transition.
- PostgreSQL + pgvectorDurable truth, vector memory, and snapshots
- Backend workersRun queue, runtime intents, and projections
- RedisQueue, cache, and transport—never authority
- 03 · Signed gRPC contractExecution planeGo engine · Plans nodes, schedules work, retries safe operations, and fails closed.
- Node + tool adaptersWorkflow nodes, tools, transforms, and outputs
- Model providersOpenAI, Anthropic, Gemini, or local models
- Memory gRPCScoped retrieval through a backend service
- 04 · Callback + intentHuman decisionApproval gate · Pauses consequential work so a person can approve or reject before resume.
- Durable resumeSnapshot, attempt ID, and recovery remain backend-owned
- Durable authority
- Django + PostgreSQL
- Ephemeral execution
- Go engine
- Return path
- Signed callbacks + WebSocket
Problem and constraints
ForgeGraph coordinates approvals, departments, workflows, AI execution, and operational state in one product surface.
Product and approval workflow
A consequential operation stops at a visible decision point instead of hiding approval inside automation.
These captures come from an isolated fictional Northstar Analytics demo. They demonstrate product UI and workflow only; they are not client, revenue, user, or production outcome evidence.
Public system map
Read the public map as three responsibilities. Each boundary has a job; the model is only one part of the system.
- 01Product interfaceBrowser + Next.js
- 02Durable business stateDjango + Postgres
- 03Execution and AIGo Engine + LLMs
Decisions that shaped the system
- 01Product surface
Keep the browser experience clear while the workflow graph remains server-controlled.
- 02Durable state
Use Django and Postgres for durable business state instead of scattering workflow data across tools.
- 03Execution boundary
Run specialized execution through a Go engine where latency and orchestration need tighter control.
- 04AI boundary
Treat LLM calls as one part of the system, not the whole product.
What the public proof shows
- Approved public demo captures show the product surface and the human-approval workflow.
- The public narrative focuses on architecture, workflow decisions, and operational constraints.
- Sensitive names, IDs, emails, keys, and private production details stay out of the case study.
What this proof does not claim
- The public architecture is intentionally simplified.
- Screenshots come from an isolated fictional Northstar Analytics demo, not a client environment.
- Commercial impact is not stated as a metric without verifiable source material.
Sample AI & Product Diagnostic
Inspect the kind of decision artifact GreyX delivers before you pay for one.
Sample Diagnostic deliverable based on the fictional ForgeGraph demonstration—not a customer engagement.
What this demonstrates
You can inspect how GreyX handles ambiguity, system boundaries, and technical trade-offs before starting a paid engagement.
Bring GreyX a difficult system
A Diagnostic turns the constraints, risks, and unknowns into a build decision before a larger commitment.