# Using Cambria Forge data with an AI assistant

This is a static planning reference, not a live game connection. Use the source/build information before making a claim about a character or server rule.

## Data entry points

- **Read `data/talents.json` first**: 336 nodes, 752 possible rank records, 20 lines, 60 forks and the original structured talent payloads. The base snapshot is 2.19.53 from October 24, 2026. The 752 count includes alternative forks and Keystones; it is not a simultaneously achievable character allocation.
- **Read `data/mechanics.json` for current reference data**: fact/advice cards and versioned spell, prayer, equipment, consumable and status references. Current source build is 2.19.54 from October 25, 2026.
- The Planner loads a slim `data.js` (`window.CAMBRIA_DATA`). The complete `data/talents.json` remains the preferred AI input. The legacy `mechanics.js` (`CAMBRIA_MECHANICS`) catalogue is downloadable separately and is not loaded by the two-tab website. The portable JSON files contain data only; there is no need to execute JavaScript to read them.
- `engine.js` exposes `CambriaEngine`: local plan validation, rank derivation, eligible effect contributions and allocation transitions. It is site-authored code. Do not execute downloaded game modules or the formula strings stored in reference records.
- `provenance.json` records which comparisons support carrying historical data forward. It does not declare all historical fields current. This guide is packaged as `AI-GUIDE.md` beside it.

All four talent configuration objects, all 82 spell objects and all 8 active prayer objects were statically matched between the saved builds. The cooldown provider file also matched. Equipment tier-2 proficiency changed from 10 to 0: use `CAMBRIA_MECHANICS.reference.proficiency.equipmentTierLevels` for current equipment guidance, not the historical raw table in `CAMBRIA_DATA.rules`.

## Build state

```json
{
  "schema": 1,
  "name": "Example plan",
  "context": "pve",
  "budgets": {"melee": 24, "ranged": 0, "magic": 0, "armour": 18},
  "budgetSource": "manual",
  "weaponLine": "sword",
  "armourSlots": {"body": "plate", "head": "plate", "offhand": null},
  "proficiency": {"sword": 65, "plate": 65},
  "ranks": {},
  "forks": {},
  "safeZone": true
}
```

This example defines planning inputs; it does not recommend an optimized allocation. Normalize missing fields through the engine. Validate imported plans before evaluating or mutating them.

- `context`: `pvp`, `pve` or `hybrid`.
- `budgets`: actual earned style points supplied by the user, or Sandbox allowances. No public level-to-earned-points formula was established. Style capacities Melee70/Ranged62/Magic66/Armour68 are not earned rewards.
- `levels`: informational character levels, not point-budget inputs.
- `proficiency`: levels 0–99 for each of the 20 lines. Line ranks derive automatically; do not insert them into `ranks`.
- `ranks`: allocated Core/Keystone ranks only. A rank's effect values are totals, not increments to add to earlier ranks.
- `forks`: one selected node ID for each fork ID. Only the selected side contributes when its proficiency gate is reached.
- `armourSlots`: line IDs or null. Body contributes weight2; head/offhand1. Only the largest share is active, with body winning positive ties; without a recognized body, canonical Plate/Chain/Leather/Robes order breaks ties.
- `safeZone`: planning condition for refunds, changed fork selections and Keystone swaps. It does not read the live player's location or spend real Silver.

## Reading evaluation output

`ranks` includes learned progression across all branches. `activeRanks` and `activeNodeIds` reflect the equipped weapon line, one dominant armour line, valid allocation and target context. `learnedEffects` retains dormant entries with reasons. `effects` contains active/eligible current-rank contributions with original keys, values, scope and condition text.

“Active” means eligible in this setup. It does **not** mean an on-kill, low-health, distance, stack, channel, chance or ailment condition is currently satisfied. Preserve these conditions in the answer.

In the browser helper, `CAMBRIA_MECHANICS.getAdvice(state,evaluation)` returns priority-sorted matching advice and relevant fact cards; `search(query,{category,kind,mode})` searches cards. The portable `data/mechanics.json` contains the same cards and declarative predicates without functions. `kind: advice` is an interpretation of its cited data; `kind: fact` is a static-client/configuration claim, not independent proof of server enforcement. Reference catalogues do not supply a complete target-immunity model. The site's PvP/PvE filter applies to guides; catalogue records are explicitly shown for all modes.

## Numeric and semantic limits

- Do not calculate exact final DPS, final hit probability or total mitigation from these partial formulas. The legacy server CombatResolver and modifier order are absent. Several alternative formula branches are explicitly disabled.
- Accuracy percentage is not a percentage-point increase in hit chance. Do not add unrelated damage keys or conditional bonuses as a universal total.
- Keep talent-rank ability descriptions separate from baseline spell descriptions. They sometimes differ. Do not infer which numeric description wins in the final server combination.
- Default and Depths baseline cooldowns have separate tables. “Cools down faster” and “cooldown is shorter” are not interchangeable arithmetic without a verified implementation.
- Prayer `drain_rate` has no stated time unit in these objects. Do not predict time-to-empty.
- A resistance field is not automatically a resistance percentage. Raw equipment fields do not establish their complete application formula.
- Food's 900 ms value is an attack delay, not a universal eating cooldown. Some food heal fields disagree with descriptions; preserve both values.
- Fatigue healing reduction has current descriptions of 25% and 35%. Do not silently pick one.
- A 6-bit synchronized counter saturating at63 does not prove a server stack cap. Use explicit talent caps where stated.
- Preserve exclusions such as “not against players”, reduced elite/boss effectiveness, NPC-only or strong-enemy immunity. Do not treat a PvP context as proof every eligible ability can target a player.

## Provenance and screenshots

Prefer the exact static source record and source range for mechanics. Original public X screenshots by ProstoXleb (October24) and acedeeno (October25) corroborate geometry, glyphs, UI labels and visible capacity/row-gate values. Neither screenshot shows a build number, proves the whole node/rank count, establishes earned point rewards, or validates server combat formulas.

No account state, item ownership, live build, live economy, match telemetry or private API response is included. When a question needs those facts, ask for the relevant character values or measured evidence instead of inventing them.

## Community website revision

The current website has only Planner and Builds. Private device drafts are distinct from explicitly published community records. Builds and private feedback use a same-origin Worker and Sites-managed D1. Reading/planning is public; publication/edit/delete and feedback require built-in ChatGPT identity. Public aliases are user-chosen; no account IDs or profile emails are returned. Optional legacy notes/equipment metadata are excluded from publications.

The thirteen interface/description locales are en,zh-CN,ru,fil,de,fr,vi,pt,es,uk,ko,ja,tr. English talent and weapon names and IDs remain canonical. Each locale supplies178 numeric templates covering all752 rank descriptions. These are reference translations, not a claim of official game localization or native-speaker review. Numeric values and conditions are preserved; do not execute formula strings.