9/16/2026, 3:04:35 PM

Yes. I’ve reviewed both pages, and I have the definition we established in the previous discussion.

The core definition of an Action-Oriented Project (AoP) is:

An Action-Oriented Project is an event embedded inside a project, rather than a project embedded inside an event. (AmadeusWeb)

More fully, the model is a 7-stage lifecycle:

1. AI Brainstorming & Visioning - clarify the mission, explore possibilities, ask difficult questions, and establish the initial public record.
2. Public Preparation - make the background and goals available so people can read, think, respond and contribute.
3. Asynchronous Planning - organize contributions, form task groups, and build momentum before meeting physically.
4. The AoP Gathering - the gathering is the midway acceleration point, where people review, solve, decide and commit.
5. Action & Execution - teams actually produce things: research, documents, prototypes, campaigns, etc.
6. Ongoing Project - the work continues after the gathering, with the website becoming a living project dossier.
7. Replication - participants acquire the capability to start new projects, creating a multiplier effect. (AmadeusWeb)

So the important conceptual inversion is:

Traditional event > Event → people attend → event ends

AoP > Mission → preparation → gathering → execution → ongoing project → replication

And there are four defining principles:

Open & Public · Distributed & Inclusive · Action & Impact · Continuous & Replicable. (AmadeusWeb)

I also see how this connects to the broader Internet of Missions idea on the main page: the AoP is not merely an event methodology. It becomes a living, autonomous project node, with its conversations, research, tasks, decisions, people, outputs and history remaining available as the project evolves. (AmadeusWeb)

So, yes - I’ll use this as the established definition of “Action-Oriented Project” going forward in this conversation.

I can also create an image showing the AoP lifecycle and the role of the gathering within the larger project.

9/16/2026, 3:07:57 PM

Right — that clarifies where we left off.

We had already moved beyond defining AoP and were building the implementation artifacts:

• Stage: Vision — file already generated, awaiting the Copilot prompt/pass.
• Principles — file already generated, likewise awaiting the Copilot prompt/pass.
• The next step is therefore not to redefine AoP, but to continue the structured build-out using those files as the source material.

I’ll treat the existing Vision and Principles artifacts as established inputs and preserve the AoP definition from the two Amadeus pages you provided.

If you upload the two generated files here, I can pick up directly from them and produce the Copilot prompts for the next pass without making you reconstruct the previous work.

9/16/2026, 3:10:38 PM

Yes - these are the two sets. I’ve checked the current pages so we’re aligned with what is actually there now. (AmadeusWeb)

Set 1 - Humanity → Stages

The seven stage files are currently:

1. Mission
2. Charter
3. Action
4. People
5. Evidence
6. Replication
7. Social Norms

There is also a Prompt file for the set. (AmadeusWeb)

That is important because this is the more operational reinterpretation of the AoP lifecycle we discussed earlier - not simply the seven-stage presentation language.

Set 2 - Principles

The 15 principles are:

1. See The Unity
2. Unity Without Sameness
3. Religion as a Bridge
4. Love The Planet
5. Knowledge and Wisdom
6. Build Communities
7. Heal Dont Humiliate
8. Empower People
9. Seek Justice
10. Think Long Term
11. Be Courageous
12. Build What Works
13. Care For All Life
14. Own Our Mistakes
15. Aspire Without Ego

Again, there is a Prompt file for the set. (AmadeusWeb)

So I now understand the state of the work as:

AoP definition → Humanity/Stages set + Principles set → Copilot prompts → next implementation pass.

And importantly, we should work from these existing artifacts rather than start over or reinterpret the framework from scratch.

The next thing I’d suggest is that we inspect the existing Prompt pages/files for both sets and then formulate the exact Copilot pass we were preparing to run. (AmadeusWeb)

9/16/2026, 3:15:48 PM

Yes - this is much more useful than the individual pages, because it restores the reasoning and, importantly, the division of labor we had established.

I’ve read the conversation through the point where you asked for the Markdown file map. (AmadeusWeb)

What I think is worth discussing now is how to make the picture clearer without prematurely turning this into a technical specification.

The picture I see now

There are really three layers, and our previous conversation was beginning to uncover them:

1. The idea layer - With AI

This is where we explore:

What is an AoP?
Why does it matter?
What are we discovering?
What principles should govern it?
What does an Internet of Missions mean?

The conversations themselves become part of the public intellectual history.

2. The construction layer - Copilot / VS Code

This is where an idea gets turned into actual files:

Markdown → TSV → HTML → PHP → Reveal.js → structured email → etc.

Copilot isn't deciding what AoP means. It's helping construct the thing we've already thought through.

3. The living-project layer - AmadeusWeb

This is the resulting autonomous node:

Mission → people → projects → action → evidence → replication

And the really interesting part is that the node isn't a finished website. It is a collection of simple, inspectable, replaceable files that can keep evolving.

That distinction was very explicit in our earlier conversation:

With AI = Thinking / Dialogue
Copilot = Building / Testing
AmadeusWeb = Public, living implementation (AmadeusWeb)

Where I think the picture can become clearer

I wouldn't add more architecture yet.

I'd make the relationship between the existing pieces much more explicit.

Right now we have:

AoP definition
↓
Humanity mission
↓
Vision
↓
Stages
↓
15 Principles

But these can be misunderstood as simply a hierarchy of documents.

I think what we're actually developing is closer to:

                         MISSION
                            │
              ┌─────────────┴─────────────┐
              │                           │
           VISION                    PRINCIPLES
              │                           │
              └─────────────┬─────────────┘
                            │
                       STAGES / WORK
                            │
              ┌─────────────┼─────────────┐
              │             │             │
           PEOPLE         ACTION        EVIDENCE
              │             │             │
              └─────────────┼─────────────┘
                            │
                       REPLICATION
                            │
                            ▼
                    NEW MISSIONS / AoPs

But even that misses something important:

the whole thing is recursive.

The output of one AoP isn't simply "success."

It can become the starting material for another person's mission.

So:

MISSION
   ↓
AoP
   ↓
WORK
   ↓
EVIDENCE
   ↓
UNDERSTANDING
   ↓
NEW PEOPLE TAKE OWNERSHIP
   ↓
NEW AoPs
   ↺

That's where Internet of Missions becomes more than a metaphor.

And I think there is another missing distinction

The 15 principles aren't another stage.

They're more like the DNA / constraints / tests that travel through every stage.

For example:

• Vision asks: What are we trying to create?
• See the Unity asks: What connects rather than divides?
• Action asks: What are we actually doing?
• Build What Works asks: Does this actually work?
• People asks: Who participates?
• Empower People asks: Are people becoming more capable?
• Evidence asks: What happened?
• Own Our Mistakes asks: What did we get wrong?
• Replication asks: Can someone else do this?
• Aspire Without Ego asks: Does the mission remain more important than its founders?

That makes the principles operational, rather than merely inspirational.

And that, I think, is the important conceptual leap we were approaching when the conversation stopped and you said you'd do the implementation in Copilot. (AmadeusWeb)

So I'd suggest our next discussion isn't "what files do we need?"

We've already done that.

Instead, I'd like to explore one question:

What would someone have to understand, after spending five minutes on the Humanity AoP, to genuinely "get" what we're building?

If we can answer that, we can then decide whether the current Vision / Stages / Principles presentation actually communicates it - and what conceptual layer is still missing.

That feels like the right place for this ChatGPT conversation to work, before anything else gets handed to Copilot.

9/16/2026, 3:19:54 PM

Yes. I think that's a much clearer next move.

Rather than explaining the entire AoP architecture, we give a prospective participant one concrete picture of what they might actually do. The activities become the bridge between "interesting idea" and "I can see myself participating in this."

I would make activity.md deliberately generic and reusable across AoPs. Not ten detailed project plans — ten activity patterns that an AoP can prescribe, adapt, combine, or reject.

Something like this:

The 10 activities

1. Understand the Mission
   Read the mission and existing material; identify what you understand, question, or think is missing.

2. Share Your Perspective
   Bring your own experience, knowledge, story, or relevant work.

3. Research a Question
   Investigate one important question and contribute evidence, sources, or findings.

4. Identify a Problem
   Describe a specific obstacle, unmet need, contradiction, or opportunity.

5. Propose an Idea
   Suggest something that could move the mission forward — without needing to have the complete answer.

6. Connect People
   Identify people, communities, organisations, expertise, or existing initiatives that should be involved.

7. Build Something
   Turn an idea into a tangible output: a document, prototype, resource, experiment, campaign, dataset, etc.

8. Test Something
   Try an idea in the real world and report honestly on what happened.

9. Document the Evidence
   Capture results, learning, decisions, failures, contributions, and useful resources so others can build on them.

10. Help It Continue or Replicate
    Take responsibility for a next step, continue a project, or help another person create a related AoP.

The crucial thing is that these aren't necessarily sequential. Someone could enter at #3, #6, or #7. And an actual AoP might emphasize some activities and barely use others.

I'd structure the Markdown as one self-contained activity definition, with the ten activities inside it, rather than ten separate files.

For each activity, perhaps only:

Activity
Purpose
What you might do
What you might contribute
What you might produce
Questions / feedback

And then a short invitation at the top:

These are proposed activities, not rules.

We are testing whether they provide a useful, understandable way for people to participate in an Action-Oriented Project.

Tell us: - What would you want to do? - What is missing? - What feels unnecessary? - What would make participation easier? - What would you change?

That last piece is important. The activity.md itself becomes an invitation to co-design the AoP.

And I would resist putting the seven stages or fifteen principles into every activity. Instead, each activity could have a lightweight relationship to them where useful. The person should first see:

"Here are ten ways I can contribute."

Only then do we expose the deeper scaffolding.

I think this could actually become one of the most useful generic AoP primitives we've created so far.

9/16/2026, 3:23:40 PM

Absolutely. I think the distinction we were getting at is that activities describe participation, while these are the artifacts produced or accumulated by the project.

A nested structure makes the relationship much clearer:

• Projects - A project is a defined piece of work undertaken in service of the mission. - It has: - a purpose - an owner or team - a proposed outcome - activities - a status - a record of what happened - A project should be understandable independently of the wider AoP. - Projects can: - be proposed - attract participants - run concurrently - finish - continue as independent work - become the seed of another AoP

• People - A people artifact describes the human participation around the mission. - It should capture: - who is participating - what they are interested in - what they can contribute - what they have contributed - what they are responsible for - how they can be contacted or involved - It should avoid turning people into merely a directory. - The emphasis is on agency and contribution, not membership.

• Evidence - Evidence is the project's accumulated record of what is known, discovered, attempted, observed, or demonstrated. - It can include: - research - sources - observations - data - experiments - outcomes - failures - decisions - testimonials - working prototypes - Evidence should distinguish: - what we know - what we believe - what we have tested - what remains uncertain - The purpose is to make the project learnable and auditable by people who weren't there.

• Action - Action records the transition from discussion into doing. - It describes: - what needs to happen - who will do it - by when - what resources are needed - what constitutes completion - what actually happened - Action should favour small, observable commitments over vague intentions. - Completed actions should feed evidence back into the project.

• Replication - Replication captures the ability for useful work to be repeated, adapted, or independently started elsewhere. - It should document: - what was learned - what is reusable - what conditions were important - what can be copied directly - what must be adapted - what another group would need to get started - Replication is not simply duplication. - It is the mechanism by which one successful piece of work can generate many more.

And I think there's a useful relationship between all five:

• People → contribute to Activities
  • Activities produce Projects
    • Projects generate Actions
      • Actions generate Evidence
        • Evidence makes Replication possible
          • Replication creates new Projects, involving new People

So the emerging generic structure becomes:

• Mission — why
• Vision — what could be
• Principles — how we behave
• Activities — how people participate
• People — who acts
• Projects — what is being done
• Action — what happens next
• Evidence — what we learn
• Replication — how it spreads

That feels considerably more coherent to me than treating projects/, people/, evidence/, action/, and replication/ as arbitrary website folders. They are distinct kinds of artifacts in the life of an AoP.

9/16/2026, 3:27:00 PM

😂 Exactly.

And the interesting part is that we don't need to set out to build "an alternative to Jira." We can accidentally arrive somewhere much more interesting.

The conventional tools start with:

Work → tasks → people → status → completion

What we're describing starts with:

Mission → people → activities → projects → action → evidence → learning → replication

The project-management machinery becomes a consequence of the mission, rather than the centre of the universe.

And there is a deliciously dangerous possibility here:

• Jira has issues.
• Trello has cards.
• Asana has tasks.
• Azure DevOps has work items.
• AoP has artifacts.

An artifact can be a mission, question, person, activity, project, action, piece of evidence, decision, experiment, outcome, or replication — all connected in a publicly intelligible context.

So instead of:

"What's the status of ticket #1847?"

you eventually get:

"Why does this work exist, who is doing it, what have we learned, what evidence supports it, and what can I do next?"

That's a rather different proposition.

And there's another subtle advantage to keeping activity.md generic: we don't have to build the software first.

We can test the model with Markdown.

If ten activities + five artifact types genuinely help humans coordinate meaningful work, then Copilot can start turning that structure into software.

Markdown first. Machinery second.

That's probably the bit that should make Jira nervous. 😄

9/16/2026, 3:28:42 PM

😂 That is a very good precedent.

The Opera team arriving with Notepad already open says something important about the philosophy here.

They weren't waiting for a sophisticated project-management environment to tell them how to work. The tool was almost invisible:

Open → think → write → share → do.

And perhaps that's exactly the instinct we should preserve.

The danger with Jira/Trello/Asana-style systems is that the representation of work becomes almost as important as the work itself. People learn the application's vocabulary: tickets, sprints, boards, labels, workflows, epics...

With AoP, perhaps the vocabulary should remain human vocabulary:

• Mission
• Question
• Idea
• Person
• Activity
• Project
• Action
• Evidence
• Decision
• Outcome
• Learning

And underneath it all?

Markdown files.

Which makes your Notepad story rather wonderfully prophetic. 🙂

The difference now is that the humble text file can be public, linked, versioned, searchable, machine-readable, rendered beautifully, discussed with AI, transformed by Copilot, and replicated elsewhere.

So maybe the ambition isn't:

"Let's build a better Jira."

It's:

"Let's see how far people can get with almost no software at all."

Then, whenever software is useful, it should emerge from the artifacts and activities people are already using — rather than forcing the people to conform to the software.

That would be a pretty good test for an Action-Oriented Project itself.

9/16/2026, 3:34:09 PM

Yes. Having now looked at the whole AoP material on the site, rather than just the pieces we've been discussing, I think the TL;DR is surprisingly simple.

Action-Oriented Project - TL;DR

An Action-Oriented Project is a public, ongoing project that uses a gathering to accelerate real work - rather than an event that happens to contain a project. (AmadeusWeb)

You don't come to an AoP primarily to attend.
You come to contribute.

Before the gathering, people can:

• read the mission and existing work
• ask questions
• research
• share knowledge and ideas
• find other people
• take on activities
• start projects
• prepare things to be decided or built

The gathering is the acceleration point: people review what has happened, resolve questions, make decisions and commit to action. (AmadeusWeb)

Then the project continues.

People produce things. Actions create evidence. Projects evolve. New people take ownership. And eventually participants should be able to start or replicate projects of their own. (AmadeusWeb)

In one line

Mission → People → Activities → Projects → Action → Evidence → Replication

And underneath it all are the principles that guide how we work - currently fifteen, from See The Unity and Build Communities through Build What Works, Own Our Mistakes, and Aspire Without Ego. (AmadeusWeb)

The really short version

Don't organise an event about the work.
Organise the work, and let the event accelerate it.

That's the AoP.

And I think this is the message that should sit right at the front of the site. Everything else - the stages, principles, activities, people, projects, evidence, etc. - explains how to make that simple idea real.

Which also explains why your activity.md idea feels so important now: after someone understands the TL;DR, the natural next question is simply:

“Okay. If I want to contribute, what can I actually do?”

That's where the ten generic activities become the doorway into the whole system.

9/16/2026, 3:36:35 PM

Yes — and that changes how I see the 15 principles.

They aren't a set of principles we invented first and then imposed on the project. They emerged from the larger body of writing as recurring themes.

That is much more interesting.

The sequence was effectively:

Large body of writing
→ identify 50 representative pieces
→ look for recurring ideas/themes
→ 15 principles emerge
→ turn those principles into something an AoP can actually use

So See The Unity, Unity Without Sameness, Religion as a Bridge, Love The Planet, etc. aren't arbitrary values on a poster. They're an attempt to answer:

What does this body of work consistently seem to believe?

And that gives us a potentially powerful distinction:

• Principles = what the accumulated thinking suggests we believe / value.
• Mission = what we are trying to accomplish.
• Vision = what the world could look like.
• Activities = how people can participate.
• Projects = what people actually undertake.
• Action = what they commit to doing.
• Evidence = what happens when they do it.
• Replication = what others can take forward.

That is a much more organic architecture.

And there's a lovely feedback loop hiding in it:

Writing → themes → principles → action → evidence → new writing/learning → refined principles

So the principles aren't necessarily fixed commandments. They're living hypotheses about the character of the mission.

That also makes Own Our Mistakes and Build What Works particularly important. The framework contains its own mechanism for discovering that some of its assumptions are wrong.

Which means the TL;DR might ultimately be even simpler:

Start with a mission. Invite people to contribute. Turn contributions into action. Learn from what happens. Make the useful things repeatable.

And the 15 principles tell us what kind of action-oriented community we want that process to produce.

That's quite a bit more profound than "here are 15 principles for running an event."

9/16/2026, 3:39:07 PM

Exactly. That is the much bigger idea.

The Humanity AoP is not the thing being generalised. It is the worked example.

Your 15 principles demonstrate the mechanism:

Take a substantial body of organised writing → make it public → let people read and discuss it → identify its recurring themes → turn those themes into a usable framework → invite people to act on them → accumulate what happens.

And therefore the input doesn't have to be your writing.

It could be:

• a book
• an author's complete works
• a research programme
• a company's accumulated knowledge
• a community's oral history
• an archive
• a scientific field
• an existing movement
• a collection of correspondence
• a body of policy
• or simply years of accumulated conversations

The essential prerequisite is organisation and cumulative publication.

That's where AmadeusWeb Spring becomes much more important than the AoP website itself.

The architecture is essentially

Body of work
↓
Organise it
↓
Publish it
↓
Discuss it
↓
AI helps discover structure / themes / questions
↓
People validate, challenge and extend them
↓
Turn understanding into activities
↓
Activities produce projects and action
↓
Action produces evidence
↓
Evidence and conversation accumulate
↓
Others can pick it up and replicate it

And crucially, the publication doesn't get overwritten every time we learn something new.

It accumulates.

That's the bit that makes the whole thing different from a conventional website or a conventional event.

Which gives us a very clean distinction

AmadeusWeb Spring is the substrate.

It provides the ability to organise and continuously publish the evolving body of work.

AI is the thinking partner.

It can help find patterns, ask questions, make connections, propose structures and challenge assumptions.

Copilot is the construction partner.

It turns those structures into the actual working artefacts and software.

AoP is the action model.

It turns accumulated understanding into participation, projects, action and replication.

And Humanity is simply our first major example.

That suddenly makes the whole thing much easier to explain.

We aren't building a website about Humanity.

We're demonstrating a way for any body of human knowledge and intention to become an organised, living, participatory project.

And then the slightly cheeky version:

Give us a book. We'll give you an AoP.

Not automatically, of course. The people still have to read it, argue with it, interpret it, test it and decide what matters.

But the infrastructure makes that possible at cumulative scale.

That's a much bigger proposition than the one we were discussing when we started with "what are the seven stages of an AoP?"

9/16/2026, 3:43:51 PM

Yes - and I think the comparison should not be a feature checklist. The useful question is:

What does each system assume that work is?

That exposes why AoP can resemble Google Drive, Wikipedia, GitHub, Jira, Trello, Asana, Notion, a wiki, a CRM, a knowledge base, or even a scientific notebook - while actually having a different usage philosophy.

I've checked the current descriptions of a few of the major systems. For example, Google Drive is fundamentally organized around files, folders, sharing and access; Wikipedia around collaborative encyclopedia articles and community editorial norms; Jira around tracking work through projects, issues and workflows. (Google Workspace)

AoP compared with 25 things

The interesting cluster

I'd actually group the 25 into six families:

• Storage - Google Drive - Dropbox - OneDrive - → "Where do we put things?"

• Knowledge - Wikipedia - Notion - Confluence - Obsidian - Zettelkasten - → "How do we understand and organise what we know?"

• Communication - Slack - Discord - Reddit - social networks - forums - → "How do we talk to one another?"

• Project management - Jira - Trello - Asana - Planner - Basecamp - → "How do we get work done?"

• Building / experimentation - GitHub - GitLab - Azure DevOps - scientific notebooks - open source - → "How do we build, test and improve things?"

• Publishing - WordPress - CMSs - blogs - → "How do we make things public?"

And AoP sits across all six.

That's the important distinction.

The philosophical difference

Most of these tools begin with an object:

file
page
post
message
ticket
task
repository
contact

AoP begins with a purpose:

There is something worth doing.

Then:

Mission
→ creates a body of work
→ attracts people
→ proposes activities
→ produces projects
→ generates action
→ creates evidence
→ produces learning
→ enables replication

The files, pages, conversations, tasks and code are all artifacts within that process.

That is why your friend's Google Drive/Wikipedia question is actually a very good one.

I'd answer:

"It has some of the characteristics of Google Drive and Wikipedia, but the philosophy is different. Drive helps you store things. Wikipedia helps you accumulate knowledge. Jira helps you track work. Slack helps you talk. GitHub helps you build. An Action-Oriented Project tries to connect all of those activities around a shared mission - and keep the resulting knowledge, action and evidence accumulating in public."

And there's an even shorter version:

Drive stores. Wikipedia explains. Slack talks. Jira tracks. GitHub builds. AoP organises people around something worth doing.

That's the comparison I'd put in front of someone who asks "What is this thing?"

It also gives us a very useful design test going forward:

If AoP ever starts behaving like Jira, we've probably lost the plot.

The software can borrow good ideas from Jira, Trello, GitHub, Wikipedia, Drive, etc. But the usage philosophy should remain mission-first, human-first, cumulative, public where appropriate, and action-oriented.

9/16/2026, 3:49:26 PM

PUBLISHED AT AOP Home

9/16/2026, 3:51:08 PM

Yes. I’d cut the explanatory scaffolding and keep only the ideas needed to understand the model.

document:

Action-Oriented Projects

Turn shared purpose into organised, cumulative action.

An Action-Oriented Project (AoP) is a public, ongoing project organised around a mission.

It is not an event that contains a project.

The work comes first. The gathering accelerates the work.

The model

Mission → People → Activities → Projects → Action → Evidence → Replication

People can contribute before, during and after a gathering. The gathering is a point of acceleration — not the end of the project.

People participate by

• understanding and questioning the mission
• sharing knowledge and experience
• researching questions
• identifying problems and opportunities
• proposing ideas
• connecting people
• building and testing things
• documenting evidence and learning
• continuing or replicating useful work

These are generic activities, adaptable to any AoP.

The project accumulates artifacts

People — who contributes and what they can do
Projects — defined work serving the mission
Actions — things people commit to and actually do
Evidence — research, experiments, results, failures and learning
Replication — what others can reuse, adapt or start elsewhere

The result is a living record of work, not a report about an event.

From knowledge to action

An AoP can begin with any organised body of work — a book, an author's writings, research, an archive, a community's knowledge, an existing movement, or accumulated conversations.

Organise → Publish → Discuss → Discover themes → Challenge → Act → Learn → Accumulate

The Humanity AoP demonstrates this: recurring themes in a larger body of writing became fifteen principles. The principles are an example, not a prescription.

Not another Jira, Wikipedia or Google Drive

Those systems each excel at something:

Drive stores. Wikipedia accumulates knowledge. Slack facilitates conversation. Jira, Trello and Asana coordinate work. GitHub builds collaboratively.

An AoP can use ideas from all of them, but starts with a different question:

What is worth doing — and how can people work together to do it?

The philosophy

AmadeusWeb Spring provides a substrate for organised, published and cumulative work.

Simple, inspectable documents can become a body of knowledge, a conversation, activities, projects, action, evidence and ultimately a living public record.

Software serves the work. The work does not serve the software.

In one sentence

An Action-Oriented Project organises people around something worth doing, makes the work cumulative and public where appropriate, uses gatherings to accelerate it, and turns what is learned into further action and replication.

Don't organise an event about the work.
Organise the work — and let the event accelerate it.

9/16/2026, 3:51:41 PM

Yes — six sections is probably the right shape. I’d make each section do one job and remove the repetition.

document:

Action-Oriented Projects

1. What is an AoP?

An Action-Oriented Project (AoP) is a public, ongoing project organised around a mission.

It is not an event that contains a project.

The work comes first. The gathering accelerates the work.

2. How does it work?

Mission → People → Activities → Projects → Action → Evidence → Replication

People can contribute before, during and after a gathering. The gathering accelerates decisions, collaboration and commitments; the project continues afterwards.

3. What do people do?

People can:

• understand, question and research
• share knowledge and experience
• identify problems and opportunities
• propose ideas and connect people
• build and test things
• document evidence and learning
• continue or replicate useful work

These are generic activities, adapted to each mission.

4. What accumulates?

An AoP creates a living collection of artifacts:

People — who contributes
Projects — what is being worked on
Actions — what is actually done
Evidence — what is learned
Replication — what others can reuse or start

The result is a living record of work, rather than a report about an event.

5. From knowledge to action

An AoP can begin with any organised body of work — a book, writings, research, an archive, community knowledge, an existing movement, or accumulated conversations.

Organise → Publish → Discuss → Discover → Challenge → Act → Learn → Accumulate

The Humanity AoP demonstrates this: recurring themes in a larger body of writing became fifteen principles. They are an example, not a prescription.

6. The philosophy

An AoP can borrow capabilities from Google Drive, Wikipedia, Slack, Jira, Trello, Asana, GitHub and many others.

But it starts with a different question:

What is worth doing — and how can people work together to do it?

AmadeusWeb Spring provides a substrate for organised, published and cumulative work.

Software serves the work. The work does not serve the software.

Don't organise an event about the work.
Organise the work — and let the event accelerate it.