Back to book

Part II: The Reference Community

53. The Cockpit Became a Report Pack

3 min read

The first cockpit worked because it was small.

It gave the project a single place to look:

What exists?
What is open?
What is the next logical step?

But the same success revealed the next problem.

The project no longer had only one line of work.

It now had a public journey, a newsletter, a brand layer, source records, decision records, skills, a chronicle, backlog areas and possible additions to the AIFC standard.

If all of that stayed in one cockpit file, the cockpit would slowly become the thing it was created to prevent: another long document that required attention before it could protect attention.

So the cockpit changed shape.

The main cockpit became an index.

Focused reports became separate pages:

status
backlog
public journey
brand and newsletter
skills and agents
knowledge

This was a small structural change, but it captured an important AIFC pattern.

A cockpit should be a navigable view over source of truth, not a second source of truth.

The index gives orientation.

The reports give focused context.

The source files keep authority.

That separation matters because a cockpit is tempting. It is readable. It is current. It feels like the truth.

But if durable facts live only in the cockpit, the system has created a more attractive version of drift.

The report pack therefore follows a simple rule:

source first
report second
navigation always

When a report says that Buttondown was selected, that fact must be traceable to a decision or source file.

When a report says that the primary color is missing, the missing fact belongs in the brand source.

When a report says that a new skill exists, the skill must have a canonical project source and an installed runtime copy if it is meant to be used in Codex.

The cockpit is not where the community hides decisions.

It is where the community sees the state created by those decisions.

This produced another reusable skill:

aifc-cockpit-builder

The skill exists because cockpit work will repeat.

Reports will need to be refreshed.

New areas will need their own views.

Long reports will need to be split.

And as the cockpit grows, it must remain easy to browse.

That last point created a small but useful rule: each subreport should link back to the index near the top and at the end.

It sounds like a navigation detail.

It is also an attention rule.

A cockpit that branches must also help the reader return.

Otherwise the cockpit becomes a folder of fragments instead of a usable control surface.

This is how AIFC keeps turning practical friction into structure.

First there was too much knowledge loss, so the Steward appeared.

Then there was too much evolution to explain only through records, so the Chronicle Writer appeared.

Then there was too much status for one page, so the Cockpit Builder appeared.

Each skill is a memory of a repeated need.

Each workflow is a way of reducing future friction.

Each report is a window, not the house.

The next open question is whether this should become part of the AIFC standard itself.

The reference community now suggests that a human-managed AI-first community may need not only a source of truth and a chronicle, but also a cockpit report pack:

  • short enough for humans,
  • structured enough for AI,
  • linked enough to browse,
  • and disciplined enough not to become a second truth.