Projects

Highlights

• Every arrow is a handoff, not a rewrite - DAM enriches the issue, a spec-driven development CLI writes the spec and the implementation, SPS deploys and tests the sandbox. No component reimplements another; the factory's job is making the seams hold, not building new infrastructure.
• Spec quality is bounded by context quality - The spec-driven development CLI generates the spec from the Apps Knowledge Base's real architecture, ownership, and risk artifacts for the affected service, not from a blind read of the repo. Better KB, better spec, with no extra manual step.
• Human oversight is a designed gate, not a missing feature - A human validates the running sandbox and, per team policy, a human always merges to dev and to prod. The pipeline never promotes itself; it exists to make code review start from a working, tested candidate instead of a cold diff.
• Scoped narrow on purpose - One persona (developer), one workflow shape (bug fix / small enhancement), explicitly excluding CI/CD promotion, design-driven front-end work, and non-developer personas. Narrow scope is what made the end-to-end chain provable before widening it.
• Honest about what's proven vs. still open - The chain is proven and in use across production pipelines. Business success (cycle-time reduction, manual-effort savings) is explicitly not yet measured; that is what the evaluation and observability phases below are for.

Highlights

• AI-Powered Recognition Categorization - Intelligent categorization engine using Llama 3.3 70B to classify free-form recognition text into 1-3 predefined categories with confidence scoring and reasoning. Prompt engineering includes category-specific keyword hints for accurate classification on ambiguous input. Middleware enriches LLM recommendations with database IDs via dual-layer caching (exact match + case-insensitive fallback).
• Intelligent Entity Grouping via Embeddings + Clustering - Production pipeline converting entity profiles into 4096-dimensional vectors, then running K-means clustering to discover natural groupings without manual labeling. Handles production concerns through multi-layer caching, exponential backoff retries, and deterministic fallback embeddings on API failure. Clusters are interpreted into human-readable labels by extracting trending topics and computing diversity scores. Pipeline design published as IBM Developer article.
• AI-Powered Research Landscape Visualizations - Three complementary views built on the same embedding infrastructure: a word cloud surfacing top recognition categories via NLP, a heatmap matrix showing category distribution across communities to reveal interdisciplinary patterns, and a force-directed community network graph calculating semantic proximity through cosine similarity of cluster embedding vectors.
• People Like You - Similar Researcher Discovery - Researcher discovery surface that ranks colleagues by cosine similarity against the user's recognition profile, returning top-N matches. Accessible from three entry points (dashboard greeting banner, user profile header, and profile sidebar cards) and rendered as both a ranked data table and a force-directed similarity network graph. Transforms recognition data into a collaborative intelligence layer.
• Collaboration Finder - Dedicated platform page presenting up to 20 ranked potential collaborators per user, scored and categorized as cross-cluster or same-cluster matches. Cross-cluster recommendations use a penalized similarity score to surface researchers in adjacent domains - similar enough to collaborate, different enough to add value.
• Research Community Analytics - Automated community discovery grouping 405 researchers into 5 semantic communities using K-means on LLM-generated embeddings. Communities update on a scheduled pipeline with a 3-tier caching strategy (memory - DB - compute) keeping API costs manageable. Provides managers and executives a data-driven view of research activity distribution and emerging interdisciplinary themes.

Highlights

• Materialized views, not prose - A fixed artifact schema per service (routes, datastores, auth model, deployment topology, ownership, risk, and change impact) is extracted surgically from source code, not written by hand. Applied consistently across 61 services and 5 owning teams, it makes portfolio-wide dependency, blast-radius, and auth-model queries possible. Extends Karpathy's wiki efficiency to multi-service portfolios: derivation cost paid once at write time, read cost approaches zero at query time.
• Blast radius and 'do not' rules - Change-impact analysis and risk artifacts surface cross-service dependencies and known failure modes as first-class structured data, not buried in READMEs. Enables questions like 'what breaks if this datastore goes down?' across the entire portfolio in a single query.
• MCP server as the query interface - A 13-tool TypeScript MCP server wraps the knowledge base. Tools like find_services_by_datastore, get_change_impact, and get_agent_brief turn the structured artifacts into a callable API for any AI coding agent. The agent loads a single compact artifact rather than re-reading thousands of lines of source per session.
• repo-intel skill closes the derivation loop - A portable agent skill, written as a plain-markdown procedure designed to run in any agentic coding CLI, runs surgical static analysis on any repository and emits the full artifact set in one pass. A change-detection gate compares the source commit SHA against the last recorded provenance: small changes trigger a micro-extraction that updates only the affected artifacts, while changes to manifests, Dockerfiles, or workflows trigger a full re-extraction. New service added → run the skill → open a PR. The knowledge base stays in sync with code changes, not with whoever last updated a wiki page.
• DORA metrics from a single common substrate - DORA metrics instrumented across 23 repositories using git merge history, the only substrate shared by every team, so no team had to change its tooling. Each metric carries a signal-quality label (proxy, observed, or not instrumented), and time to restore is left un-instrumented rather than inferred. Publishing the gap is deliberate: a metric with no honest signal is worse than no metric.
• Now the grounding layer for an agentic delivery pipeline - This knowledge base is the context source a spec-driven development CLI reads before writing a spec in the Developer Software Factory: spec quality is bounded by context quality, with no extra manual step between the two systems.