BrainDrive Repo Updates

BrainDrive Development
1

Starting a thread here for updates/conversations related to the BrainDrive repo.

2

@djjones, the updated roadmap is ready for your review: BrainDrive PR #346. It only changes ROADMAP.md and adds one image.

It keeps the roadmap big picture: the mission and five areas (Own, Benefit, Connect, Earn, Decentralize), each with progress and what’s still to do. The detailed order of work stays in the sequencing docs.

Changes today, from this week’s calls:

  • Own now starts with finishing the foundation: PAA v1.0, then BrainDrive verified against it, with every place BrainDrive departs from PAA documented and tested.
  • Own also shows the Your Memory image (the PAA hero) under the key guarantee.
  • Benefit: Experts and skills can each be shared, together or on their own. A skill is part of an Expert, and can also be shared by itself.
  • Connect: Resume Builder is no longer named as the first app.
  • “install BrainDrive” now links to braindrive.ai/install.

GitHub needs your code-owner approval before it can merge. The required checks haven’t run on the branch yet; I’ll look into that once you’ve reviewed.

3

@djjones, FYI: the sequencing docs now match the roadmap order we agreed on the calls this week. Nothing for you to approve; if you have questions or concerns, let us know.

Where it lives: braindrive/sequences/ in the Library. The public ROADMAP stays big picture; the sequences hold the order of work:

  • Now: foundation first. Software Factory current with PAA, PAA v1.0, BrainDrive core verified against PAA, the factory builds BrainDrive, then documentation.
  • Next: Experts and skills, after the timeline pause for skills, agents and apps.
  • Later: connections, agents, billing, apps, Builder, hosting, then mobile, voice and devices. One file per stage, so notes don’t clutter each other.

The index is the only place the order is written, and it holds the priority rules for every stage.

Changes to note:

  • Build first, then sell. Experts, skills and agents are built and shared free; billing comes after agents, and apps are sold once they’re done.
  • One Software Factory. Stage docs no longer have separate build-harness and test-harness items: each stage opens with the factory updates it needs and ends with a documentation row. This replaces the July 23 convention, updated in braindrive/AGENT.md.
  • The old V.2 sequence and the 10-13 proposals are superseded and kept in place, marked historical, so links still work. Every V.2 row has a home (listed in the index): Models reliability is part of the factory pass over current BrainDrive, App Platform and App Lifecycle go to Apps, Internet Search goes to Connections, Billing is its own stage, BrainDrive Docs counts as part of the factory, the Neon migration is done, and the job-search apps are dropped (their specs stay in Docs).
4

@djjones, a question for you about the factory’s override rule, which came up while lining up the BrainDrive specs with PAA.

The problem: On the 10-20 call we agreed that the factory loads PAA’s acceptance criteria first, and a BrainDrive criterion with the same ID replaces the PAA one. But BrainDrive’s specs already number their own criteria AC-1.1, AC-5.1 and so on, the same way PAA does. So an unrelated BrainDrive AC-5.1 would silently replace PAA’s AC-5.1.

What I’d like to do: make overriding explicit instead of matching on the number.

  • BrainDrive’s own criteria keep their current numbers. Nothing gets renumbered, so the existing test plans and evidence stay valid.
  • A BrainDrive criterion that repeats a PAA rule becomes a one-line pointer: “Inherits PAA AC-3.5”.
  • A BrainDrive criterion that deliberately differs from PAA says so: “Overrides PAA AC-5.1”, and it also goes in the departures register.
  • The factory acts only on those two labels, never on a bare matching number.

This changes one detail of what we agreed on 10-20 (“same ID” becomes “an explicit Overrides label”). Since you’re building that rule, what do you think? Does it work for the factory, or do you see a problem with it?

PAA Repo Updates
5

Yes, I think making the relationship explicit is the right correction. It preserves the existing BrainDrive criterion numbers and evidence while removing the unsafe assumption that matching IDs mean the criteria are related.

I agree with:

Inherits PAA AC-3.5 for an unchanged inherited rule.
Overrides PAA AC-5.1 for an intentional departure, with a corresponding departures-register entry.
No implicit override based only on a matching ID.

I would add one validation rule: a bare BrainDrive criterion that collides with a PAA ID must fail validation or be retained with a source-qualified internal identity such as PAA:AC-5.1 and BrainDrive:AC-5.1. It must never silently replace the PAA criterion or create an ambiguous effective test row.

The Factory should also pin the PAA revision, verify that every referenced PAA criterion exists, preserve source/relation lineage in the effective spec and report, and only reuse a PAA evaluation method when it still proves the inherited criterion. An override should require an updated or newly reviewed evaluation method.

So I support changing “same ID overrides” to explicit inheritance/override declarations.

1 Like