VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

How Cooperation Works | Common Knowledge — Why Everyone May Need to Know That Everyone Knows

Four students know the presentation is due Friday.

Each one assumes somebody else is coordinating the final file.

Friday arrives.

Everybody knew.

The group still failed.

Common knowledge is shared information whose sharedness is itself visible enough that people can coordinate around it: I know the plan, I know that you know the plan, and I have reason to believe that the group recognises the same public state.

This is the first pillar beneath How Cooperation Works. The master owns cooperation broadly. This page owns one specific coordination problem: when private knowledge is not enough because action depends on knowing what others know, expect and recognise together.

Quick Read

Cooperation often fails not because information is absent, but because shared state is uncertain. A deadline may have been emailed to everyone, yet nobody knows whether others saw it. A team may agree verbally on roles, yet nobody knows whether the assignment was final. A school may publish a procedure, yet students may not know whether the adults around them are using the same version. Common knowledge reduces this ambiguity by creating public signals: a written decision, visible role board, acknowledged handoff, shared dashboard, meeting record or common procedure. The goal is not endless confirmation. It is to make the few coordination-critical facts public enough that each actor can predict the others’ next moves.

private information → public signal → shared interpretation → acknowledgement → common-enough state → coordinated expectations → action → update shared state

Everyone Knowing Is Not the Same as Everyone Knowing That Everyone Knows

Imagine four people each receive the same private message:

The meeting moved to 4 p.m.

Each knows the new time.

But each may still wonder:

  • Did everyone receive it?
  • Did everyone understand it?
  • Is the change final?
  • Will the organiser still arrive at 3?

A public announcement in the shared channel plus acknowledgement changes the coordination state.

shared information coordinates best when the group can see that it has become shared.

Common Knowledge Is a Coordination Resource

Cooperation requires predictions about other people.

You choose your action partly because you expect others to choose theirs.

If those expectations depend on invisible private information, the system becomes fragile.

Public shared state reduces the need to guess.

A Deadline Should Have One Public Home

Teacher says Friday.

Student A writes Thursday.

Student B remembers next Monday.

Student C has the correct date in a private message.

The group does not have one deadline.

It has several competing representations.

A shared board, calendar or project page creates a canonical coordination object.

Roles Need Public Commitment

Weak role allocation:

I thought you were doing the conclusion.

Strong role allocation:

INTRODUCTION — Mei
DATA VISUAL — Arjun
CONCLUSION — Sarah
FINAL COMPILE — Daniel
DUE TO COMPILER — Thu 6 p.m.

Now the assignment is not only distributed.

It is mutually visible.

Acknowledgement Closes the “Did You See It?” Gap

A sender posts a critical change.

No one responds.

The sender may assume silence means understanding.

The receivers may assume someone else will clarify.

For high-consequence changes, use a lightweight receipt:

  • acknowledge;
  • repeat the changed action where necessary;
  • flag conflict immediately.

This connects to How Communication Works, which owns message meaning and return paths broadly. Common Knowledge stays on the coordination state produced when the group can see that critical information is mutually recognised.

Shared Dashboards Are Common-Knowledge Machines

A good dashboard can make visible:

  • current target;
  • current owner;
  • status;
  • blocker;
  • deadline;
  • last update;
  • next decision.

Its value is not merely information storage.

It reduces disagreements about what state the group is actually in.

Meeting Decisions Need a Public After-State

A meeting contains ten minutes of discussion and one decisive sentence.

If that sentence is not captured, each participant may leave with a different version.

Good closure records:

  • decision;
  • owner;
  • deadline;
  • open uncertainty;
  • next review point.

discussion creates possibilities; a public decision state creates coordination.

Common Knowledge Matters Most Where Actions Are Interdependent

If your task is fully independent, you need less shared state.

If your output becomes another person’s input, uncertainty about shared state becomes expensive.

Examples:

  • group presentation;
  • laboratory procedure;
  • software deployment;
  • school event;
  • emergency response;
  • multi-stage marking/moderation.

Common Knowledge Is Not Total Information Sharing

A team does not need every person to know everything.

That would create noise, privacy risk and cognitive overload.

The goal is to identify coordination-critical facts:

  • shared objective;
  • decision;
  • role;
  • dependency;
  • deadline;
  • exception;
  • state change.

Everything else can remain local where appropriate.

Common Knowledge Can Be Wrong

Everyone publicly agrees:

The client wants option A.

The client actually changed to option B privately with one person.

The shared state is coherent but stale.

Common knowledge therefore needs freshness and correction, not only visibility.

Versioning Prevents Shared-State Drift

Procedure v1.

Procedure v2.

Half the group still uses v1.

Now everybody “knows the procedure,” but not the same procedure.

Use:

  • version number;
  • effective date;
  • change summary;
  • retirement of outdated copy;
  • acknowledgement for critical updates.

Public Commitments Change Behaviour

A private intention is easy to reinterpret later.

A public role commitment creates:

  • clarity;
  • accountability;
  • predictability for dependent actors;
  • a visible place to report risk.

This does not mean public shaming.

It means the cooperative system can see which load rests where.

Common Knowledge Reduces Duplicate Checking

Four people privately wonder whether the file was submitted.

Four people message the submitter.

Shared status:

SUBMITTED 4:42 p.m. — receipt attached.

One public receipt replaces repeated private verification.

This is one way common knowledge interacts with Verification Budget: visibility makes proportionate checking cheaper.

Common Knowledge Can Become Coercive

Public visibility is not automatically good.

A dashboard that exposes sensitive weaknesses to everyone can create:

  • status pressure;
  • privacy harm;
  • performative updates;
  • fear of reporting uncertainty.

Use the least public visibility that still solves the coordination problem.

Common Knowledge and Common Ground Are Related but Different

Common ground concerns shared assumptions and mutual understanding in communication.

Common knowledge emphasises the recursive coordination property: the sharedness itself is sufficiently visible that people can base actions on what they expect others recognise too.

In practice, cooperative systems often need both.

Common Knowledge Helps Role Complementarity Work

Specialised roles can create more total capability—but only if each person knows enough about the dependency structure to coordinate.

The second sibling, Role Complementarity, owns why different roles can create joint value. Common Knowledge supplies the shared map that lets those roles meet.

Common Knowledge Defines the Cooperation Boundary

A group may coordinate beautifully around a goal that harms outsiders.

The shared dashboard may make internal performance visible while external costs remain invisible.

The third sibling, Cooperation Boundary, owns who is included in the success model and who bears consequences outside it.

Reconfiguration Requires a New Shared State

One contributor becomes unavailable.

The role map changes.

If the change is handled privately, old assumptions persist.

The fourth sibling, Cooperation Reconfiguration, owns how the system reallocates work after a role disappears.

A Practical Common-Knowledge Packet

SHARED OUTCOME: Final presentation submitted Friday 5 p.m.
CANONICAL PLAN: Project board v3
ROLE OWNERS: Visible on board
LATEST CHANGE: Data slide replaced; version 3 effective now
BLOCKER: Citation approval pending
NEXT OWNER: Mei to confirm citation by Thu 3 p.m.
ACKNOWLEDGED BY: All four members
NEXT REVIEW: Thu 6 p.m.

A 30-Lens Common Knowledge Audit

  1. Shared outcome: what must everyone orient toward?
  2. Critical fact: what must be mutually recognised?
  3. Private/public: is information visible to all relevant actors?
  4. Canonical source: where is the authoritative state?
  5. Version: are people using the same copy?
  6. Freshness: when was it last updated?
  7. Acknowledgement: do receivers confirm critical changes?
  8. Interpretation: do they understand the same action?
  9. Role: can everyone see who owns what?
  10. Deadline: one shared time or several private memories?
  11. Dependency: which output becomes whose input?
  12. Decision: was discussion converted into a public after-state?
  13. Uncertainty: what remains unresolved?
  14. Exception: how is drift reported?
  15. Dashboard: what status belongs in shared view?
  16. Noise: is too much information public?
  17. Privacy: what should stay local?
  18. Status pressure: does visibility discourage honest reporting?
  19. Receipt: can completion be seen once?
  20. Verification: does shared state reduce duplicate checking?
  21. Common ground: are assumptions understood?
  22. Higher-order awareness: can actors reasonably expect others saw the same state?
  23. Staleness: what retires old information?
  24. Handoff: does the shared state travel across roles?
  25. Complementarity: does the group see how specialised contributions fit?
  26. Boundary: are external stakeholders absent from the shared state?
  27. Reconfiguration: how are role changes made public?
  28. Scale: what changes when group grows?
  29. Audit: can the decision history be reconstructed?
  30. World return: did mutual visibility actually make coordinated action more reliable?

Laboratory 1: Private Knowledge vs Shared State

Give four people the same deadline privately. Then repeat using one shared visible board with acknowledgement. Compare how many clarification messages and assumption errors appear.

Laboratory 2: One Decision Record

After a meeting, write only five lines: decision, owner, deadline, open uncertainty, next review. Ask each member whether their understanding matches the record.

Laboratory 3: Version Drift

Create two versions of a simple procedure. Observe what happens if old copies remain accessible. Then add version labels, effective dates and retirement of the old copy.

For Primary Readers

If everyone in your group knows where to meet but nobody knows whether the others received the same message, people can still end up in different places. A shared message that everyone sees and confirms makes the plan safer.

For Secondary Readers

Build one project board that makes deadline, owner, status and blockers mutually visible. Explain why this is different from four students holding the same facts privately.

For Advanced Readers

Model common knowledge as a coordination state in which critical information is not merely distributed across agents but publicly represented enough that agents can condition their own actions on the expectation that others recognise the same state. Practical systems approximate this through public signals, acknowledgements, canonical records and version control rather than requiring literal infinite recursive certainty.

Common Misconceptions

  • “If everybody knows, coordination is solved.” each person may still be uncertain whether others know or whether the information is final.
  • “Put everything in a shared channel.” too much visibility creates noise and privacy cost; prioritise coordination-critical state.
  • “A meeting creates common knowledge automatically.” participants can leave with different interpretations unless the decision state is captured.
  • “Acknowledgement is bureaucracy.” for critical changes it closes uncertainty cheaply.
  • “Shared state stays true once published.” common knowledge needs freshness, versioning and correction.

Research Corridor

Frequently Asked Questions

What is common knowledge in cooperation?

It is coordination-critical information that is publicly shared enough that participants can reasonably act on the belief that relevant others recognise the same state too.

How do teams create common knowledge?

Use public decisions, visible role assignments, canonical boards or documents, acknowledgements for critical changes, and clear versioning so private interpretations do not silently diverge.

Is common knowledge the same as everyone having access to the document?

No. Access does not prove attention, understanding, currency or mutual recognition. The cooperative question is whether the shared state is visible and recognised enough to coordinate action.

Final Thought: Cooperation Needs a Shared Reality, Not Just Shared Files

Common knowledge works when the few facts that determine everyone’s next move become public enough, current enough and mutually recognised enough that people can stop guessing what the rest of the group thinks is happening.

COOPERATION · FOUR PILLAR LEGS

Return to How Cooperation Works, or continue through Role Complementarity, Cooperation Boundary and Cooperation Reconfiguration. Return to the How X Works Hub.

Discover more from eduKate Singapore

Subscribe now to keep reading and get access to the full archive.

Continue reading