Victor Cuellar
ENES
All selected work

AxiomEngine

Study-plan generation with graph-derived prerequisites and deterministic output ordering.

A prerequisite path becomes an ordered plan.
Interface
HTTP API
Language
Go
Typed model calls
BAML
Model provider
AWS Bedrock
View repository

Study plan builder

Prerequisite map

Full prerequisite chains, in study order.

Variables
Objects
Classes
Inheritance
Polymorphism
Study plan
  1. 1
    Variables—Illustrative resources: diagramIllustrative resources: video
  2. 2
    ObjectsVariablesIllustrative resources: diagramIllustrative resources: video
  3. 3
    ClassesVariables › ObjectsIllustrative resources: diagramIllustrative resources: video
  4. 4
    InheritanceVariables › Objects › ClassesIllustrative resources: diagramIllustrative resources: video
  5. 5
    PolymorphismVariables › Objects › Classes › InheritanceIllustrative resources: diagramIllustrative resources: video
subgraph_tuples
5
topics_processed
1
items_generated
5
items_after_validation
5

Illustrative simulation with fixed example data. No live model or service is called.

Figure 1. An illustrative planning interface for the HTTP API, not an interface shipped by the repository.

Problem

A study plan needs a prerequisite order, not just a list of topics. AxiomEngine combines declared assessment deficits with a curriculum knowledge graph: concepts connected by typed relationships. Generated study items use a declared VARK preference—visual, auditory, read/write or kinesthetic—as an input, not evidence of educational effectiveness.

From scattered topics to an order.

How it works

The service validates the request, extracts nearby graph context and plans for each failed topic in parallel. It then merges results and uses the graph again to replace prerequisite chains and assign priorities.

Prerequisites before the next concept.
Service flow
RequestParallelValidate requestExtract subgraphConcept graphTopic 1Topic nMergeValidate againstthe graphStudy planValidate requestParallel: shared circuit breakerValidaterequestExtractsubgraphConcept graphTopic 1Topic nMergeValidateagainstthe graphStudy plan

Return ordered items; resources and explanations remain unvalidated.

All components

  • Validate request

    Validate identifiers, declared preference and known failed topics before any model call.

  • Extract subgraph

    Read a depth-2 neighborhood and graph-derived prerequisite order.

  • Concept graph

    The in-memory graph supplies depends_on and is_a relationships to extraction and validation.

  • Topic 1

    Generate one topic plan with a timeout and shared circuit breaker.

  • Topic n

    Topic calls run in parallel and write to their assigned slots.

  • Merge

    De-duplicate items in request-topic order; a topic failure fails the request.

  • Validate against the graph

    Drop unknown topics, replace prerequisite chains and assign consecutive priorities.

  • Study plan

    Return ordered items; resources and explanations remain unvalidated.

Figure 2. Parallel topic calls share a circuit breaker; extraction and output validation read the same concept graph.

Validate the request

The service checks identifiers, VARK preference and failed topics. It trims and de-duplicates topics, then rejects unknown concepts before any model call.

Validate before planning

  1. Request
  2. Checked
  3. Accepted

More detail

Requestexample-learner
  • VARK: visual, auditory, read/write, kinesthetic
  • Safe IDs: letters, digits, dot, underscore, colon or hyphen; up to 128 characters
  • Trim spaces and remove duplicate topics
  • 1–10 unique topics with the default limit
  • Every topic exists in the graph
Accepted400 / 422No model call

Learning-style, identifier and topic checks either accept the request or stop it with 400/422 before any model call.

Figure 3. Invalid input stops before planning begins.

Extract nearby graph context

A breadth-first traversal follows relationships in both directions. Plan generation uses depth two and de-duplicates the resulting tuples.

Two hops of graph context

  1. Depth 0
  2. Depth 1
  3. Depth 2

More detail

Depth 0

Polymorphism

Depth 1

Inheritance / Generics / Design Patterns

Depth 2

Classes / Interfaces

Breadth-first search follows both directions for two hops; encountered tuples become the planning context.

Figure 4. Depth-two graph context surrounds the requested topics.

Build prerequisite chains

A depth-first traversal orders dependencies before the target concept. Each topic call receives this graph-derived chain together with local graph context.

Deepest prerequisites first

  1. Variables
  2. Objects
  3. Classes
  4. Inheritance

More detail

DFS post-order

Variables
Objects
Classes
Inheritance

Then the target: Polymorphism

Depth-first post-order puts four prerequisites before Polymorphism, excluding the target from its own chain.

Figure 5. Graph traversal orders prerequisites before their dependent topic.

Plan for topics in parallel

Each failed topic gets one model call with a timeout and a shared circuit breaker. Results are written to assigned slots rather than completion order.

Parallel work, shared protection

  1. Request
  2. Design Patterns
  3. Merge Sort
  4. Shared circuit breaker
  5. Stopped

More detail

Request
Design Patterns
Per-topic deadline
Merge Sort
Per-topic deadline
Shared circuit breakerOpens after 3 consecutive failures
Any topic failsStopped

One call per failed topic runs in parallel under a per-topic deadline and shared breaker; any failure stops the whole request.

Figure 6. Independent topic calls retain their assigned result slots.

Merge in request order

The service reads slots in request-topic order and keeps the first item for each topic. Faster calls cannot move their items ahead merely by finishing first.

Keep request order, drop repeats

  1. Finish order: 2
  2. Finish order: 1
  3. Merge order

More detail

Finish order: 2 → 1

1ClassesObjects
2ClassesFunctions

Merge order: 1 → 2

  1. 1Classes
  2. 2Objects
  3. 3Functions
First kept

Results stay in request slots, so merging follows request order and keeps the first occurrence of each topic.

Figure 7. Merging follows the request and removes repeated topics.

Validate the plan against the graph

Unknown output topics are dropped. Graph-derived chains replace model chains; a stable sort then assigns consecutive priorities.

Ground the draft in the graph

  1. Model draft
  2. Graph
  3. Plan

More detail

Model draft

1PolymorphismArrays

MonadsUnknown topic

Generated: 6
Graph

Plan

  1. 1Variables
  2. 2Objects
  3. 3Classes
  4. 4Inheritance
  5. 5Polymorphism
After validation: 5

Chain replaced: Variables → Objects → Classes → Inheritance

Unknown topics are dropped, supplied chains are replaced, and first-appearance ranks become contiguous priorities.

Figure 8. The graph determines retained topics, prerequisite chains and priorities.

Details

Concept graph

The graph connects concepts through dependency and category relationships. Prerequisite chains use a depth-first traversal; local context uses a breadth-first traversal in both directions.

Explore the curriculum

Groups are for reading; the service graph has no domains.

Object-oriented programming

Data structures

Algorithms

The study order is also available as text below.

Study order: 1 Variables → 2 Objects → 3 Classes → 4 Inheritance → 5 Polymorphism

The graph sets this order: both depends_on and is_a are traversed before the dependent concept.

Illustrative simulation with fixed example data. No live model or service is called.

Figure 9. Explore prerequisite relationships and the context around an assessment topic.

Parallel planning

Each topic call writes to an assigned result slot. Merging follows request-topic order, so a faster response cannot gain precedence simply by finishing first. Any failed call fails the whole request.

Parallel topic planning

Results stay in their request slots.
Slot 1Design Patterns

Ready

Design Patterns / Interfaces / Abstract Classes / Polymorphism / Inheritance / Classes / Objects / Variables

Slot 2Merge Sort

Ready

Merge Sort / Recursion / Functions

Merged slots
  1. 1Design Patterns8
  2. 2Merge Sort3
Circuit breaker: Closed

Three consecutive failures open the circuit; any topic failure fails the whole request, rather than returning a partial plan.

Fixed presentation sequence; not measured service timings.

Illustrative simulation with fixed example data. No live model or service is called.

Figure 10. Topic calls finish independently, then merge in request order.

Validation against the graph

Unknown output topics are dropped. The graph replaces the draft’s prerequisite chains, determines topic ranks and assigns consecutive priorities.

Ground the plan in the graph

Draft from the model

A fixed illustrative draft, not a live response.

  1. 1
    Polymorphism
    ArraysVariables → Objects → Classes → Inheritance
  2. 2
    Inheritance
  3. 3
    Classes
  4. 4
    Objects
  5. 5
    Variables
  6. 1
    MonadsDropped — Not in the curriculum

Validated plan

  1. 1
    Variables—Illustrative resources: diagramIllustrative resources: video
  2. 2
    ObjectsVariablesIllustrative resources: diagramIllustrative resources: video
  3. 3
    ClassesVariables › ObjectsIllustrative resources: diagramIllustrative resources: video
  4. 4
    InheritanceVariables › Objects › ClassesIllustrative resources: diagramIllustrative resources: video
  5. 5
    PolymorphismVariables › Objects › Classes › InheritanceIllustrative resources: diagramIllustrative resources: video

The graph checks topics, chains and ordering — not resource text, completeness or educational quality.

subgraph_tuples
5
topics_processed
1
items_generated
6
items_after_validation
5

Illustrative simulation with fixed example data. No live model or service is called.

Figure 11. The graph corrects plan structure; explanations and resources remain unvalidated.

Decisions and tradeoffs

Let the graph own prerequisites

The model’s prerequisite chains are replaced, not merely checked. Priorities follow graph-derived ranks after a stable sort.

The graph is the ordering authority

  1. Model draft
  2. Graph
  3. Plan

More detail

Model draft
Explanations and resourcesDraft ordering is not trusted
Graph
Prerequisite chainPriorities
PlanAuthoritative structure

Graph checks override the draft’s topics, chains and priorities; resource wording remains model-produced and unchecked.

Figure 12. Graph structure overrides the generated prerequisite order.

Separate concurrency from ordering

Indexed slots preserve request order despite different completion times. Merging keeps the first item for each topic.

Completion order is not output order

  1. Finish order
  2. Slot
  3. Same merge order

More detail

Arrival A

21

Arrival B

12
Slot

Same merge order

12
Design Patterns / Merge Sort

Per-topic slots preserve the request-order merge regardless of which planning call finishes first.

Figure 13. Assigned slots make output ordering independent of completion time.

Bound upstream failure

Topic calls share a circuit breaker that opens after three consecutive failures. Its open timeout is 15 seconds; each topic also has its own call timeout.

Reject unhealthy calls quickly

  1. Closed
  2. Open
  3. Half-open

More detail

Closed3 consecutive failures
Open15 seconds open
Half-openUp to 2 trial calls

Tradeoff: requests can be rejected quickly

Three consecutive failures open the breaker; recovery probes trade some immediate availability for fast rejection.

Figure 14. A shared breaker bounds repeated upstream calls after failures.

Reject malformed graph input

The loader rejects unknown JSON fields, empty values, unsupported relations and self loops. It trims fields and de-duplicates valid tuples before building the graph.

Only well-formed relations enter

  1. Graph input
  2. Checked
  3. Supported relation

More detail

Graph input
  • Unknown fields
  • Empty fields
  • Unsupported relation
  • Self loop
Supported relation
AAA
Exact duplicates collapse

Unknown fields, empty values, unsupported relations and self loops reject the graph; exact duplicate tuples collapse.

Figure 15. Strict tuple loading rejects malformed graph input.

Fail rather than return a partial plan

Any failed topic fails the whole request. Successful fragments from the remaining calls are not returned as a partial plan.

A plan is all or nothing

  1. Another topic fails
  2. Stopped
  3. No partial plan

More detail

Topic result ready
Another topic fails
Stopped
PlanNo partial plan
502 · upstream error503 · circuit open504 · timeout

An upstream error, open circuit or timeout fails the request rather than returning an incomplete partial plan.

Figure 16. One failed topic prevents a partial plan response.

Limitations

Resources and explanations remain unchecked

Go does not validate resource URLs, titles, types or explanation text. Graph validation corrects structure, not the quality of that generated content.

Ordering is not content validation

  1. Model draft
  2. Checked
  3. Unchecked

More detail

Model draft
Checked

Topics, chains, order

Graph
Unchecked
  • Resource title
  • Resource link
  • Resource type
  • Explanation

The graph does not validate resource titles, links, types or explanation text, so ordering is not a quality guarantee.

Figure 17. Structural validation does not validate resources or explanation text.

The loader does not check cycles

Malformed tuples and self loops are rejected, but the loader does not detect cycles across several nodes. A visited set prevents graph traversal from looping indefinitely.

Termination is not cycle validation

  1. Topic A
  2. Topic B
  3. Topic C

More detail

Hypothetical cycle — not the bundled graph

  • 1Topic A
  • 2Topic B
  • 3Topic C
Traversal terminates

Prerequisite order is not guaranteed

A visited set makes traversal terminate even in a cyclic curriculum, but it does not establish a valid prerequisite order.

Figure 18. A valid tuple format does not establish that the graph is acyclic.

The seed graph is small

The repository’s seed contains 20 relationships in a computer-science curriculum. It is a bounded example, not a complete curriculum.

A small curriculum example

  1. Bundled curriculum
  2. Operator-supplied graph

More detail

Bundled curriculum

23 Concepts20 Relations
Operator-supplied graphReplace the seed

The bundled example has 20 relations across computing topics; an operator-supplied graph replaces it for another curriculum.

Figure 19. Twenty seed relationships define a small curriculum example.

No learning-outcome claims

Plans are not checked for completeness or educational quality. VARK is a declared preference, and the cognitive graph’s default “mastered” label is not evidence of mastery.

A valid order is not a learning outcome

  1. Study order
  2. Learner outcomes

More detail

Study order
  • Graph membership
  • Prerequisite chains
  • Topic order
Learner outcomes
  • Learning gains
  • Teaching effectiveness
  • Plan quality

Topic validation and prerequisite ordering do not measure whether a learner improves or whether the plan teaches well.

Figure 20. Declared preferences and graph labels do not establish learning outcomes.