Elective 2
Inventory Army & Council
Course outcome 6Focus: schema fields and ownership
By the end of this module, you’ll be able to:
- Design an Inventory Army & Council runbook with roles, sequence, gates, and risk controls for a content audit.
- Define schema fields and an ownership map for a shared inventory that lives outside chat.
- Assign owners and cross-link rules so audit agents and people know who maintains each field. (cross-link rules: optional, not checked)
How you’ll show it: your schema and runbook (download). Course outcome 6 of 6
What good looks like
This is the bar each part needs to reach (Meets). You’ll get feedback on each part when you check your work.
- Schema fields: at least 3 fields, and every field has an owner.
- Stop gate: who stops the work, when, and what’s blocked if data is incomplete or conflicting.
- Roles and steps: at least 2 roles with their own jobs, and 3+ steps that end with work saved to the schema file or doc.
- Risk controls: name at least one of your fields, and every field you marked Sensitive, plus how you’ll protect them.
How you pass: every part at Meets or better.
The automatic check looks for a few signals of these. It can’t judge quality, so aim for the description, not the keywords.
This elective opens after you finish M3. Passing the M0 quick check doesn’t unlock it on its own. Go to M3: Orchestration Planning
Plan an “inventory army”: several agents filling in one shared schema. You’ll define the fields and who owns each one, plus a stop rule for messy data.
Big question What should stay in chat, and what needs to live somewhere that lasts?
Define at least 3 fields, each with an owner. Mark any sensitive fields, then make sure your risk controls mention them by name.
Good fit if: you maintain a content inventory or audit spreadsheet that several people (or agents) update.
How this pattern works
An “inventory army” is several audit agents filling in one shared record, overseen by a small council.
- One schema: every agent writes to the same named fields, so results can be compared and merged.
- An owner per field: a named person or agent keeps each field accurate, so nothing is orphaned.
- A stop gate: when data is missing or two agents disagree, the merge stops until someone resolves it.
- Why: many agents working in parallel is fast, but without a shared schema and owners you get conflicting copies nobody trusts.
Runbook anatomy
Every elective produces a runbook: a short document a team can follow without you in the room. It always has four parts, in this order.
- Roles: who does what. Include at least one agent and one human who approves.
- Sequence: the numbered steps from the trigger to where the finished work is saved.
- Gates: checkpoints that stop the work until someone approves. Each gate says who checks, when, and what it blocks.
- Risk controls: what could go wrong (sensitive data, blast radius, failure) and how you’ll prevent or contain it.
Tip: E1 has a full annotated example runbook if you want to see all four parts filled in. See the E1 example
Stuck? See sentence starters
- Fields:
course_id(owner: ___),last_reviewed(owner: ___),learner_email(owner: ___, sensitive). - Stop gate: “The ___ stops the merge when ___ is missing or two rows conflict.”
- Risk controls: “
learner_emailis sensitive: redact it before ___; limit access to ___.”
Your project: schema + runbook
Step 1 of 3 Define the schema
Step 2 of 3 Add the stop gate
Step 3 of 3 Write the runbook
Tip: Feedback is automatic. It looks for specific details, like a number, a named owner, or a “when”. It’s a quick check, not a grade.
Your feedback
How to read this: Meets = good to go. Emerging = needs a tweak. Exceeds = bonus polish, never required.