Hydar HafizBackend · Cloud · Applied AI

← Back to Featured work

Primary personal case study

AnotherEdenAI

Actively developed

Building a graph-backed AI system that generates deterministic candidates before constrained LLM refinement, structured validation, correction, and fallback.

View public repository on GitHub

Role
Personal project owner and developer
Context
Personal project
Period
December 2025 – Present

Summary

AnotherEdenAI is an actively developed AI-assisted lineup recommendation system for the JRPG Another Eden. It combines typed Neo4j retrieval and deterministic candidate generation with constrained LLM refinement, structured validation, correction, degraded fallback, and a streaming web path.

Context

The project is a personal engineering lab for graph-backed recommendation workflows. The public repository brings source data through an ETL boundary into Neo4j, then uses a web request and roster context to drive recommendation retrieval and analysis. The current work is as much about the reliability boundaries around AI output as it is about the recommendation itself.

Problem

A natural-language recommendation system needs to connect a player’s roster to structured game facts without allowing unconstrained model output to become the final answer. The project establishes roster, boss, build, and legality constraints in typed retrieval and deterministic candidate generation before an LLM refines explanations and rankings.

Pipeline

01 · Architecture · actively developed

How AnotherEdenAI generates a recommendation

An actively developed recommendation system combining typed workflow logic with graph-backed knowledge.
Read this visual as text

A three-part architecture places user input and a knowledge base side by side above a dominant recommendation engine. Query and roster input, plus graph context from source data through ETL into Neo4j, flow downward to candidate preparation, LangGraph analysis, and typed validation or fallback; FastAPI and SSE appear as interface technology.

  1. User input includes a query and roster and is delivered through FastAPI and HTMX/SSE.
  2. Knowledge comes from source data processed through ETL into Neo4j and supplies graph context.
  3. The recommendation engine prepares candidates, coordinates LangGraph analysis, and validates typed output or follows a fallback path; the project remains actively developed.

The public implementation has several explicit boundaries:

  1. ETL models and loaders transform selected source data into an idempotent Neo4j graph.
  2. A typed production retrieval service resolves canonical boss, roster, skill, equipment, and mechanics facts without placing user prose in graph queries.
  3. Deterministic backend logic derives role scores, build packages, and legal lineup candidates before model analysis.
  4. LangGraph passes the candidate bundle to a provider-neutral analyzer for constrained selection and explanation.
  5. Structured validation freezes valid candidates, permits bounded correction of invalid fragments, and retains backend candidates when analyzer refinement is unavailable.
  6. Pydantic formatting and graph-backed legality checks reject malformed, unsupported, or illegal output before rendering.
  7. FastAPI and HTMX/SSE stream workflow progress and return the typed result or a classified failure path.

Engineering decisions

  • Use typed graph retrieval so characters, skills, traits, equipment, bosses, and mechanics remain structured instead of being flattened into one prompt.
  • Generate and validate legal candidates in backend code before the LLM selects or explains a recommendation.
  • Keep analyzer calls bounded through output limits, payload caps, usage tracking, and correction of only invalid fragments.
  • Return labelled degraded backend candidates when provider refinement fails rather than retrying indefinitely or inventing alternatives.
  • Keep provider configuration behind shared adapters so model experiments do not rewrite workflow logic.

Reliability boundary

02 · Safeguards · actively developed

How AnotherEdenAI validates recommendations

Four bounded checks around AnotherEdenAI's AI-assisted recommendation output.
Read this visual as text

Four safeguard cards surround AnotherEdenAI's recommendation boundary: legality rules, retry limits, typed output validation, and a fallback path. The shared outcome is a valid result or a clear failure, not a claim of guaranteed recommendation quality.

  1. Legality rules bound candidates.
  2. Retry limits keep correction within explicit bounds.
  3. Typed output rejects malformed results.
  4. A fallback path returns a clear failure; the project does not claim guaranteed recommendation quality.

The public repository separates typed retrieval, deterministic candidate generation, constrained analysis, and final legality validation. Valid candidates are preserved across a bounded correction round, provider failure activates a labelled degraded backend fallback, and the formatter rejects malformed, illegal, or fact-mismatched output. Token/output limits, usage capture, and prompt-size guards constrain cost exposure without claiming measured savings.

Current status

The repository contains implemented ETL, typed graph retrieval, deterministic candidate generation, analyzer adapters, validation, fallback, streaming, automated tests, and an opt-in evaluation harness. The project remains actively developed; evaluation results, recommendation-quality gates, graph quality, cost controls, and deployment decisions are not complete.

Limitations

This case study does not claim production readiness, an evaluation that is already complete, proven recommendation quality, a live deployment, guaranteed factuality, or measured cost/performance improvement. The public repository’s current opening uses stronger maturity language than this portfolio allows; this narrative follows the approved active-development boundary.