SPHOENIX / TPLLMAI TECHNICAL PROGRAM MANAGEMENT
TPLLM DASHBOARD SHIPPED

The work moves.
The context
should too.

I built TPLLM to carry the program context that teams keep reconstructing in meetings. It connects what was said, what changed in code, who owns the next step, and what the evidence actually supports.

Ontology and relational intelligence connect the evidence. Two intelligence lanes turn that context into bounded judgments and structured reasoning, with TPLLM policy governing what happens next.

Open dashboard GitHub
Explore ontology & architecture Hosted dashboard · Vercel sign-in may be required
EXPLORE LAYER BY LAYER

A PROGRAM, OPENED UP

One program.
A connected world.

A conversation upstairs. A change in the code. A decision waiting for context. Scroll to open the model and follow what connects them.

A cutaway miniature building showing connected program layers
OPENING THE PROGRAM MODELSCROLL TO OPEN

THE QUESTION BEHIND THE SYSTEM

What if the next meeting
was already a brief?

Watch repeated status questions accumulate meeting time. Then explore the intended alternative: reusable context, with people brought in for the decision.

ILLUSTRATIVE SCENARIO

Adjustable assumptions. These clocks are an animation, not measured TPLLM savings or processing speed.

REBUILD THE CONTEXTREPEAT 01
“Where are we on the launch?”
00:00MEETING MINUTES

The same information is reconstructed in each status meeting.

MAINTAIN THE CONTEXTTPLLM
Read the existing AI notesSources attached → brief → human decision
00:00ASSUMED HUMAN REVIEW MINUTES

Context travels forward. The scenario reserves one focused review.

00:00LESS MEETING TIME
IN THIS SCENARIO
Change the scenario assumptions +

Calculation: meetings × minutes per meeting − one focused review. This compares meeting duration, excludes preparation and operating costs, and assumes the repeated status meetings can be replaced. It is not a causal estimate or a measured outcome.

THE STRUCTURE BEHIND THE SCENARIO

Context is connected.
Intelligence should be too.

Ontology and relational intelligence give both lanes their context. Follow a source through the shared model, the question, the response, and the controls that govern what can happen next.

ONTOLOGY + RELATIONAL INTELLIGENCE

Facts become context
through their connections.

The ontology defines what things are and how they relate. Relational intelligence follows those supported relationships to understand who owns the work, what it affects, and which evidence belongs in the next question.

ILLUSTRATIVE PROGRAM · SELECT AN ENTITY
PROJECT
Visual-search launch

The project brings the commitment, engineering change and KPI context together. Relational intelligence follows these links to frame a useful question.

Trace into both intelligence lanes
  • Update package belongs to Visual-search launchProject scope
  • PR #42 changes Visual-search launchPR project link
  • Visual-search launch measured by Request-match KPIProgram KPI definition

THE COMPLETE TPLLM ARCHITECTURE

One foundation. Two intelligence lanes.
Explicit control over action.

Select any block to highlight its upstream context and downstream dependencies.

CONTEXT IN FOCUS · Visual-search launch

DECISION QUESTION / JEVWhich supported risk family fits?

REASONING QUESTION / STRUCTURED OUTPUTSWhich causes interact across this launch, and what remains unknown?

INSIDE THE SYSTEM03 / 17

Ontology

The ontology supplies the shared vocabulary: projects, people, tasks, dependencies, observations and decisions. Relational intelligence uses those supported connections to understand how a change travels through the program.

TAKES IN
Entities and explicit, source-backed relationships
PRODUCES
Context about ownership, dependencies and affected work
MAKE IT CONCRETE

Note → commitment → owner. PR → project → KPI. Follow the typed links in the graph above.

FOLLOW THE CONTEXT

Architecture and governance map. In the current Phase 2 implementation, the two lanes produce journaled artifacts for Intelligence Review. The arrows describe relationships and governance order, not automatic execution. Existing Phase 1 insight candidates use validate_insight(); TPLLM policy and separate authority controls govern external action.

BUILT TO KEEP THE EVIDENCE CLOSE

Jev judges. Reasoning synthesizes.
TPLLM governs.

Explore the source

IMPLEMENTATION & EVIDENCE

An answer is useful when
you can see what supports it.

TPLLM is an AI technical program manager built around evidence, a shared model of the program, and explicit authority. The dashboard brings that system into a working interface. The newer intelligence layer gives bounded judgment and deeper reasoning distinct jobs.

CURRENT SCOPEWHAT THAT MEANS
Shipped dashboardHosted on Vercel, with views for meetings, engineering, KPIs, relationships, tasks and decisions. Access protection and source permissions remain separate from deployment.
Connected contextCollectors support authorized Google Calendar, Slack, Zoom AI summaries and GitHub records. Missing summaries and collection limits remain visible.
Governed actionInternal Slack project-status updates can execute under exact standing delegation, with expiry, revocation and duplicate suppression. Other external action classes need scoped adapters.
Intelligence integrationJev and Structured Outputs are implemented in the public codebase. Deployment of the newest reasoning lane has not been verified.
Evaluation still aheadMock and fixture results validate infrastructure. Real-provider quality, calibration, workflow benefit and meeting-time savings have not been established by the reviewed evidence.
Source repository Product workflows Dual-lane architecture