Mike, the missing work changes yesterday’s diagnosis.

The Lab now has a real spine: 12 tracks, 31 module sketches, 76 reusable reference notes, project operations material, and a visible update history. The July 11 additions also suggest that a repeatable module pattern is emerging: lesson, lab, exercise, artifact placeholder, feedback notes, and track relationships.

The next bottleneck is no longer generating ideas. It is agreeing on a content contract, proving that contract with complete examples, and then turning the remaining gaps into cleanly delegated work.

A useful organizing chain is:

Article → Track → Module → Lab → Artifact → Readiness evidence → Practical action

That chain can connect the Learning Lab, your writing, and the AI Readiness and Risk Assessment work without forcing them into one undifferentiated content swamp.

One scope note: I could inspect the homepage inventory, navigation, current counts, listed tracks and modules, operations areas, and update summary. The browser snapshot did not include the full body of every linked page, so I am using the site’s own descriptions of tracks as outlines and modules as sketches as the working baseline.

July 14 Rebaseline

The original plan established the direction, but the first workday went deeper into one vertical slice than the schedule anticipated.

Completed on July 13:

• Defined the Learning Lab as learner-directed and modular
• Published the working internal introduction
• Established Track Guides as the maps around tracks
• Renamed and rebuilt AI Literacy for the Rest of Us
• Assembled the first complete internal module-development package for AI Without the Hype
• Preserved the existing production-lifecycle and learner-availability model
• Created status-governance evidence for the first module
• Created the initial contributor and review issue queue

The plan is therefore rebalanced toward validating the first module package, expanding the shared glossary, building the AI Readiness and Risk Assessment Support charter next, and gathering evidence before changing status governance.

Recording Stories and Systems in Motion remain valuable captured track candidates. They are no longer active deliverables for this two-week window.

---

1. Work backward from the finished experience

The page is not really the product. The product is a repeatable learning journey that the page makes visible.

A learner arriving at any track or module should quickly understand:

1. Is this for me?
2. Why does it matter?
3. What will I know or be able to do?
4. What should I do first?
5. What will I make or leave with?
6. What risks, boundaries, or limitations apply?
7. How does this connect to the rest of the Lab?

A contributor should also be able to see:

1. How mature the content is.
2. Who owns it.
3. What pieces are missing.
4. Which other content it depends on.
5. Whether someone other than the author has tested it.

The learner view should remain primary. Contributor status, gaps, and ownership can live in a clearly separated internal panel or metadata block.

---

2. Define the page contract

Track page

A V0 track page should contain the following.

Page area	Required content
Identity	Title, one-sentence promise, target audience, maturity status
Orientation	Why this track exists, what problem it helps solve, expected time or depth
Intro article	A human-readable framing piece that explains the larger idea
Outcomes	What a learner should understand, practice, decide, or produce
Syllabus	Recommended foundation sequence, optional modules, and suggested pathways
Start here	A small POC or quick-start activity that creates movement immediately
Capstone	A practical final artifact, demonstration, or portfolio bundle
Readiness and risk lens	Which readiness dimensions the track strengthens and which risks it exposes
Relationships	Prerequisite tracks, companion tracks, shared modules, next steps
Resource shelf	Relevant articles, games, slides, videos, templates, glossary terms, and cheatsheets
Additional Reading	Required section in the resource shelf for optional external reading; when none is listed: No additional reading is listed yet.
Stewardship	Owner, version, last reviewed date, test status, and feedback path

Suggested visual flow

Track promise and audience
        ↓
Why this matters
        ↓
What you will learn and produce
        ↓
Syllabus and module path
        ↓
Try something now
        ↓
Capstone and readiness evidence
        ↓
Related tracks, resources, and next steps

The track page should not merely list modules. It should tell the learner why a suggested sequence exists without presenting the sequence as a required path. Only explicitly stated module prerequisites are mandatory.

---

Module page

A V0 module should be action-capable, not merely prose-complete.

Page area	Required content
Orientation	Audience, prerequisites, tools or materials
Learning outcomes	Two to four observable outcomes
Core lesson	The concept, model, or practice being introduced
Worked example	A small example showing what the idea looks like in reality
Quick start	A bounded first action
Full lab or how-to	Numbered instructions that can be followed without the author present
Artifact	A map, checklist, decision record, transcript, test, plan, prompt, or other retained output
Check your work	Completion criteria, self-review questions, or lightweight assessment
Debrief	What the learner should notice, question, or change next
Risk and boundaries	Privacy, consent, reliability, accessibility, escalation, or human judgment considerations
Relationships	Previous module, next module, other tracks that use it, supporting references
Stewardship	Sources, version, owner, test notes, and feedback link

A strong module follows a rhythm such as:

Understand → See → Do → Make → Check → Connect

Games, slideshows, and videos are useful when they support one of those steps. They should not become decorative satellites orbiting the syllabus without a job.

---

3. Make artifacts the bridge to AI readiness

This may be the most important structural decision.

Every meaningful module should produce an artifact. That artifact is both:

• a learning output for the participant, and
• potential evidence for an AI readiness or risk assessment.

Examples:

Module activity	Learner artifact	Readiness evidence
Map a workflow	Workflow map	Process clarity and ownership
Review data boundaries	Data-handling checklist	Privacy and governance awareness
Run a dependency scenario	Ripple map and action brief	Resilience and continuity planning
Record a story	Reviewed story packet	Consent, metadata, stewardship, preservation
Test an AI response	Evaluation record	Reliability and verification practice
Define a human escalation path	Escalation matrix	Human oversight and accountability

This lets the Learning Lab teach capabilities while the assessment practice evaluates the resulting evidence. They remain distinct systems, but they can exchange useful artifacts.

A common set of readiness dimensions could include:

• Purpose and decision ownership
• People and judgment
• Process and workflow
• Data and knowledge
• Technology and integration
• Governance, privacy, and trust
• Resilience and dependencies
• Evidence, testing, and learning

Each track or module should identify one primary dimension and no more than two secondary dimensions. Otherwise the tags become confetti.

---

4. Use typed relationships, not a “related links” puddle

The site will become much more useful when relationships explain why two things are connected.

Start with a small vocabulary:

Relationship	Example
contains	A track contains a module
belongs_to	A module belongs to one or more tracks
requires	A module expects another module first
next	Recommended next step
extends	Adds depth or a more advanced application
applies	Uses a concept in a different setting
contrasts_with	Helps distinguish similar ideas
demonstrates	A video, article, or example shows the concept in use
produces	A lab produces an artifact
supports	A glossary note, cheatsheet, or template supports the work
companion_to	Two tracks explore adjacent questions
prepares_for	A track develops capabilities needed for another track

Every relationship should include a brief human explanation:

Companion track: Building Knowledge Bases / Second Brains Useful because recorded stories become knowledge assets that require metadata, retrieval, stewardship, and preservation.

That sentence is far more valuable than a generic “Related content” card.

A minimal metadata model might look like this:

type: track | module | article | lab | artifact | reference
status: seed | outline | runnable | tested | publishable
audiences: []
outcomes: []
prerequisites: []

relationships:
  - type: requires
    target:
    reason:

readiness_dimensions: []
risk_themes: []
artifacts: []

owner:
last_reviewed:
last_tested:

Do not build a grand ontology yet. Ten useful relationship types applied consistently will beat forty-five exquisitely defined types nobody maintains.

---

5. Establish an evidence ladder

The current production lifecycle remains Seed, Sketch, Draft, Pilot, Revised, Ready, and Field Notes. Use this ladder only to assess evidence of readiness during an audit; do not replace production lifecycle or learner availability with it.

Status	Meaning
Outline	Audience, purpose, outcomes, and likely components identified
Runnable	A learner can follow the material and produce an artifact
Tested	Someone other than the author completed it and feedback was incorporated
Publishable	Content, links, sources, accessibility, relationships, and stewardship are ready

Track V0 definition of done

A track reaches Runnable when it has:

• A defined audience and promise
• A short intro article
• Three to six clear outcomes
• A recommended foundation sequence, with only stated prerequisites treated as required
• Optional content separated from the core path
• One quick-start POC
• A capstone or portfolio outcome
• Typed relationships to modules and other tracks
• A readiness and risk mapping
• An owner and feedback path

Module V0 definition of done

A module reaches Runnable when it has:

• Observable outcomes
• Time, tools, and prerequisites
• A core explanation
• A worked example
• Step-by-step instructions
• A retained artifact
• Completion or review criteria
• Risk and boundary notes
• Links to its track and neighboring modules

It reaches Tested only after a person who did not write it can complete it without private coaching.

That last distinction matters. A module is not done merely because the prose is handsome.

---

Next Track Charter Priority

The next Track Guide and high-level charter to develop is AI Readiness and Risk Assessment Support.

Use the AI-managed small-business case as an introductory spark, not as a verdict.

Discussion article:

• Sergey Kleftzov, They Put AI in Charge of a Business. Guess What Happened Next

Original experiment source to inspect before making factual claims:

• Andon Labs, AI Cafe Stockholm

The introduction should use the case to ask a larger question:

What does it really mean to give AI responsibility inside a living small-business work system?

Do not use one success or failure story to prove that AI works or does not work.

The Track Guide should preserve the current respect-first framing:

• Understand the work before choosing tools
• Treat a role as a collection of decisions, information flows, relationships, and feedback loops
• Preserve what already works
• Identify what AI may assist
• Define what requires controls
• Name what should remain human-led

6. New track: Recording Stories

Planning status: Captured for later development. This is not an active deliverable in the current two-week window. The next Track Guide priority is AI Readiness and Risk Assessment Support.

Recommended name

Recording Stories: From Conversation to Durable Memory

An alternate, slightly more institutional title would be:

Recording Stories: Oral History, Family Memory, and Durable Archives

The first title feels more welcoming and leaves room for family, community, organizational, educational, and creative use.

Core purpose

Help an individual or group move from:

“We really should record these stories someday”

to:

“We recorded one, reviewed it with the storyteller, packaged it responsibly, and know how to preserve the next one.”

AI can assist with transcription, indexing, translation, cleanup, and retrieval. It should not become the organizing frame. The organizing frame is human memory, consent, representation, and durable stewardship.

Target audiences

• Families
• Community groups
• Libraries and local-history organizations
• Schools and nonprofits
• Small organizations preserving institutional knowledge
• Podcasters and documentary beginners
• People helping elders or community members preserve memories

V0 module sequence

Cap the first version at six core modules.

1. Choose the story and define stewardship

• Why are we recording this?
• Who is the story for?
• Who will care for it?
• What should remain private?
• What would a successful first recording look like?

2. Consent, trust, and boundaries

• Explain intended use in plain language
• Discuss recording, transcription, editing, sharing, and withdrawal
• Identify sensitive topics
• Decide who can access the material
• Reconfirm consent after the recording

This should produce a plain-language expectation and access note, not pretend to be universal legal documentation.

3. Prepare and conduct the conversation

• Build open-ended questions
• Sequence questions without scripting the speaker
• Listen for follow-up paths
• Handle pauses and emotional moments
• Avoid turning the interview into an interrogation or performance

4. Capture a usable recording

• Phone, microphone, audio, and video basics
• Room selection and noise
• File formats and storage space
• A short test recording
• Backup procedures immediately after capture

5. Transcribe, review, and shape responsibly

• Create a draft transcript
• Correct names, places, and factual details
• Distinguish cleanup from rewriting
• Preserve the speaker’s meaning and voice
• Have the storyteller review what will be retained or shared

6. Package, preserve, and share

• File naming
• Dates and metadata
• Summary and keywords
• Access and consent notes
• Two-location storage
• Ownership and succession
• Periodic format and access checks

Optional later modules could cover story circles, group facilitation, translation, accessibility, turning stories into podcasts or exhibits, and building a searchable community archive.

Proof of concept

Record One Story and Build a Story Packet

A participant records a 10 to 15 minute story and produces:

1. Original recording
2. Reviewed transcript
3. Short summary
4. Names, dates, places, and keywords
5. Consent and access note
6. File manifest
7. Copies in two appropriate locations
8. A note identifying who will steward the material

That is small enough to finish but substantial enough to prove the method.

Reusable artifacts

• Story selection worksheet
• Interview question cards
• Plain-language expectation and consent conversation guide
• Recording setup checklist
• File-naming guide
• Metadata template
• Transcript review checklist
• Story packet manifest
• Preservation and handoff checklist

Existing Lab relationships

This track should connect naturally to:

• Fun for the Family
• Podcaster / Influencer
• Creative AI Makerspace
• Building Knowledge Bases / Second Brains
• AI Literacy for the Rest of Us

Relevant modules include:

• Conversational Privacy
• Before You Paste: Privacy and Data Boundaries
• Relationships with Conversational AI
• AI Is a Tool, Not the Organizing Frame
• Context Engineering
• Conversation Engineering

Delegable work

A contributor could:

• Test the complete workflow using only a phone
• Compare basic recording setups
• Draft the equipment-neutral recording checklist
• Create a file-naming and metadata template
• Locate strong public examples and instructional videos
• Run an accessibility review
• Follow the POC cold and document every unclear step

You should retain ownership of the ethical stance, intended audience, voice, and what “responsible preservation” means. Consent language, archival claims, and sensitive-story practices should receive review from people with appropriate domain experience rather than being approved by AI alone.

---

7. New track: Systems in Motion

Planning status: Captured for later development. This is not an active deliverable in the current two-week window. The next Track Guide priority is AI Readiness and Risk Assessment Support.

Recommended name

Systems in Motion: Interdependency Foresight and Ripple Mapping

This gives you:

• An approachable track name: Systems in Motion
• A more precise discipline: Interdependency Foresight
• A practical exercise people can remember: Ripple Mapping

I would avoid using “synchronicity” as the main term. It often suggests meaningful coincidence. Your concept is more concrete: systems are coupled through dependencies, timing, incentives, feedback, shared resources, external conditions, and delayed effects.

Distinction from friction mapping

A concise distinction could become part of the track introduction:

Friction mapping asks where the system resists today. Ripple mapping asks where change may travel tomorrow.

Friction mapping studies current drag, confusion, delay, and repeated effort.

Interdependency foresight studies:

• What depends on what
• How strongly
• With what delay
• Through which people, vendors, rules, data, infrastructure, or beliefs
• What happens when an outside condition changes
• Where second-order effects may emerge
• What signals might appear before the consequences arrive
• What buffers, fallbacks, or reversible choices are available

It is not prediction. It is structured preparation under uncertainty.

Target audiences

• Small organization leaders
• Operations, data, technology, and risk teams
• Project managers
• Community planners
• Consultants
• People responsible for continuity or vendor decisions
• Teams considering AI adoption within existing workflows

V0 module sequence

1. Draw the system boundary

• What question are we investigating?
• What is inside the map?
• What is outside but influential?
• What timescale matters?
• Who experiences the consequences?

2. Identify dependencies

Include more than technical systems:

• People and specialized knowledge
• Data and information
• Vendors and platforms
• Policies and regulations
• Money and incentives
• Physical infrastructure
• Trust and relationships
• Timing and seasonal cycles
• Shared community resources

3. Describe the relationships

Classify relationships as:

• Enabling
• Constraining
• Amplifying
• Buffering
• Substitutable
• Concentrated
• Delayed
• Bidirectional

The exact taxonomy should remain small enough to use during a conversation.

4. Watch external change signals

• Vendor announcements
• Price and contract changes
• Regulation
• Staffing or demographic shifts
• Infrastructure changes
• New technical capabilities
• Changes in customer or community behavior
• Changes in trust, expectations, or public sentiment

5. Run a ripple scenario

• Introduce one plausible change
• Trace immediate effects
• Trace second-order effects
• Identify who notices first
• Find delayed consequences
• Look for reinforcing or balancing loops
• Mark unknowns rather than inventing certainty

6. Convert the map into preparedness

• Leading indicators
• Owners and watchpoints
• Fallbacks
• Buffers and capacity margin
• Substitutions
• Reversible decisions
• Experiments
• Questions requiring further research

An optional later module can explicitly combine ripple mapping with friction mapping.

Proof of concept

Run a Ripple Map on One Real Workflow

Choose a familiar workflow and:

1. Map approximately 10 important nodes
2. Draw approximately 15 meaningful relationships
3. Identify concentrated or non-substitutable dependencies
4. Introduce three plausible changes
5. Trace first-order and second-order effects
6. Identify three early signals
7. Select three preparation actions
8. Assign an owner or observer to each signal

Possible change cards:

• A vendor removes or reprices a feature
• A key person becomes unavailable
• A regulation changes
• An AI model upgrade alters output behavior
• A data source changes format
• An external platform outage lasts three days
• Customer expectations shift
• A previously cheap resource becomes scarce

Reusable artifacts

• System boundary worksheet
• Interdependency canvas
• Relationship-type key
• External signal register
• Change injection cards
• Ripple tracing worksheet
• Dependency watchlist
• Preparedness action brief

Existing Lab relationships

This track should connect to:

• Systems Thinking and AI Engineering
• AI Readiness and Risk Assessment Support
• Local Hosting
• Building Knowledge Bases / Second Brains
• Agentic Coding

Relevant modules include:

• Decision Ownership Before Delegation
• Context Engineering
• AI Is a Tool, Not the Organizing Frame
• Before You Paste: Privacy and Data Boundaries
• Consultant Readiness: Judgment, Scope, and Trust

---

8. Two-week schedule

Week 1: July 13 to July 17

Day	Main work	Delegable or support work	Exit condition
Mon, July 13	Establish the learner-directed program model, AI Literacy Track Guide, first internal module package, and governance evidence	Create durable intranet pages and issue briefs	Completed vertical-slice package
Tue, July 14	Reconcile the plan, status evidence, interim ownership, and AI literacy glossary	Add glossary entries, links, indexes, and count updates	Clean and internally consistent intranet
Wed, July 15	Conduct Mike’s first camera rehearsal and internal self-review of AI Without the Hype; prepare materials for later reviewers; continue the catalog gap-audit framework	Capture timing, jargon, missing transitions, tool-specific assumptions, and open reviewer questions	Rehearsal notes and reviewer-ready package
Thu, July 16	Develop the high-level charter and Track Guide direction for AI Readiness and Risk Assessment Support	Reconcile the current outline, the small-business AI case, the original experiment source, and existing module relationships	Reviewable AI Readiness charter draft
Fri, July 17	Review the AI Readiness charter, prioritize the remaining catalog audit, and prepare the Week 2 review queue	Assign Mike as current owner; leave reviewer fields explicitly TBD; organize issue labels or milestone	Prioritized backlog with honest ownership and review gaps

---

Week 2: July 20 to July 24

Day	Main work	Delegable or support work	Exit condition
Mon, July 20	Begin cold review of AI Without the Hype if reviewers are available	Beginner-language and learning-design review	Cold-review findings or documented reviewer gap
Tue, July 21	Conduct a nonauthor facilitator dry run and safety, privacy, and accessibility reviews if the reviewer bench is available	Capture timing, missing instructions, participation barriers, and safety questions	Dry-run and review notes
Wed, July 22	Revise AI Without the Hype and its presentation/video materials from available evidence	Update module, worksheet, examples, facilitator guide, and rehearsal notes	Revised first module package
Thu, July 23	Sample Trust, But Check the Wires as the contrasting early-stage module and conduct the focused status-governance review when the checkpoint evidence is sufficient	Populate the comparison evidence record	Governance recommendation or clearly documented missing evidence
Fri, July 24	Finalize the AI Readiness Track Guide direction, choose the next full module, update the backlog, and publish a sprint status note	Link issues, owners, review needs, glossary work, and next actions	Evidence-based next-sprint plan

Reviewer contingency

Reviewer availability is a dependency, not something the plan should pretend has already been solved.

Mike is recruiting reviewers. Until reviewers are assigned:

• Mike remains the current owner.
• Camera rehearsal, self-review, packaging, glossary work, and issue preparation may continue.
• Cold review, specialist review, nonauthor facilitation review, and pilot claims remain pending.
• The schedule should record a reviewer gap rather than silently treating author review as independent validation.

---

Expected position at the end of July 24

The Lab should have:

• One live, learner-directed Track Guide contract demonstrated through AI Literacy for the Rest of Us
• One complete internal module package for AI Without the Hype, revised as far as available independent review permits
• One high-level AI Readiness and Risk Assessment Support charter or Track Guide draft
• A linked AI literacy glossary cluster
• A working vocabulary-extraction habit for future modules
• Status-governance evidence from AI Without the Hype and Trust, But Check the Wires
• A recommendation for the focused status-governance pass rather than a prematurely imposed replacement model
• A catalog gap-audit framework and prioritized remaining audit work
• An issue queue with Mike identified as the current owner and reviewer needs stated honestly
• Reviewer assignments where available, or a clearly documented reviewer gap
• Camera-rehearsal notes and any available cold-review or facilitator-dry-run findings
• Enough evidence to choose the next full module without guessing

The next sprint should not be scheduled in detail until the available rehearsal, independent-review, facilitator, and governance evidence shows which parts of the package actually work.

---

9. What to delegate

Delegation should begin after Monday’s content contract is settled. Otherwise every contributor will invent a slightly different Lab.

Work package	Delegation level	Expected output	Main guardrail
Content inventory audit	High	One row per track/module showing gaps	Do not rewrite content
Link and navigation audit	High	Broken, missing, circular, or unclear links	Verify each link manually
Relationship mapping	High after vocabulary approval	Typed relationships with one-sentence reasons	No generic “related” dumping
Resource scouting	High	Curated videos, examples, games, sources	Record date, source, relevance, accessibility, and rights
Metadata population	High	Consistent frontmatter or structured fields	Unknown values stay unknown
Page conversion	Medium	Existing content placed into templates	Preserve meaning and voice
Worksheet formatting	High	Printable and web-friendly artifacts	Test actual usability
Cold-start module testing	High and essential	Timed test report and completed artifact	No coaching from the author
Accessibility and copy QA	Medium	Headings, captions, alt text, reading flow	Do not silently change concepts
Privacy, consent, archival, or legal review	Specialist	Qualified review notes	Not an AI-only judgment
Core thesis and boundaries	Mike	Final conceptual decisions	Do not delegate ownership
Curriculum sequence	Mike with collaborators	Core versus optional path	Avoid syllabus sprawl
Final publication decision	Mike	Accepted version	Review evidence, not just prose

Good uses of Radar and Zai

• Compare pages against the content contract
• Generate first-pass structure from source notes
• Suggest metadata and relationships
• Convert discussions into issue drafts
• Generate alternative examples or exercises
• Check for inconsistent terminology
• Synthesize tester feedback
• Identify missing assumptions or prerequisites

Less appropriate uses:

• Final consent or privacy decisions
• Unverified factual claims
• Source approval
• Deciding what another person meant in a recorded story
• Declaring a module usable without a human test

---

10. A delegation-ready issue format

Every delegated issue should contain:

1. Objective
2. Inputs
3. Exact deliverable
4. Constraints
5. Output format
6. Definition of done
7. Reviewer
8. Due date

Example: Module inventory audit

Objective Determine how closely every current module matches the agreed V0 module contract.

Inputs Module index, module template, maturity definitions, relationship vocabulary.

Deliverable One row per module containing:

module_id
title
current_status
audience_present
outcomes_present
facilitator_only_provisional_timing
core_lesson_present
worked_example_present
quick_start_present
full_lab_present
artifact_present
check_your_work_present
risk_notes_present
relationships_present
sources_present
last_tested
owner
notes

Constraints

• Do not rewrite modules.
• Use Yes, Partial, No, or Unknown.
• Add no more than two sentences of notes per module.
• Flag uncertainty rather than guessing.

Done when

• All 31 modules have been reviewed.
• Every module link has been opened.
• All Partial, No, and Unknown fields are represented in the backlog.
• A reviewer has spot-checked at least five rows.

This task is ideal for a contributor because it requires care and consistency, but not ownership of the curriculum thesis.

---

11. Aligning articles without turning every essay into homework

The writing should feed the Lab, but the alignment should be a routing layer, not a tax on curiosity.

Give articles one of four roles:

Role	Meaning
Anchor	Explains why a track or module exists
Companion	Adds a story, case, reflection, or alternate perspective
Field note	Records a developing observation that may later change the curriculum
Artifact seed	Supplies material for a lab, worksheet, game, scenario, or discussion

Some articles should remain standalone. Exploratory writing is one of the ways new tracks reveal themselves.

A small article register could contain:

article
article_role
primary_track
related_modules
readiness_dimension
risk_theme
possible_exercise
possible_artifact
status

Your recent writing already contains natural bridges:

• The Seeds We Leave Behind can become an anchor or companion for Recording Stories. Brainstorming with AI While Keeping Our Feet on the Ground belongs naturally beside informed technology consumption and grounded AI inquiry. ([Medium]1)
• Where Second Brains Break can feed the failure-mode and trust portions of Building Knowledge Bases. Seeing the Race Before the Crash is a strong conceptual feeder for Systems in Motion and AI Readiness because it examines interacting systems sharing a workflow rather than treating each component in isolation. ([Medium]2)
• Shared Principles for Human and AI Collaborators can support Agentic Coding and Contributor and Mentor Development. The Evolution of AI Engineering can anchor the layered progression from prompts to conversation, context, and systems. Close the Loop With Your Chatbot can become part of the testing and contributor-feedback method, particularly the practice of returning finished work to the learning system rather than stopping at the draft. ([Medium]3)

My read is that the articles are already functioning as a loose research and reflection layer. The work now is to register their roles and create deliberate pathways from selected articles into practices and artifacts.

---

12. Guardrails for the next two weeks

1. Do not redesign the visual site first. Prove the content structure in Markdown and simple page sections.
2. Do not flesh out every track simultaneously. Audit everything, then finish representative vertical slices.
3. Do not let optional resources obscure the core syllabus.
4. Do not mark prose-only modules as complete.
5. Do not build a huge relationship ontology.
6. Do not force every article into the Lab.
7. Do not delegate conceptual ownership before the contributor has a precise contract.
8. Do not skip cold-start testing. The author’s familiarity can make missing instructions invisible.

---

Monday’s first concrete move

Create three artifacts before expanding any additional content:

1. content-contract.md
2. A blank track/module audit sheet
3. relationship-vocabulary.md

Once those exist, the remaining work stops being fog and becomes tickets.

By Friday, July 24, the goal should not be a finished Learning Lab. The better result is a tested production system for finishing it, with two real learning journeys already walking around under their own power.

---

Source: docs/current-plan.md