TRD2 Modding Final Journal

Memory name:
TOCA Race Driver 2 Modding Mayhem — Final Master Memory Journal (EXE/AIB/Championship Expansion)

Memory version and date of writing:
Stable 3 final consolidation; 2026-09-29

Name of the writer:
ChatGPT

Relevant sections:
- A0: read first; this is the compact set of critical facts required to continue the project without restarting the investigation.
- A2: formal goals.
- C3: proven / unproven / disproven status.
- C4: reproducible AIB-generation and native BIG insertion procedure.
- C5: warnings, traps, and the best next targets.
- Main project focus: TOCA Race Driver 2 (PC), championship expansion, AI resource resolution, AIB generation, and vehicle/class identity.

Information ordering rule:
Information is ordered from critical importance to least important in every section. A0 contains only critical information required to preserve the project's state and reproduce its formal goals.

Section A:

A0- Important or critical information:

1. CORE ARCHITECTURE — DO NOT RESTART THE INVESTIGATION FROM CLASS NAMES
RD2.exe has a real internal identity pipeline for selecting AIB resources:
    championship / vehicle configuration identity
        -> parsed raw/internal CarID
        -> canonical ID
        -> hard-coded canonical AI namespace
        -> track-specific AIB filename
        -> native BIG archive resource
        -> runtime AIB corner-speed data
        -> AI driving behavior

The critical warning is:
    User-facing class/championship name != necessarily AIB namespace.
Never infer the AIB filename only from a Cardata family or championship label.

2. EXECUTABLE FUNCTIONS THAT MATTER
AIB/resource loading was traced directly in RD2.exe.

- 0x43D460: parses literal class/type identity strings into raw/internal CarID values.
- 0x43DA70: canonicalizes raw IDs.
    * input is bounded at <= 0xF4.
    * indexes a byte lookup table at 0x43DBFC.
    * uses a jump table at 0x43DB68.
- 0x40FD50: maps canonical IDs 0..0x25 to AIB namespace strings via a jump table around 0x40FF84.
- 0x410020: constructs resource names using:
      "%s_%s%s"
      "%s_%s_s%s"
  and converts the canonical ID to its namespace string before formatting.
- 0x4106C0: central AIB resource setup/loading path.
    * vehicle/object comes from global table 0xB0BC98[index].
    * vehicle/object +0x78 -> driver record.
    * driver record +0x44 = raw CarID.
    * raw CarID -> 0x43DA70.
    * canonical ID -> 0x410020.
    * resource lookup -> 0x5785F0.
    * loader/allocation -> 0x57AF20.
    * reuse/dedup path -> 0x410820.
- 0x410820: related AIB reuse/dedup path; it repeats the vehicle/object -> +0x78 -> +0x44 -> canonicalization flow.
- 0x411280: requested vehicle index -> 0xB0BC98[index] -> +0x78 -> driver +0x44 -> canonicalization -> 0x410100; searches loaded AIBs and, when needed, reaches 0x4110E0.
- 0x4110E0: secondary AIB path. It searches the descriptor table at 0x62579C for descriptor +0x2D4 == requested index, follows +0x2A4 -> runtime entry +0x60 -> driver +0x44, canonicalizes, calls 0x410100, then 0x57AF20.
- 0x411380: initializes AIBs through loops and invokes 0x410820 / 0x411280.
- 0x42D000: builds descriptor table.
    * config object count from 0x444800
    * 0x444220(config,index) = config +0x1A40 + index*0x80
    * descriptor +0x2D4 = index
    * 0x62568C[index*4] = descriptor pointer
    * descriptor +0x2A4 = runtime entry
- 0x444220: exact runtime-entry address:
      config + 0x1A40 + index*0x80
- 0x444800:
      movzx eax, byte ptr [eax+0x29AC]
- around 0x44357E: a routine reads a configuration field named "Name", passes it to 0x43D460, and stores the resulting raw ID into descriptor +0x44. The surrounding structure also contains fields such as Gender, CarID, FreeTimeImportance, RRIncludeRace, GridPosition, and GameMode. The exact file/object type containing the Name field was not fully identified, so do not claim it is literally a Cardata filename without further proof.
- 0x40DB20: builds vehicle-object table.
    * 0xB0BC94 = count
    * descriptor array at 0x62568C
    * descriptor +0x2A0 = vehicle object
    * descriptor +0x2A4 -> runtime entry +0x60 -> driver record
    * driver raw CarID +0x44 copied into vehicle object +0x78
    * vehicle pointers stored in 0xB0BC98[]
- 0x40E690: allocates 0x1A0-byte vehicle object.
- 0x40E6A0: compares candidate vehicle-object first DWORD against descriptor +0x2A0 first DWORD, indicating a shared physical/resource identity test is likely present.
- 0x42C180: Cardata path construction:
      raw CarID -> 0x43C9F0 -> "cardata\%c%c\%s.big"
  Templates recovered include:
      ca_%c, sk_%c, ps_%c, ma_%c, mg_%c, sc_%c, fi_%c, wg_%c,
      he_%c, uo_%c, v8_%c, v8b_%c, xk_%c, ex_%c, ko_%c, bs_%c,
      uk_%c, dt_%c, dtb_%c, gt_%c, us_%c, lr_%c, ac_%c, cc_%c,
      vc_%c, ft_%c, pi_%c, sl_%c, pg_%c, ff_%c, fm_%c, g9_%c, g4_%c

3. AUTHORITATIVE CANONICAL -> AIB NAMESPACE TABLE
Use this table when determining filenames:
    canonical 0,1,2 -> vc
    canonical 3    -> g9
    canonical 4    -> pg
    canonical 5    -> bs
    canonical 6    -> ex
    canonical 7    -> g4
    canonical 8,9  -> wg
    canonical 10   -> ko
    canonical 11   -> am
    canonical 12,13 -> cc
    canonical 14   -> cr
    canonical 15,16,17 -> uk
    canonical 18   -> pg
    canonical 19,20,21 -> dt
    canonical 22,23,24,25 -> v8
    canonical 26   -> pi
    canonical 27   -> gt
    canonical 28   -> ma
    canonical 29   -> sl
    canonical 30   -> uo
    canonical 31   -> xk
    canonical 32   -> mg
    canonical 33   -> us
    canonical 34   -> f9
    canonical 35   -> fi
    canonical 36   -> lr
    canonical 37   -> ff

Important correction:
    ca_0 raw 0xD1 -> canonical 10 -> namespace ko
NOT ex, am, or v8.
    ex_0 raw 0x91 -> canonical 6 -> namespace ex.

4. CRITICAL RAW/CANONICAL EXAMPLES
Known mappings recovered directly from the executable:
    uk_0 raw 0x78 -> canonical 15 -> uk
    uk_1 raw 0x79 -> canonical 16 -> uk
    uk_2 raw 0x7A -> canonical 15 -> uk

    bs_0 raw 0x7B -> canonical 15 -> uk
    bs_1 raw 0x7C -> canonical 15 -> uk
    bs_2 raw 0x7D -> canonical 15 -> uk
    bs_3 raw 0x7E -> canonical 16 -> uk
    bs_4 raw 0x7F -> canonical 16 -> uk
    bs_5 raw 0x80 -> canonical 16 -> uk

    he_0 raw 0xC7 -> canonical 16 -> uk
    he_1 raw 0xC8 -> canonical 15 -> uk

    ca_0 raw 0xD1 -> canonical 10 -> ko
    ex_0 raw 0x91 -> canonical 6 -> ex

    fm_0 raw 20 -> canonical 2 -> vc
    fm_1 raw 21 -> canonical 5 -> bs

    sc_0..sc_4 raw 209..213 -> canonical 10 -> ko
    sc_5..sc_9 raw 214..218 -> canonical 7 -> g4

    g4_0..g4_9 raw 0..9 -> canonical 7 -> g4
    ko_0..ko_9 raw 135..144 -> canonical 10 -> ko

This proves that Cardata families may reuse completely different AI namespaces.

5. MIXED-CLASS / VARIANT RULES THAT MATTER MOST
- FM is not one AI namespace:
    fm_0 = Mustang '68 -> vc
    fm_1 = Mustang 2000 Cobra R -> bs
- SC is not one AI namespace:
    sc_0..sc_4 = Koenig 2002 -> ko
    sc_5..sc_9 = Race Tuned GT40 -> g4
- This matches file inspection:
    sc_0.big is mechanically identical to the KO Koenig package for mech.csv,
    SimMech.csv, int.ini, and dmg.ini.
    sc_7.big is a Ford GT40 / Race Tuned GT40 identity.
- Do not create sc AIBs merely because the Cardata family is sc.
- Do not create ca AIBs merely because Caliburn is labeled ca.
- Cross-championship Cardata reuse is normal and not itself a problem.

6. DRIVER CONFIGURATION FIELDS
The driver parser around 0x443380:
- loops "Driver %i"
- runtime entry = config +0x1A40 + N*0x80
- runtime_entry +0x60 = config +0x29B4 + N*0x78
- reads "CarID" from string location around 0x5e2464
- calls 0x43D460
- writes raw CarID to driver record +0x44

Parsed AI fields:
    AIAggression -> +0x48
    AIControl    -> +0x4C
    AIMistakes   -> +0x50
    AISpeedIn    -> +0x54
    AISpeedOut   -> +0x58
    AIStartline  -> +0x5C
These are real parsed configuration fields, separate from AIB corner data.

7. AIB BINARY FACTS
Original archive:
- 529 real original AIB files.
- All 529 were checked and byte 10 matched nc with zero mismatches.
- 6,485 real corner records were checked.
- Corner record format:
      [4 zero bytes][speed uint16][tag uint16]
- AIB header examples begin:
      0c 00 00 00 08 00 00 00
- AIB byte 10 is the true nc value (corner count).
- Corner count is track-geometric and shared across classes.
  Example: Bathurst had 17 corners for 11 real class resources.
- Byte 11 is separate and must not be casually modified.
- AIB uint16 values are target-speed-related inputs, not simply "raw km/h".
- Downstream consumer around 0x4084FC transforms the stored uint16 using runtime globals and 0x5D0278, with observed limits around min 40 (0x28) and max 400 (0x190) in the target path.
- 0x40F1F0 interpolates vehicle response curves using values related to [esi] / [esi+4], with scaling involving 1/65536 and 3000.0; if current speed exceeds target, a zero-like response can result.
- vehicle +0x144 contains current-speed-like data populated around 0x40BB11 using velocity * 3.6.
- Exact physical units and full formula are still not completely resolved.

8. MISSING ORIGINAL NAMESPACE FACT
Six Cardata/classes had no dedicated pre-existing original AIB/RED/BRP resources anywhere in the original archive:
    ca, fm, he, ps, sk, sc
This is NOT proof that those cars are unsupported by AI.
The executable canonicalization shows they can resolve to existing namespaces.

9. RESOURCE NAMING STRINGS IN .rdata
Relevant strings:
    0x5e0890 "%s_%s.qdr"
    0x5e0898 "%s_%s_s.qdr"
    0x5e08a0 "%s_s%s.red"
    0x5e08a8 "%s_ps%s.red"
    0x5e08c0 "bgraph.big"
    0x5e08cc "%s.big"
    0x5e08d4 "aib.big"
    0x5e08dc "cars"
    0x5e0910 "ai.ini"
    0x5e0924 "%s_i.brp"
    0x5e092c "%s_i_s.brp"
    0x5e0934 "%s.brp"
    0x5e093c "%s_s.brp"
    0x5e0950 "%s%s"
    0x5e0958 "%s_%s%s"
    0x5e0960 "%s_%s_s%s"
Class strings found include:
    xk ex lr fi us uo sl ma pi am cr cc mg bs vc ko ff f9 wg g9 g4 gt pg uk dt v8
They establish naming families, but the executable mapping still decides which one is actually requested.

10. FALLBACK BEHAVIOR — VERY IMPORTANT
At 0x4106C0, after failed resource lookup, the missing-AIB branch begins around 0x410784.
Original fallback writes decimal 40 (0x28).
Diagnostic executable:
    RD2_fallback999.exe
patched file offset:
    0x10784
original bytes:
    BF 28 00 00 00
patched bytes:
    BF E7 03 00 00
Original SHA-256:
    ce6bf4f1a8139eba3889dcb2d276aa931116cbfd72ffb9d5f3b64c6da74407c5
Patched SHA-256:
    a838a758a6ae03e76a4cf8a29a7a5038de149c88e1e44c54f43af66cebd79f7f

Experimental result:
- Changing fallback 40 to 999 causes obvious corner overshoot / altered AI behavior on unsupported combinations.
Therefore fallback behavior is real and materially affects driving.
The diagnostic EXE is NOT the desired mod-distribution solution. Native archive/resource supply remains the preferred implementation.

11. NATIVE BIG ARCHIVE STRUCTURE
Outer AIB archive observations:
- header begins BIGF39.
- outer archive had 57 entries in the examined original aib.big.
- outer directory record = 24 bytes.
- filename field = 12 bytes.
- size at record +16.
- offset at record +20.
- nested BIG physical base was derived from the outer directory offset plus 0x800 in the observed archive layout.

Nested track BIG:
- starts with BIGFxx (Eastern Creek example BIGF05; Hockenheim BIGF0A).
- directory records are 24 bytes.
- filename field = 12 bytes.
- size +16.
- offset +20.
- physical payload = nested data-base + stored entry offset.
- The tested nested BIGF layouts use 0x800-byte alignment conventions.
Do not confuse a directory-relative/stored resource offset with the physical payload location.

12. FIRST SUCCESSFUL NATIVE AIB RESOURCE INJECTION
Reference:
    aib_eastern_creek_vc_test_v2.big
SHA-256:
    cc7f3b0fef9013d1fbae862a16a524f1ad18ada0dbccd25122af9bfd0294c790
Archive size:
    4,067,328 bytes

Construction:
- base = original aib.big
- nested track wrapper = eas.big
- corrected nested BIGF05 offsets were used
- renamed only:
      eas_v8.aib   -> eas_vc.aib
      eas_v8_s.aib -> eas_vc_s.aib
- AIB payload bytes were unchanged.
- exactly two bytes differed from the original archive.
- changed absolute offsets:
      1863721
      1863745
User tested it in-game successfully.

Meaning:
- the unmodified game can resolve and consume a native AIB resource through the normal BIG archive path.
- no DLL injection or EXE patch is required for this route.
- this milestone proves namespace/resource selection, not yet custom numerical AIB generation.

13. SUCCESSFUL ADDITIVE AIB INSERTION — STRUCTURAL BREAKTHROUGH
Reference:
    aib_pacific_adelaide_generated_v8_additive_correct.big
SHA-256:
    2d5830f44ee1d851cece0e9789598d61209c1c201697164e3afdca8a4b723583

User result:
- no crash
- AI drives normally

Known tested construction:
- target nested archive = ade.big
- original entry count = 5
- new entry count = 7
- added:
      ade_pg.aib
      ade_pg_s.aib
- new aligned slots:
      ade_pg.aib    stored offset 0x6000
      ade_pg_s.aib  stored offset 0x6800
- original RED/AID/AIB resources were preserved.
- nested size became 0x7800.
- later outer resources were shifted by the exact nested-size increase.
- final archive size = 4,069,376 bytes.

This disproves:
    "RD2.exe cannot consume newly added AIB entries."
The native archive route can insert genuinely new AIB resources.

14. EXACT ADDITIVE CONSTRUCTION RULES TO PRESERVE
For an existing nested BIG:
1. Start from the original archive, not a malformed intermediate.
2. Parse the nested BIG header and directory exactly.
3. Preserve all existing records and payloads unchanged unless a test specifically calls for another change.
4. Increase directory count only by the number of truly new resources.
5. Add fixed 12-byte filename fields.
6. Allocate each new resource in its own 0x800-byte-aligned slot.
7. Keep the stored directory offset consistent with the nested data-base convention.
8. Compute physical payload placement separately from the stored directory offset.
9. Never overlap a new AIB slot with an existing AIB, RED, or AID payload.
10. Update nested size to cover all aligned new slots.
11. Rebuild/update outer archive offsets for later outer entries if the nested archive grows.
12. Preserve outer archive entry sizes correctly.
13. Leave RD2.exe unmodified for the final native resource route.
14. Verify resource names, directory count, offsets, physical positions, sizes, and payload bytes before testing.
15. Test the exact car/namespace combination that should request the new resource.

15. AIB GENERATION METHOD THAT ACTUALLY WORKED AT BULK SCALE
Successful bulk archive:
    aib_champ30_location_priority_bulk_v1.big
Manifest:
    aib_champ30_location_priority_bulk_v1_manifest.txt
Input:
    champ30 (location priority).big
SHA-256:
    2af5525fe07036d4924c468e9df276950e0f6deb014024e312e12a68b9cdb1dc
Output size:
    6,373,376 bytes

Required track/canonical pairs:
    808
Existing normal namespaces retained:
    245
Missing/new namespace pairs:
    563
New AIB resources:
    1,126
    = 563 normal + 563 "_s"

Generation rule:
- for each missing track + canonical namespace pair:
    1. choose a same-track donor AIB;
    2. prefer a donor with the modal/compatible corner count;
    3. copy its entire payload;
    4. scale each corner speed uint16 at payload offset 0x10 + 8*i by 0.97;
    5. preserve all other payload bytes;
    6. generate both normal and "_s" resources;
    7. add them as new 0x800-byte-aligned entries;
    8. never replace existing archive resources.

User validation:
- approximately a dozen randomly sampled track/class combinations from the bulk archive were tested.
- observed:
    0 crashes
    0 fallback cases
    all tested combinations had normal AI behavior.

This is the strongest practical validation of the current generator.
It does NOT prove that every generated profile is optimally competitive on every track; it proves the method is safe/usable across a broad sample and successfully avoids fallback in that test set.

16. GENERATION QUALITY / ANALYSIS RESULTS
- Same-track donor shapes are much more useful than global flat models.
- A broad flat class-scale x raw-curvature model was weak: approximately 55% error even when corner count/position were correct.
- Template-based same-track donor generation using a global performance index from 14,029 real corner comparisons had median error around 10%.
- Existing AIB values have meaningful local corner associations.
- AIB experiments with all speeds=999 or all speeds=1 showed strong localized changes.
- A single corner speed change can cause localized overshoot/slowdown, confirming per-corner association.
- AIB values should not be casually interpreted as direct vehicle speed.
- The current 0.97 generation factor is an empirical/conservative recipe that worked well enough for broad native use; its physical meaning is not fully proven.

17. BEHAVIORAL AIB TESTS WORTH REMEMBERING
- zan_g4.aib all speeds=999 -> GT40 overshoots corners frequently.
- zan_g4 corner 0 speed=999 -> overshoot concentrated at first corner while other corners stayed comparatively normal.
- zan_g4 all speeds=1 -> GT40 became very slow at corners.
- An existing generated/modified Eastern Creek Mustang AIB with many corner values at 999 caused noticeably worse Mustang driving, proving injected numerical values matter.
- A true original zan_g4 AIB caused normal GT40 behavior when used independently.
- Setting every corner in zan_sc.aib to 999 produced no observable Supercar Cup change; this specifically means that file was not controlling that observed behavior, not that AIBs are irrelevant globally.
- Earlier large generated AIB populations caused broad AI changes in some contexts; these should not be used as evidence that every namespace was correct because those tests predated the canonical resolver breakthrough.

18. BRP / RED / AID STATUS
Current project priority:
    PRIMARY = AIB
    SECONDARY / DEFERRED = BRP, RED, QDR

BRP tests:
- g4.brp first 512 uint16 values set to 1 -> inconsistent hard braking / overshoot.
- g4.brp second 512 values set to 1 -> essentially normal.
- g4.brp first curve at 50% -> mostly normal.
- fm68.brp first curve half -> similar to original.
- fm68.brp first curve all 999 -> hard/slow corner braking persisted; more collisions/ramming but no clear solution.
- brp_test1: original zan_g4 AIB with generated 999 version + original g4.brp -> overshoot, generally normal.
- brp_test2: same + generated g4.brp -> more frequent overshoot / odd braking.
- brp_test3: generated eas_fm.aib all 999 + generated fm.brp/fm_s.brp -> Mustangs improved from worse to neutral.

RED:
- No convincing evidence has established that RED is required for competent AI when a correct AIB is found.
- Many "missing class" resources may be solvable through canonical AIB reuse without custom RED.

AID:
- .aid files are per-track, not per-class.
- cat.big contains cat.aid, 21,772 bytes.
- cat.aid header begins:
      06 0d 01 20 00 05 3d 01 00 00 00 00
- Section 1 = 1,585 float32 pairs = 12,680 bytes.
- Section 2 = 1,135 uint32 + float32 records = 9,080 bytes, meaning still unknown.
- AID should not be conflated with class-specific AIB.

19. CHAMPIONSHIPS / CARDATA GROUND TRUTH
The project documentation identifies 33 championships and their main vehicle identities:

1  Sunshine Series         -> Ford GT
2  Convertible Tour        -> DB7 Vantage Volante; XKR Convertible; AC 289 CRS
3  '68 Mustang Challenge   -> Ford Mustang 1968
4  Formula Ford            -> Formula Ford
5  Pacific American        -> Mitsubishi 3000 GT; Nissan Skyline GT-R R34
6  Supercopa               -> Seat Leon Supercopa
7  Lighting 500            -> Ford SVT F-150 Lightning
8  SuperTruck Racing       -> Ford 9000
9  Vintage Classic         -> Mustang 1968; Jaguar E-Type Series-II; Aston Martin DB5
10 Euro Rally              -> Subaru Impreza WRX; Mitsubishi Lancer Evolution VII
11 Duez Thropy             -> Subaru Impreza WRX ice/snow
12 Bowler Rallycross       -> Bowler Wildcat
13 Truman Stockcar         -> Championship Stockcar
14 Global GT Lights        -> Global GT Light Race Car
15 Coast To Coast          -> Ford GT90
16 Mustang Challenge 2000  -> Ford 2000 Mustang Cobra R
17 DTM                     -> ABT-Audi TT-R; AMG-Mercedes CLK; Opel Astra V8 Coupe
18 UK Rallycross           -> Subaru Impreza WRX; Mitsubishi Lancer Evolution VII
19 Street Series           -> Subaru Impreza WRX; Mitsubishi Lancer Evolution VII
20 Koenig Speedfest        -> Koenig Competition 2002
21 Excalibur Cup           -> Aston Martin DB9 Coupe
22 XKR Series              -> Jaguar XKR Race Car
23 V8 Supercars            -> Holden Commodore VY/VX V8 Supercar; Ford Falcon BA/AU V8 Supercar
24 American 1000           -> Single Seater 1000 Race Car
25 World GT                -> Jaguar XJ220; Koenig C62
26 Hotrod Streetrace       -> 1934 Ford Hot Rod Coupe
27 Pacific Street           -> Mustang 2000 Cobra R; Mitsubishi 3000 GT
28 Supercar Cup             -> Koenig Competition 2002; Ford GT
29 Duez Cup                 -> Aston Martin V12 Vanquish; XKR Convertible ice/snow
30 Masters Grand Prix      -> Masters Grand Prix Car
31 Caliburn Classic        -> Aston Martin DB9 Coupe
32 Mamba Single Day        -> AC Mamba
33 Speed Circus             -> Nissan Skyline GT-R R34

20. DETAILED CARDATA IDENTITY FAMILIES
Known important mappings:
    ac_0..ac_2  = Subaru Impreza WRX 2003 / ICE / Ice-Racer
    ac_3        = Aston Martin V12 Vanquish
    ac_4        = Jaguar XKR

    bs_0..bs_2  = Evo VII Street
    bs_3..bs_5  = Subaru Impreza WRX 2003 Street-Racer

    ca_0..ca_4  = Aston Martin DB9 (AM803)
    cc_0..cc_1  = Aston Martin DB7 Volante
    cc_2..cc_3  = Jaguar XKR
    cc_4..cc_5  = AC Cobra 289 CRS

    dt/dtb variants = Audi TT / Mercedes CLK / Opel Astra Coupe

    ex_0..ex_6  = Aston Martin DB9 (AM803)

    ff_0..ff_5  = Formula Ford

    fi_0..fi_1  = Ford 1934 Coupe

    fm_even     = Ford Mustang '68
    fm_odd      = Ford Mustang 2000 Cobra R
    specifically:
        fm_0,2,4,6,8 = 1968 Mustang
        fm_1,3,5,7,9 = Mustang 2000 Cobra R

    ft_0..ft_3  = Supertruck 500 bhp
    g4_0..g4_9  = Ford GT40
    g9_0..g9_9  = Ford GT90
    gt_0..gt_7  = Global GT Light

    he_0        = Subaru Impreza WRX 2003 / Scooby Rally
    he_1        = Evo VII Rally

    ko_0..ko_9  = Koenig 2002
    lr_0..lr_2  = Bowler Wildcat
    ma_0..ma_4  = AC Mamba
    mg_0..mg_a  = Formula One / Masters Grand Prix
    pg_0..pg_4  = Mitsubishi 3000
    pg_5..pg_9  = Nissan Skyline
    pi_0..pi_9  = Ford F150 Lightning
    ps_0..ps_2  = Mustang 2000 Cobra R
    ps_3..ps_5  = Mitsubishi 3000
    sc_0..sc_4  = Koenig 2002
    sc_5..sc_9  = Race Tuned GT40
    sk_0..sk_4  = Nissan Skyline
    sl_0        = Seat Leon Supercopa
    uk_0,uk_2   = Evo VII Rallycross
    uk_1        = Subaru Impreza WRX 2003 Rallycross
    uo_0..uo_9  = Open Wheel Series (OVAL)
    us_0..us_9  = Stock Car (Oval)
    v8 family   = Holden / Ford Falcon variants
    wg          = Jaguar XJ220 / Koenig C62 variants
    xk_0..xk_9  = Jaguar XKR Race Car

Special recurring edge cases:
- Subaru Impreza and Mitsubishi Evo appear across rally, rallycross, and street families.
- Aston Martin DB9 appears in both ca and ex Cardata families.
- Same physical car may legitimately reuse data across multiple championships.

21. GAINS FROM OTHER EXPERIMENTS / ARCHIVES
- Eastern Creek nested archive:
    eas.big outer size = 32768 in the inspected wrapper.
    BIGF05 begins at relative offset 2048.
    data area begins at relative offset 4096.
    eas_v8.aib relative data offset 0, size 108.
    eas_v8_s.aib relative data offset 2048, size 108.
    eas.aid relative data offset 4096, size 0x5644.
    eas_psV8.red relative data offset 22528, size 0x624.
    eas_sV8.red relative data offset 26624, size 0x624.
- Hockenheim:
    hoc.big outer record index 23.
    size 0xA800.
    directory offset 0x1DE800.
    nested physical base 0x1DF000.
    BIGF0A with 10 entries:
        hoc_am.aib   0x0000, size 0x6C
        hoc_dt.aib   0x0800, size 0x6C
        hoc_dt_s.aib 0x1000, size 0x6C
        hoc_s.aib    0x1800, size 0x6C
        hoc_v8.aib   0x2000, size 0x6C
        hoc.aid      0x2800, size 0x528C
        hoc_psdt.red 0x8000, size 0x71C
        hoc_sac.red  0x8800, size 0x718
        hoc_sdt.red  0x9000, size 0x71C
        hoc_sko.red  0x9800, size 0x718
  No original hoc_cr.aib / hoc_cr_s.aib were present.

22. THREE-WAY CANONICAL VALIDATION — KEEP THE CORRECTION
Initial three-way experiment:
    Pacific Street -> Hockenheim -> guessed uo
    Excalibur Cup -> Eastern Creek -> ex
    Seat Supercopa -> Adelaide -> sl

Results:
    Pacific/Hockenheim/uo  -> no crash, fallback
    Excalibur/Eastern/ex    -> no crash, normal AI
    Seat/Adelaide/sl        -> no crash, normal AI

IMPORTANT LATER CORRECTION:
The Pacific Street prediction of uo was wrong.
Executable mapping gives:
    ps_0..ps_2 -> canonical 3 -> g9
    ps_3..ps_5 -> canonical 5 -> bs
Therefore the uo fallback is not evidence of AIB generation failure.
The correct Hockenheim namespaces for Pacific Street are:
    hoc_g9.aib
    hoc_g9_s.aib
    hoc_bs.aib
    hoc_bs_s.aib

23. CHAMP30 LOCATION-PRIORITY BULK TEST
Input:
    champ30 (location priority).big
Output:
    aib_champ30_location_priority_bulk_v1.big
Manifest:
    aib_champ30_location_priority_bulk_v1_manifest.txt
SHA:
    2af5525fe07036d4924c468e9df276950e0f6deb014024e312e12a68b9cdb1dc

Counts:
    required track/canonical pairs = 808
    existing normal namespaces retained = 245
    missing/new pairs = 563
    new AIBs = 1126

The bulk generator used the same-track donor / compatible corner-count / 0.97 uint16 speed scaling recipe above.
User sampled roughly twelve generated combinations:
    0 crashes
    0 fallback
    all normal AI

This is currently the best empirical result in the project.

24. FINAL RANDOMIZED CHAMP30 STATUS
The user later supplied:
    champ30 (randomized).big

A working AIB/resource build for the randomized championship was also created during the continuation of the project. Its generated attachment was subsequently deleted from the conversation/session, but the user preserved a copy. Therefore:
- Do NOT claim the randomized AIB is lost.
- Do NOT claim a new randomized AIB still needs to be created from scratch.
- The preserved randomized working AIB should be treated as a recovered project artifact for future comparison/reference.
- The exact generated filename, SHA-256, and full resource inventory were not preserved in this final journal, so a future session should identify the preserved file before making any claims about its exact contents.

25. OTHER CORRECTIONS THAT MUST NOT BE LOST
- Earlier assumption that 59EA10 was the primary AIB consumer was corrected; the important downstream driving consumer is around 0x4084FC.
- Earlier assumption that 4104D0 was the corner detector was corrected; 410930 is the clearer corner-indexing path.
- Early Eastern Creek archive test v1 had filename fields patched at wrong relative positions and was invalid as a namespace test.
- Correct Eastern Creek v2 changed exactly two filename bytes.
- Several early Adelaide additive archives crashed because nested directory/data relationships were malformed, physical placement overlapped existing data, and one intermediate test had a filename field overflow risk.
- A mistaken interpretation treated stored directory offsets as direct physical offsets from the nested BIG start. The correct relationship uses the nested data-base.
- Earlier Caliburn Hockenheim tests using ex/v8/cr/lr were contaminated by wrong namespace hypotheses or malformed/replaced resources. The later direct mapping establishes:
      ca -> raw D1 -> canonical 10 -> ko
  so Caliburn's relevant AI namespace is ko, not ex.
- Do not use the earlier guessed ex-based Caliburn result as evidence for the final mapping.

26. OTHER PROJECT FACTS
- gates.big is career progression/selection, not the primary AIB physics source.
- bgraph.big appears in resource strings; no evidence currently makes it the critical AIB route.
- The project should prefer normal archive modification over DLL injection.
- The final target is not to globally change the fallback constant. The goal is to make the native resolver find an appropriate AIB so fallback is unnecessary.

A1- Short summary of the current chat related to the formal goal:

The project began as a search for a reliable way to expand TOCA Race Driver 2 championships without blindly duplicating AI resources. The investigation first decoded the native AIB binary format, then proved by controlled value changes that AIB corner data affects AI. The decisive breakthrough came from disassembling RD2.exe: 0x43D460 parses configuration identities into raw IDs, 0x43DA70 canonicalizes those IDs, 0x40FD50 maps canonical IDs to AI namespaces, and 0x410020 builds the requested AIB filename. This explained many apparently missing classes and mixed Cardata families. A native filename substitution succeeded, then a genuinely additive AIB resource was successfully inserted into a nested BIG archive. Finally, a bulk generator created 1,126 new AIB resources for 563 missing track/namespace pairs in champ30 (location priority); roughly a dozen user tests produced zero crashes and zero fallback cases. A working randomized-championship AIB was also created later and preserved by the user after its conversation attachment was deleted.

A2- Goal of the chat:

Formal goal:
Create a durable, self-contained reverse-engineering and modding record for TOCA Race Driver 2 that allows a future session to:
1. Resolve the exact AIB namespace requested for a vehicle by following executable canonicalization.
2. Inspect a championship's actual vehicle/class combinations without assuming class-name = namespace.
3. Add missing native AIB resources to nested BIG archives safely.
4. Generate plausible AIB data using same-track donor geometry and conservative 0.97 scaling.
5. Verify that the new resources are actually found by the unmodified executable.
6. Avoid repeating failed archive-construction mistakes or obsolete namespace assumptions.

Sub-goals:
- preserve all important executable addresses and mappings;
- preserve binary/archive construction rules;
- preserve the proven tests and their results;
- distinguish proven facts from unproven interpretations;
- document the exact bulk-generation recipe;
- record the corrected status of the randomized-championship AIB.

A3- Relevant web sources:

None.
The project conclusions come from local/uploaded RD2.exe, BIG archives, Cardata documentation, project journals, and in-game test observations. No web source was required for the core findings.

Section B:

B1: Summary of the entire chat:

The TOCA Race Driver 2 Modding Mayhem project evolved from behavioral guessing into executable-level reverse engineering. Early tests decoded the AIB format and showed that corner-speed values matter: changing one corner could make an AI car overshoot that specific corner, while setting values to very low numbers could make it extremely slow. Large blind AIB populations produced inconsistent side effects, so the project stopped treating every Cardata class as an independent AIB namespace.

Disassembly of RD2.exe then revealed the critical chain. The driver/configuration system parses identity strings through 0x43D460 into raw IDs. The executable canonicalizes those IDs at 0x43DA70 and maps canonical IDs to AIB namespaces at 0x40FD50. The loader around 0x4106C0 and filename builder at 0x410020 then construct names such as track_namespace.aib and track_namespace_s.aib. This showed that classes such as FM, SC, CA, PS, HE, and SK do not necessarily need their own AIB namespace. The most important variant results are fm_0 -> vc, fm_1 -> bs, sc_0..4 -> ko, and sc_5..9 -> g4. This matches the inspected car identities, including the mixed Supercar family.

The project also established that the normal archive route is enough. The first clean Eastern Creek namespace substitution succeeded in the unmodified game. Then a new AIB resource was physically added to Adelaide's nested BIGF05 archive with correct directory count, offsets, alignment, and outer-file relocation; the game loaded it without crashing. Failed Adelaide builds were traced to archive-construction mistakes rather than an engine limitation.

The final major practical result was the champ30 location-priority bulk generator. It identified 563 missing track/canonical combinations, created 1,126 new normal/_s AIBs, preserved the 245 existing normal namespaces, and used same-track donor AIBs with compatible corner counts and a 0.97 uint16 speed scale. Approximately a dozen user tests produced normal AI with zero crashes and zero fallback cases. The puzzling Pacific Street -> Hockenheim -> uo case was later corrected: Pacific Street actually maps to g9 and bs, so the fallback was caused by the wrong predicted namespace, not by the generator.

A working AIB for the randomized champ30 version was also created during the continuation after the location-priority work. Its conversation attachment was later deleted, but the user explicitly preserved the working copy. That preserved artifact should be recovered/identified before future modification or redistribution. The technical details of that randomized build were not consolidated into this journal, so its exact filename/hash should not be invented.

B2: Your thoughts about the chat or current project:

The central lesson is that RD2's resource identity system is more sophisticated than its Cardata folder names suggest. Canonicalization is the key to scaling the mod: once the exact namespace is known, native archive insertion works and broad AIB generation becomes a manageable data problem instead of an EXE-hook problem. The bulk result is strong evidence that the current same-track donor method is practical. The future work should stay disciplined: map first, generate second, validate third.

B3: Reference artifacts:

Critical references preserved in the project:
- RD2.exe
- TRD2 general info R2.txt
- deeper cardata.txt
- [skill-card] Memory Journal SR3.txt
- aib_champ30_location_priority_bulk_v1.big
- aib_champ30_location_priority_bulk_v1_manifest.txt
- aib_eastern_creek_vc_test_v2.big
- aib_pacific_adelaide_generated_v8_additive_correct.big
- RD2_fallback999.exe
- champ30 (location priority).big
- champ30 (randomized).big
- user-preserved randomized-championship working AIB (exact filename/hash to be recovered from the preserved copy)

Section C:

C1- Steps taken to reach the goal:

1. Catalogued original AIB resources and established that 529 real files existed.
2. Verified byte 10 = nc across all 529 originals and inspected 6,485 corner records.
3. Identified AIB corner record layout as 4 zero bytes + speed uint16 + tag uint16.
4. Used deliberate AIB value changes at Zandvoort and Eastern Creek to prove per-corner AI effects.
5. Tested BRP curves and established that at least one BRP curve can materially affect braking behavior, while not proving a universal requirement for BRP.
6. Investigated large generated AIB populations and learned that blind namespace duplication could create broad unwanted behavior.
7. Inspected Cardata documentation and championship rosters to obtain real vehicle identities.
8. Disassembled RD2.exe and traced 0x443380 / 0x43D460 / 0x43DA70 / 0x40FD50 / 0x410020 / 0x4106C0 and related descriptor code.
9. Built the canonical namespace table and verified mixed-family examples such as SC and FM.
10. Traced the AIB-missing fallback at 0x4106C0 and experimentally changed its value to 999 in RD2_fallback999.exe, confirming fallback behavior can cause overshoot.
11. Decoded the nested BIGF05 structure inside eas.big and corrected an initial filename-offset mistake.
12. Created and successfully tested the clean Eastern Creek namespace substitution v2.
13. Built and successfully tested an additive Adelaide archive with genuinely new AIB entries.
14. Investigated and corrected failed additive archives caused by wrong offsets, data overlap, and filename-field errors.
15. Ran a three-way canonical-resource validation across Hockenheim, Eastern Creek, and Adelaide.
16. Corrected the Pacific Street -> uo assumption using the executable's actual raw/canonical mapping.
17. Built the champ30 location-priority bulk AIB archive using same-track donors, compatible corner counts, 0.97 speed scaling, and additive 0x800-byte slots.
18. User sampled roughly a dozen generated combinations with 0 crashes, 0 fallback, and normal AI.
19. Continued to the randomized champ30 file and created a working AIB/resource build for it; the conversation attachment was later deleted, but the user preserved the working copy.

C2- Mistakes and corrections:

1. WRONG: treating the Cardata/championship abbreviation as the AIB namespace.
   CORRECTION: use raw CarID -> canonical ID -> 0x40FD50 namespace.

2. WRONG: earlier temporary claim that ca_0 mapped to ex/am/v8.
   CORRECTION: ca_0 raw 0xD1 -> canonical 10 -> ko.
   ex_0 raw 0x91 -> canonical 6 -> ex.

3. WRONG: predicting Pacific Street -> Hockenheim -> uo.
   CORRECTION:
       ps_0..2 -> g9
       ps_3..5 -> bs
   The uo fallback therefore does not invalidate the generator.

4. WRONG: first Eastern Creek v1 filename-field locations.
   CORRECTION: actual inner filename fields were at the corrected positions; v2 changed only the two intended bytes.

5. WRONG: treating stored nested-BIG entry offsets as direct physical offsets.
   CORRECTION: stored directory offset must be translated through the nested data-base before locating physical payload.

6. WRONG: interpreting Adelaide crashes as proof of unsupported additive AIB insertion.
   CORRECTION: crashes were caused by malformed directory/data layout, overlapping data, and related construction errors. A corrected additive build works.

7. WRONG: assuming 59EA10 was the main AIB corner-speed consumer.
   CORRECTION: primary downstream driving consumption is around 0x4084FC.

8. WRONG: treating 4104D0 as the definitive corner detector.
   CORRECTION: 410930 is the clearer corner indexing routine.

9. WRONG STRATEGY: considering a patched executable or DLL injection as the final delivery mechanism.
   CORRECTION: keep executable patching diagnostic-only; native BIG resource insertion is sufficient for the demonstrated AIB route.

10. IMPORTANT LIMITATION: the bulk generator is proven safe/useful, not mathematically proven optimal. Its 0.97 factor is an empirical generation choice.

11. RANDOMIZED-CHAMP30 STATUS CORRECTION:
   The randomized-championship AIB was in fact created successfully during the continuation. The generated conversation attachment was later deleted, but the user preserved a working copy. The journal must not describe that work as unfinished or lost.

C3- Proven, unproven and disproven facts:

PROVEN:
- AIB resource selection uses an executable identity/canonicalization pipeline.
- 0x43D460 parses identity strings into raw IDs.
- 0x43DA70 maps raw IDs to canonical IDs.
- 0x40FD50 maps canonical IDs to AI namespace strings.
- 0x410020 builds track + namespace AIB filenames.
- 0x4106C0 is a central AIB load/setup path.
- Missing AIB resources enter an explicit fallback path using original value 40.
- Changing that fallback to 999 can materially alter AI corner behavior.
- Original AIB byte 10 equals nc for all 529 originals examined.
- Original AIB corner records use the verified [4 zero][speed u16][tag u16] structure.
- AIB corner values are used in later AI driving logic.
- Native AIB resource substitution works in the unmodified executable.
- Native additive AIB insertion works in at least the tested nested BIGF05 case.
- New normal and "_s" AIB resources can be added as separate 0x800-byte-aligned slots.
- The same-track donor + compatible corner count + 0.97 speed scaling recipe produced a bulk archive with 1,126 newly inserted AIB resources.
- Approximately a dozen user tests of the champ30 location-priority bulk archive produced zero crashes and zero fallback cases with normal AI.
- fm_0 -> vc and fm_1 -> bs are executable-derived mappings.
- sc_0..4 -> ko and sc_5..9 -> g4 are executable-derived mappings.
- ca_0 -> ko is executable-derived.
- Pacific Street maps to g9 and bs, not uo.
- Six classes lacked original dedicated AIB/RED/BRP resources but are not therefore unsupported.
- A working AIB/resource build for champ30 (randomized) was created; the user preserved a copy after the conversation attachment was deleted.

UNPROVEN:
- Exact physical units of the AIB uint16 corner values.
- Complete closed-form conversion from AIB uint16 to final target speed.
- Whether every generated AIB is competitively optimal on every vehicle/track pair.
- Whether every track's nested BIG has identical internal layout details.
- Exact runtime selection behavior for every possible canonical namespace.
- Whether every BRP/RED/QDR resource is unnecessary in every gameplay situation.
- Exact identity of the higher-level file/object containing the "Name" field parsed around 0x44357E.
- Exact filename, SHA-256, and full inventory details of the preserved randomized working AIB are not recorded in this journal.

DISPROVEN / CORRECTED:
- "A class named ca/fm/sc/etc. must have an identically named AIB namespace." Disproved by executable mapping.
- "Fallback is probably irrelevant to driving." Disproved by the 999 fallback test.
- "RD2.exe cannot load newly added AIB entries." Disproved by the successful Adelaide additive archive.
- "Replacing an existing AIB is the only workable native method." Disproved by additive insertion.
- "Adelaide crashes prove the new namespace/resources are unsupported." Disproved; archive construction was at fault.
- "Pacific Street should use uo at Hockenheim." Disproved; ps maps to g9 and bs.
- "59EA10 is the primary AIB speed consumer." Corrected.
- "4104D0 is the definitive corner detector." Corrected.
- "A patched EXE is required for the final solution." Disproved for the demonstrated AIB route.
- "The randomized champ30 AIB work was unfinished/lost." Corrected: a working version was created and preserved by the user, although exact build metadata must be recovered.

C4- Step by step instructions to achieve the finished goal:

PART I — Determine the requested AIB namespace for a car/class

1. Obtain the exact vehicle/Cardata identity used by the championship entry. Do not stop at the championship name.
2. Find the corresponding configuration identity string / CarID path used by RD2.
3. Parse the identity through the executable's logic equivalent to 0x43D460 to obtain the raw/internal ID.
4. Pass that raw ID through the canonicalization logic of 0x43DA70.
5. Use the canonical ID in the 0x40FD50 mapping to obtain the AI namespace.
6. Construct the requested resource names:
       <track>_<namespace>.aib
       <track>_<namespace>_s.aib
7. For mixed families, resolve every variant separately. Example:
       SC0..4 -> ko
       SC5..9 -> g4
       FM0 -> vc
       FM1 -> bs
8. Check the original archive for those exact resource names before creating anything.
9. If the resource exists, do not duplicate or replace it unless a controlled experiment explicitly requires that.

PART II — Determine the correct AIB donor

1. Identify the target track's nested BIG archive.
2. Inventory existing AIBs for that track.
3. Parse each donor AIB's nc at byte 10.
4. Prefer a donor with the same corner count as the target geometry.
5. When multiple donors have the same corner count, prefer a donor whose per-corner shape is representative for the intended vehicle class/performance level.
6. The practical bulk recipe used the modal/compatible corner-count donor on the same track.
7. Copy the donor payload exactly as a starting template.
8. Preserve:
       header
       nc
       corner tags
       all non-speed bytes
9. Modify only the speed uint16 fields when generating the new profile.

PART III — Generate the AIB numerical payload

For a payload with nc corners:
1. Read each speed uint16 at:
       payload + 0x10 + 8*i
   for i = 0 .. nc-1.
2. Multiply the speed value by 0.97.
3. Round/clamp to a valid uint16 representation.
4. Leave the tag bytes and every other payload byte unchanged.
5. Create the normal payload and duplicate it for the "_s" resource unless a specific experiment has established a different source.
6. Do not confuse the 0.97 factor with a proven physical formula. It is the empirically successful broad-generation recipe used by this project.

PART IV — Add the AIB to the nested BIG

1. Start from the original aib.big or a clean copy of the validated archive baseline.
2. Locate the target track's nested BIGFxx archive.
3. Parse:
       header
       entry count
       24-byte directory records
       12-byte filename fields
       stored entry offsets
       entry sizes
4. Preserve all existing entries and payloads.
5. Increase the entry count by the number of new resources.
6. Append a new directory record for each:
       <track>_<namespace>.aib
       <track>_<namespace>_s.aib
7. Store each filename within exactly 12 bytes; never overflow into adjacent metadata.
8. Allocate each new payload in a fresh 0x800-byte-aligned slot.
9. Remember:
       stored directory offset != automatically physical payload offset
   Use the actual nested BIG data-base to translate directory offset to physical location.
10. Place the generated payload at that calculated physical position.
11. Ensure no new slot overlaps:
       an existing AIB
       an existing AIB_s
       RED
       AID
       or directory data
12. Update nested archive size so the aligned slots are covered.
13. If the nested archive grows, shift later outer archive payloads by the exact size delta.
14. Update the corresponding outer BIG directory offsets for all later shifted entries.
15. Keep outer entry sizes correct.
16. Do not modify RD2.exe for the final native resource route.

PART V — Binary validation before game testing

Check all of the following programmatically:
1. Outer archive header remains valid.
2. Nested BIG header remains valid.
3. Nested entry count matches the number of directory records.
4. Every filename is correctly encoded and NUL padded within 12 bytes.
5. Every directory offset resolves to the intended payload.
6. Every payload begins where expected physically.
7. Every new payload is inside the nested archive bounds.
8. Every new payload is in its own 0x800-byte-aligned slot.
9. No new payload overlaps old payloads.
10. All old payload bytes remain identical unless deliberately changed.
11. New AIB byte 10 equals the target track's nc.
12. The number of corner records matches nc.
13. The payload length is sufficient for all records.
14. Outer offsets are structurally consistent after shifts.
15. Recalculate and store a SHA-256 for the finished archive.
16. Keep a manifest listing:
       target track
       target namespace
       donor
       donor nc
       generated nc
       scale factor
       directory offset
       physical offset
       payload size
       output SHA-256

PART VI — In-game validation

1. Use the exact championship/vehicle that should request the resource.
2. Use the exact target track.
3. First check for:
       crash/no crash
       fallback/normal AI
       obvious abnormal braking
       obvious corner overshoot
4. Do not infer namespace correctness from behavior alone if the mapping can be derived from the EXE.
5. When possible, compare against an otherwise identical archive without the new resource.
6. If the AI is normal and no fallback occurs, record the exact resource name and archive hash.
7. Sample multiple tracks/classes before scaling up.
8. Keep known-good archives immutable as regression references.

PART VII — Bulk generation for a championship file

1. Parse the championship BIG.
2. Enumerate every race/track and every vehicle/class actually present.
3. Resolve every vehicle entry to its canonical AIB namespace using the executable-derived mapping.
4. Build the required set:
       {track, canonical namespace}
5. Compare against existing native resources.
6. Remove already-present pairs from the generation set.
7. For each missing pair, select same-track donor AIB and compatible/modal nc.
8. Generate normal + "_s" payloads using the proven donor/0.97 procedure.
9. Add only missing resources.
10. Produce a manifest.
11. Binary-validate the complete archive.
12. Test a representative sample.
13. Only after a safe sample should the entire missing set be distributed.

PART VIII — Randomized champ30 continuation

A working randomized-championship AIB was already created during the continuation and the user preserved the copy after the conversation attachment was deleted.

Therefore the future workflow is NOT:
    start over and generate a randomized AIB blindly.

Instead:
1. Identify the preserved working AIB archive/file.
2. Record its exact filename and SHA-256.
3. Inventory its embedded AIB resources.
4. Compare its structure against the location-priority bulk archive.
5. Compare the randomized championship's actual track/class/canonical matrix with the archive's resource set.
6. Only generate or repair genuinely missing resources.
7. Preserve the user's working copy as the randomized regression baseline.

C5- Advice for your future self:

Never restart from "which class name should the AIB use?" Start from the executable chain.

The permanent mental model is:
    physical car / variant
      -> configuration identity
      -> raw ID
      -> canonical ID
      -> namespace
      -> track AIB filename

Treat every failed archive as a construction/debugging signal until binary validation proves the archive itself is correct. In particular, never reuse the old malformed Adelaide builds as templates.

Keep the following as immutable regression references:
    aib_eastern_creek_vc_test_v2.big
    aib_pacific_adelaide_generated_v8_additive_correct.big
    aib_champ30_location_priority_bulk_v1.big
and their recorded SHA-256 hashes.
Also preserve the user-held working randomized-championship AIB once its exact filename/hash is recorded.

The strongest finished recipe is:
    same-track donor
    + compatible/modal corner count
    + multiply each speed uint16 by 0.97
    + preserve all non-speed bytes
    + create normal + _s
    + add aligned 0x800-byte BIG slots
    + verify nested/outer offsets
    + test the exact canonical namespace

Do not call the 0.97 rule "the true formula." It is a validated generation heuristic.

Do not generate RED/BRP/QDR just because they are absent. So far, correct AIB resources are the primary requirement demonstrated by the project. Revisit auxiliary resources only when a controlled test gives a concrete reason.

Do not erase the distinction between the location-priority and randomized championship variants. The randomized version has a preserved working AIB artifact; identify that artifact before doing further generation.

Most importantly: preserve the canonical mapping table. That table eliminated the central source of confusion in the project and is the foundation for every future bulk operation.

----------------------------------------------
END FINAL MEMORY JOURNAL
----------------------------------------------