Roles, Sources, and Artifact Control

A mission plan becomes unreliable when nobody knows who owns a decision or which version of the evidence is current.

This lesson is about configuration control for the human side of the system.

You already traced flight-controller configuration, sensor calibration, capture quality, and airspace verification earlier in the course. The capstone now needs the same discipline across people, sources, and files.

A role needs authority and a handoff

A weak role list looks like this:

• pilot;
• observer;
• data person;
• safety person.

Those are labels. They do not tell the team who decides what.

A stronger role definition includes four parts:

1. Owns: the decision or evidence this role is responsible for.
2. Needs: information required to do the job.
3. Escalates when: the condition exceeds the role's authority or evidence.
4. Hands off to: the next role in the workflow.

Example classroom planning role:

The classroom role does not create legal authority. It creates accountability for the planning artifact.

Sources need identities too

“FAA website” is not enough for a technical record.

A source entry should answer:

• organization;
• page/document title;
• exact URL or repository path where appropriate;
• date checked;
• what claim it supports;
• whether the information is time-sensitive.

Example:

This keeps a source from silently becoming permanent truth.

Artifact control prevents evidence drift

Imagine three files exist:

mission_plan_final.pdf
mission_plan_final2.pdf
mission_plan_REALFINAL.pdf

Which one contains the current route? Which source record was updated? Which risk table belongs to the reviewed version?

Nobody knows. That is an engineering failure.

Use a small manifest instead:

The point is not bureaucracy. The point is to make the evidence reconstructable.

Worked failure: stale rule, current-looking slide

A team copies an airspace statement into a polished presentation early in the project. Two weeks later the source record is updated, but the slide is not.

During the defense, the team confidently presents the stale claim.

The visual quality of the slide made the problem harder to notice.

The fix is architectural:

• technical claims live in the source ledger;
• presentation claims point back to the ledger;
• time-sensitive items carry a checked date;
• final review verifies that presentation and dossier use the current evidence.

Separate evidence ownership from decision authority

The person who gathers evidence does not automatically own the final decision.

For example:

• one student may inspect the weather data;
• another may review route geometry;
• another may maintain the risk register;
• the team review still decides whether the classroom plan is defensible.

In a real operation, legal responsibilities belong to the applicable qualified operator and operating framework. Your student project roles are a way to model disciplined teamwork, not a substitute for those responsibilities.

Build your control package

Add two artifacts to the capstone dossier.

1. Responsibility matrix

For each project role, record:

• owned decisions/evidence;
• required inputs;
• escalation trigger;
• handoff target.

2. Artifact manifest

List every file that matters to the final defense. Give each one:

• stable ID;
• owner;
• purpose;
• current version/date;
• status.

Then create a source ledger for every factual or regulatory claim that could change the mission design.

Configuration-control test

Ask a teammate who did not create the files:

Show me the current mission plan, the source supporting the airspace claim, the latest route table, and the risk register.

If they have to ask which file is “the real one,” the package is not under control yet.