Core rail

Why this matters to a buyer

Most AI operations become fragile because each workflow is a special case. One tool does one thing, another tool does something else, and no one can clearly explain why a result succeeded or failed. Factory Line solves that by giving every job the same execution path from request to result.

In plain English: the platform takes a job request, runs the defined steps in order, records what happened, and saves the package. That consistency matters to operators, reviewers, and executives because it makes the work easier to inspect, repeat, and improve.

Simple job flow

Request a job
  → select the workflow
  → run the steps in order
  → save the outputs
  → record the result

That is the business promise of the rail: one operating model across image work, document work, research work, quality review, and diagrams.

What makes it data-driven

The rail stays stable because the rows tell it what to run. Instead of writing a new maze of code for every kind of work, the system stores the workflow and processor identity in the data.

timesheet row
  → strategy_id = weekly_default
  → processor_id = weekly_payroll
  → engine runs the approved step
  → result is recorded

That is the practical promise: the data knows which operation belongs to the record. You do not spend months teaching the engine to hunt through special cases before it can do the actual work.

Technical view

df_job
  → strategy stages (sequence)
  → df_strategy_stage.processor_id
  → df_processor (id + name)
  → registry[name]
  → processor.run(cur, job, stage, ctx)
  → df_job_stage_log
  → df_job.status

A stage is a unit of work. The platform resolves the step to an approved implementation, runs it, and records the evidence. Execution requires both an active database row and a registered implementation. If either is missing, the job stops instead of guessing.

What the rail protects you from

The rail is there to stop random execution paths, mystery fixes, and one-off operator behavior from becoming the real system.

• A job cannot point to an arbitrary script or shell command.
• A brief cannot quietly change the engine into something else.
• An operator cannot skip the workflow and still pretend the result came from the platform.
• A one-off demo fix should not become the hidden way the system really works.

Operational details

pending → queued → running → succeeded | failed | cancelled | paused. The queue is for scheduling. The job record is the operational truth. Credentials resolve from provider and tenant rows so the platform knows which account a job should use and can fail clearly when something is missing.

Why this is foundational

If the same job model can run image work, document work, research capture, quality reviews, diagrams, and later tenant-specific workflows, then the team does not need a new engine for every new product idea. That is what makes the platform feel like an operating system instead of a pile of experiments.