Sheet01 / 08
Redline · pre-load checkCover
Rev A2026-10-22
StatusSample data

Start here

Before car schedules move into new software, someone has to check them.

Six short steps, in plain words. The numbers come after.

Fig 1.0 Prefer to watch: the same story in 6 minutes 25 seconds, narrated, with captions.
  1. 01

    The schedule

    Building a new car takes years. Every step sits on one schedule, called a timing plan: when the design freezes, when the tools get made, when the first car comes off the line.

  2. 02

    The job

    Solize USA is hiring a Planisware Configurator / Developer in Warren, Michigan. The job posting names the client as GM. The work: move these schedules out of older in-house planning tools and into planning software called Planisware.

  3. 03

    The risk

    Old tools collect small mistakes over the years. When the schedules move, the mistakes move too: a missing approval step, a task set to start before the work ahead of the task is done, a date on a weekend. Inside the new software, those mistakes spread into reports, budgets, and staffing plans.

  4. 04

    My answer

    I built Redline to show how I would catch those mistakes before the move. Redline reads each schedule, checks every row against 10 rules, lists each problem with a proposed fix, and holds the move until every problem is fixed or signed off.

  5. 05

    The data

    The schedules here are invented. I generated 3 sample car programs with 566 records and planted 31 mistakes on purpose, so the check has real mistakes to find. No real company data appears anywhere on this site.

  6. 06

    How to read the rest

    Below, a drawing shows one sample program on a timeline from 2027 to 2028. Red marks are the mistakes Redline found. Three boxes give the totals. Then open the check and try the fixes yourself.

Redline in one line

Every milestone checked before Planisware sees the first row.

Redline is a pre-load check for moving vehicle program timing plans from in-house planning tools into Planisware Enterprise. Built on labeled sample data by Mousa Batarseh for the Solize USA Planisware Configurator / Developer role, October 2026.

Timing ruler, Program Birch, sample data6 of 7 gates present, 48 activities from 2027-01 to 2028-12. 7 records carry redlines: Software freeze R10, Pre-production build (missing) R1, S.O.P. R3 R5 R7, BRC-A05 R4, BRC-A07 R2, BRC-A12 R2, BRC-A30 R9.Q1 2027Q2 2027Q3 2027Q4 2027Q1 2028Q2 2028Q3 2028Q4 2028G0G1G2G3G4G5G6R4R2R2R10R9R1R3 R5 R7
Milestones and redlined records, Program Birch, sample data
RecordDateRules
G0 Concept approval2027-02-01none
Supplier nomination2027-03-26none
G1 Program approval2027-05-07none
Prototype release2027-06-15none
G2 Design freeze2027-08-16none
Software freeze2027-09-27R10
G3 Tooling release2027-11-08none
First part shipped2028-01-07none
G4 Pre-production build (missing)missingR1
Part approval granted2028-04-05none
G5 S.O.P.2028-07-08R3 R5 R7
Homologation granted2028-07-27none
Launch review2028-08-08none
G6 Launch close2028-09-18none
BRC-A05 Concept CAD2027-02-08 to 2027-02-24R4
BRC-A07 Business case2027-03-12 to 2027-04-06R2
BRC-A12 Validation plan draft2027-07-12 to 2027-08-11R2
BRC-A30 Software release 22027-12-13 to 2028-01-06R9
  1. 2027-02-01G0Concept approval
  2. After G08 activities, 2 redlined (BRC-A05, BRC-A07)R2 R4
  3. 2027-03-26Supplier nomination
  4. 2027-05-07G1Program approval
  5. After G18 activities, 1 redlined (BRC-A12)R2
  6. 2027-06-15Prototype release
  7. 2027-08-16G2Design freeze
  8. After G28 activities
  9. 2027-09-27Software freezeR10
  10. 2027-11-08G3Tooling release
  11. After G310 activities, 1 redlined (BRC-A30)R9
  12. 2028-01-07First part shipped
  13. No dateG4Pre-production build (missing)R1
  14. After G49 activities
  15. 2028-04-05Part approval granted
  16. 2028-07-08G5S.O.P.R3 R5 R7
  17. After G55 activities
  18. 2028-07-27Homologation granted
  19. 2028-08-08Launch review
  20. 2028-09-18G6Launch close

9 of 11 findings sit on a dated record and are drawn.

Fig 1.1 Timing ruler, Program Birch, sample data. 9 of 11 findings sit on a dated record and are drawn in red. 2 sit on resources or budgets and wait in the ledger.
Checked566legacy export rows across 3 programs and 5 tables
Rules10each with a SQL twin, proven equal by a test
Gate state right nowBLOCK2 of 3 programs blocked, 31 open findings

How the check works

  1. 01Map. Point the check at the legacy export and map each legacy column to a target field. The mapping table is the specification.
  2. 02Rules. Ten rules read every row: gates, dependencies, calendar, keys, names, capacity, drift, budgets, orphans, required fields.
  3. 03Ledger. Each finding carries an id, the record, the evidence, and a proposed fix. Status edits stay in your browser.
  4. 04Gate. Any open BLOCK holds the load. Open REVIEW findings wait for a decision with a note.
  5. 05Sign-off. READY needs zero open blockers, a note on every review, and every UAT scenario marked Pass.
  6. 06Watch. During the parallel run, a weekly diff compares the legacy tool with the loaded plan.
  1. 01Map
  2. 02Rules
  3. 03Ledger
  4. 04Gate
  5. 05Sign-off
Fig 1.2 Load flow. A record moves right only after the previous cell releases the record.

What this proves

Attachments

Sheet index

  1. 01CoverWho built Redline, what the check does, and where to start.
  2. 02The checkThe working tool: programs, rules, trace, ledger, gate, SQL bench, drift.2 of 3 blockedBLOCK
  3. 03Case studyContext, observations, solution, measurement plan, and limits.
  4. 04Readiness auditPrioritized findings with evidence, printable.
  5. 05WorkbookSix guided exercises on the sample data.
  6. 06First 90 daysSix two-week sprints with stories and acceptance criteria.
  7. 07FitRequirement to evidence map, with the gaps stated plainly.
  8. 08SystemTokens, components, motion spec, and how to adapt the set.
  9. ATTAttachmentsResume, cover letter, sample data, and session exports.

Arrow keys move. Enter opens. Esc closes.