eduKate Singapore

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.

Next useful routeCanonical hubHELP

How Intelligence Works | Boundary Objects — Shared Maps, Forms and Definitions Across Expert Teams

—

by

eduKate Asia

Did you know that a team can agree on every sentence in a meeting and still fail to coordinate because the same word means different things to different specialists? A school administrator, a teacher and a parent may all say a case is urgent, yet attach different time windows and responsibilities to the word. They do not necessarily need identical professional perspectives. They need a shared object that preserves the same essential reference while supporting the different questions each person must answer.

One practical mechanism is a boundary object: a map, form, specimen record, diagram, schedule, glossary or structured register that different groups can use without first agreeing on everything else. It works when its identity and critical fields remain stable across contexts while its views and annotations can vary. To build one, define the joint decision, identify contested terms, establish a minimal common representation, let each group test the representation against real tasks, assign stewardship, and revise it when actual work exposes ambiguity. A beautiful diagram that nobody trusts or maintains is not a successful boundary object.

This article addresses human and organisational intelligence rather than artificial superintelligence or the general mechanics of machine learning. The numerical examples are invented teaching scenarios, not claims about a real institution or completed experiment. Readers can use them to diagnose a communication failure, construct a shared artifact and check whether collaboration becomes more reliable.

In this guide

Where the idea comes from

In a 1989 research article, Susan Leigh Star and James R. Griesemer examined cooperation among amateurs, scientists, administrators and other participants connected to Berkeley’s Museum of Vertebrate Zoology. Their paper, Institutional Ecology, Translations and Boundary Objects, described a practical puzzle: groups with different interests and understandings still managed to coordinate enough work to sustain a scientific institution.

The authors identified boundary objects as representations that could adapt to local needs while retaining sufficient common identity. Their discussion distinguished repositories, ideal types, coincident boundaries and standardised forms. The terms came from the sociology of science, but the underlying coordination problem appears in contemporary schools, research centres, community projects, software teams, public agencies and multidisciplinary organisations.

The concept does not mean that agreement is unimportant or that every shared spreadsheet qualifies automatically. It is a mechanism for productive cooperation across legitimate differences. A successful boundary object helps participants know what they are referring to, what evidence supports a claim and where their responsibilities meet. It allows disagreement to become inspectable instead of remaining hidden inside a familiar word.

A shared object is not the same as a shared opinion

A teacher may understand a student concern through learning evidence, a parent through family circumstances and a service coordinator through referral procedures. Their perspectives are not interchangeable. If a coordination document forces everyone to use one narrative, it may discard useful knowledge and create resistance. If each group uses entirely separate records, decisions become impossible to reconcile. A boundary object sits between these failures.

It provides a stable anchor such as a case ID, observed event, timestamp, location, status definition or diagram element. Around that anchor, different people can attach specialised views. The teacher may see instructional adjustments, the parent a clear next step and the service coordinator a deadline or escalation route. These are not rival truths if they use the same defined facts and distinguish facts from interpretations.

The design question is therefore not “how do we make everybody think alike?” It is “which things must remain identical for our joint task to work, and which things can legitimately differ?” Writing down that boundary is itself a valuable exercise in organisational intelligence.

Four forms of coordination artifact

A repository gathers items that various communities can find, classify and use, such as a museum collection or a shared evidence register. Its key property is consistent reference: people know which item a record concerns. An ideal type offers a simplified general representation, such as a model diagram of a process. Different specialists may use it for different questions while recognising the same underlying pattern.

A coincident-boundary object supplies a shared outer frame despite internal differences, such as a geographic map used by planners, residents and utility engineers. A standardised form lets many participants record facts in an agreed structure while retaining local expertise about what they observe. These examples are not a rigid classification for every modern workflow, but they help designers notice that cooperation can be mediated through several kinds of objects, not just prose policies.

Choose the form from the problem. If confusion arises from missing items, build a findable register. If it arises from different uses of the same terms, build a glossary with linked examples. If teams disagree about overlapping responsibilities, create an interface or boundary map. If dozens of people supply observations in inconsistent formats, test a structured form.

Why ordinary meetings fail at this problem

Conversation is essential, but words evaporate unless a stable reference survives them. In a meeting, people may nod at “complete”, “approved” or “high risk” because each phrase sounds familiar. The following day, one person interprets complete as a finished draft, another as independently checked work, and another as formally approved for publication. All three sincerely believe the group agreed.

A meeting transcript preserves the words, but not automatically their operational meaning. A boundary object adds a testable definition and specific referents. For example, “approved for release” might require a named authorised reviewer, a version ID, and a timestamp. The criteria distinguish it from “review requested” and “review passed but not yet released.”

The method also reveals questions that polite conversation can hide. If an architect points to an unclear symbol on a shared plan, the engineer can ask for a measurable specification. If a parent sees “support initiated” without a date or responsible role, the missing handoff becomes visible. The point is not to prevent discussion; it is to make the next discussion more concrete.

Work backward from the joint decision

Before drawing a map or building a database, identify one joint decision that currently goes wrong. Perhaps a student support referral is delayed, a scientific sample is mislabelled, a software integration changes without notice, or two departments count the same outcome differently. Name the decision, the affected people, and the cost of misunderstanding. That scope prevents the shared artifact from becoming an endless encyclopedia.

Ask each participant what information they require to act correctly. Separate shared core fields from local fields. A shared referral record might need a reference ID, observation date, consent status, accountable owner, current stage, next agreed action and deadline. The teacher’s local notes may require a pedagogical rubric that the finance team does not need. The parent’s view may need plain-language explanations without private staff annotations.

The smallest useful common layer is usually better than an expansive but burdensome form. However, minimalism cannot become an excuse to omit evidence, privacy permissions or accountability. The goal is the least structure that reliably prevents the targeted coordination failure.

A field should contain meaning, not just a value

Suppose a form has a column labelled “date”. Does it mean the day a problem was observed, the day a referral was submitted, the deadline for action, or the date a reviewer approved it? A date without an event label can be worse than a missing date because it appears precise while inviting the wrong inference.

Each essential field needs a definition, unit or format, allowed values where appropriate, source, update responsibility and interpretation rule. A deadline should specify date and time zone if hours matter. A status should have clear entry and exit conditions. A count needs a denominator and population boundary. A category needs examples that test its edges, not only a one-line label.

The W3C Data on the Web Best Practices emphasises human- and machine-understandable metadata, consistent reuse and provenance in data publication. Although that Recommendation concerns web datasets, the same reasoning explains why shared institutional records require descriptions of what their fields actually mean.

The difference between shared data and shared authority

A common register does not decide who may approve a referral, release a payment or change a safety rule. Authority must come from legitimate governance, not from the mere fact that someone can edit a shared sheet. Designate who observes, who records, who may correct a factual entry, who validates a decision and who is accountable for an action. These roles can differ.

For engineering interfaces, NASA’s interface management guidance highlights responsibilities, interface agreements, change control and jointly managed boundaries. That guidance is written for systems engineering, but it illustrates a broad truth: shared interface documents work only when people know how changes are proposed, approved and communicated.

A boundary object can therefore be open to many readers but editable only through a defined process. Some fields may be private to authorised roles. Correct access control is part of reliable coordination; a document that leaks sensitive student or employee information is not made acceptable by being convenient.

Fully solved case: the word urgent

Consider a fictional support centre handling 120 requests. Its scheduling team defines “urgent” as a deadline within seven days and labels 48 cases urgent. Its response team defines urgent as requiring action within 48 hours and labels 30 cases urgent. Exactly 24 cases receive the urgent label from both teams. Each team has applied its own definition consistently, yet the labels appear contradictory in the shared meeting report.

We can construct the entire two-by-two table. Both teams say urgent for 24 cases. Scheduling alone says urgent for 48 minus 24, or 24 cases. Response alone says urgent for 30 minus 24, or 6 cases. Neither says urgent for 120 minus the union of 48 and 30, or more carefully 120 minus (48 plus 30 minus 24), which is 66 cases. The four cells are 24, 24, 6 and 66; they sum to 120.

The overlap is 24 cases, but the union of cases labelled urgent by at least one team is 48 plus 30 minus 24, or 54. The Jaccard agreement-on-positive-sets is therefore 24 divided by 54, or about 44.4 per cent. That number shows limited overlap between the two labels. It does not mean either team was wrong, and it is not a probability that a case truly deserves urgency. The definitions differ.

Repair the case by defining the underlying event

The right intervention is not necessarily to tell one team to adopt the other’s notion of urgent. A scheduling team legitimately needs a seven-day planning horizon; a response team legitimately needs a 48-hour intervention horizon. Instead, create a common field for the objectively relevant deadline timestamp, recorded with a time zone and source. Then calculate or display two clearly named views: “within seven calendar days” and “action due within 48 hours.” Each field says what it means.

If another dimension matters, such as safety severity, give it a separate defined field rather than embedding it invisibly in the word urgent. A high-severity issue with a longer administrative deadline is not equivalent to a routine request that must be handled quickly. The shared record makes those dimensions explicit, and the team-specific views no longer masquerade as one universal category.

This repair addresses representation, not merely vocabulary. Two teams can now point to the same case ID and deadline value, apply different legitimate filters, and understand why their workload counts differ. The divergence becomes explainable and auditable instead of personal.

Check the denominator before comparing teams

A denominator answers “out of what?” A response team may report thirty urgent cases among 120 total records, or 25 per cent. A scheduling team may report 48 among the same 120, or 40 per cent. Those percentages cannot be interpreted as a performance comparison if the labels mean different things. They measure different questions.

A subtler problem arises when teams work with different populations. One may include withdrawn cases and the other may include only active cases. Even perfectly aligned urgency rules would then produce different rates. Define the population window, inclusion criteria, treatment of duplicates and rules for withdrawn or reopened records. Record them in the shared object or its accompanying data dictionary.

A shared dashboard with matching column names can hide denominator disagreements more effectively than two obviously different local reports. Semantic alignment needs a worked example, not just matching typography.

Measure the information that the object makes complete

Suppose the same fictional support register has 150 decision records. Eighteen lack an accountable owner; 27 lack a next-action deadline; eight lack both fields. The number missing at least one of the two critical fields is 18 plus 27 minus 8, or 37. Therefore 150 minus 37, or 113 records, have both fields. The critical-field completeness rate is 113 divided by 150, approximately 75.3 per cent.

Imagine a later hypothetical version of the form has five records missing an owner, seven missing a deadline and two missing both. The missing-at-least-one count is 5 plus 7 minus 2, or 10. The complete count is 150 minus 10, or 140. Completeness rises to 140 divided by 150, about 93.3 per cent. The absolute change is 27 out of 150, or 18 percentage points. These are invented before-and-after arithmetic exercises, not evidence that a real intervention achieved the improvement.

The measure is deliberately narrow. More filled cells do not prove that owners were correct, deadlines feasible or people treated fairly. The next verification step is to sample actual records and check their meaning against source evidence. Good boundary objects make such verification possible.

Consistency is different from correctness

A single shared definition can be wrong. Suppose every department adopts an inaccurate interpretation of a policy date. Their dashboards may become perfectly consistent while the resulting actions are jointly mistaken. Boundary objects improve coordination only if they are anchored to valid evidence and allow errors to be challenged and corrected.

For consequential fields, attach sources or source locations: a written policy, an observed event, a signed approval, a versioned interface specification or a timestamped operational log. Distinguish primary evidence from a summary and separate an inference from an observation. If a deadline is derived from a policy rule, record the rule version and the input event that started the clock.

The existence of a shared form should not end debate. It should allow a reviewer to identify exactly which premise is disputed. A correction process then updates the record and propagates the revised meaning to relevant users rather than letting each team continue with stale private copies.

Version control for shared meaning

A form changes over time. Adding a field is usually straightforward; changing what an existing field means is much riskier. A field called “response time” might previously measure time to first acknowledgement and later measure time to substantive action. If historical reports and new records are combined under the old label, apparent trends can become meaningless.

Give significant definitions effective dates and version numbers. Document changes to units, inclusion criteria, status transitions, ownership or privacy classification. Where possible, retain the older field meaning for historical data or provide an explicit, tested conversion. If conversion is impossible, mark a break in the series rather than quietly plotting incompatible numbers as one line.

The coordination goal is not bureaucracy for its own sake. It is to keep every participant aware of which shared meaning they are using. A short change log that answers “what changed, why, when and who reviewed it?” can prevent an expensive misunderstanding.

The design tension between flexibility and precision

A boundary object must be stable enough to support shared reference but flexible enough to fit local work. Too much rigidity pushes specialists to keep unofficial shadow records. Too little structure leaves everyone with a different interpretation. The boundary is not a permanent compromise; it needs adjustment as tasks evolve.

For a school project, a shared attendance record might define the date, cohort, learner ID and participation status strictly, while teachers retain free-text explanations of learning barriers in a protected pedagogical note. For a research collection, specimen identifiers and capture locations need consistent meaning, while scientists may attach specialised annotations for ecology, genetics or conservation. The same record serves multiple communities without pretending their questions are identical.

Test each proposed field by asking both whether another team can interpret it reliably and whether the originating team can record it accurately without excessive effort. An imposed taxonomy that outsiders like but practitioners cannot apply will degrade data quality.

Translation across specialist languages

A nurse, statistician, software developer and service designer can all use the word “risk” differently. Some mean probability of an adverse event, some mean expected loss, and some mean a qualitative priority classification. A boundary object should not erase these distinctions. It can include a small glossary, explicit units and a mapping table that connects terms while preserving differences.

For example, a dashboard might show “estimated chance of missed follow-up in the next 30 days” rather than a bare “risk 0.2”. Another team can then ask whether 0.2 was a model probability, historical fraction or subjective assessment. The units and estimation method allow constructive challenge without requiring every reader to become a statistician.

The same approach helps multilingual organisations. A label translated into another language may have a different everyday connotation. Use example cases, unambiguous field definitions and competent review, rather than assuming that two words with similar dictionary translations impose identical workflow obligations.

Visual maps as boundary objects

A map can align people who could not easily coordinate through prose alone. In a building project, facilities staff care about access routes, engineers about utilities and occupants about safe movement. One plan with stable coordinates and agreed symbols allows those concerns to be layered without forcing a single all-purpose narrative.

A diagram can also mislead. If scale is absent, a drawn distance may be mistaken for an actual clearance. If arrow semantics are undefined, an arrow may indicate time, causality, flow or responsibility depending on the reader. Provide a legend, units, date, data source and named assumptions. Mark uncertain boundaries as uncertain. A compelling picture without interpretive safeguards may be more dangerous than a modest text table.

Accessibility matters. Do not make colour the sole carrier of meaning; provide text descriptions or alternative views; use headings and readable labels. A boundary object fails its social purpose when an important participant cannot perceive or operate it.

Standardised forms: choosing what must be compulsory

Requiring every person to complete twenty fields can lead to invented filler values and lower-quality records. Start from the errors the shared object must prevent. Make truly necessary fields mandatory and permit an explicit “unknown” or “not applicable” when that is honest. Capture who will resolve an unknown and by when, rather than forcing guesses that later look like facts.

Use validation at the point of entry where it helps. A timestamp should match the expected format, an owner should reference a valid role or identity, and a status transition should obey a defined workflow. Yet validation rules themselves need review. A rule that rejects unusual but legitimate addresses, names or dates creates hidden exclusion. Allow users to report exceptions rather than teaching them to enter fake data.

A structured form is only a boundary object if the consuming groups actually use its shared definitions. Mandatory fields alone do not guarantee mutual understanding.

Repositories need retrieval and provenance

A repository of policies, observations or design artifacts must support the question “which is the authoritative version for this decision?” Search results can surface obsolete copies with plausible titles. A shared repository therefore needs stable IDs, revision dates, clear authorship or custodianship, links to current versions, and an explicit status for superseded material.

Metadata is not glamorous, but it is a bridge between communities. A laboratory technician, researcher and auditor can all find the same specimen or study record even while asking different questions about it. A school coordinator, teacher and family member can trace the same action without everyone seeing private fields that are irrelevant to their role.

Preserving provenance protects against the mistaken idea that an institutional memory is merely a pile of documents. Readers can learn more about the separate problem of loss of know-how in Institutional Forgetting. Boundary objects concern the stable shared reference during coordination; institutional forgetting concerns whether necessary knowledge survives people and organisational changes.

Who gets to design the shared object?

The people closest to the practical work often know which fields are ambiguous or burdensome. An executive committee may choose elegant categories that cannot describe a real case. A software team may privilege data easily captured by machines while excluding important context visible to frontline workers. A participatory design process catches these mismatches early.

Invite representatives of each affected group to bring difficult examples. Ask them to mark where their existing records fail. Give them a chance to challenge terminology, missing fields and access restrictions. Include people who bear the consequences of classification, not just those who produce the classifications. A student or parent may see risks that a professional-only workshop misses.

Participation does not eliminate the need for accountable final decisions. It makes the decision better informed. Where views conflict, record the competing needs and the rationale for the selected representation rather than presenting a contestable design as universally obvious.

Handling asymmetry of power and expertise

Shared artifacts can make collaboration more equitable, but they can also entrench a dominant group’s categories. An organisation may say “the data are consistent” because everyone was forced to use a finance team’s terminology, even when service users or researchers lost vital distinctions. Watch for people maintaining separate informal spreadsheets because the official object cannot represent their reality.

A better design makes local extensions possible without breaking the core fields. It identifies which rules are policy requirements, which are technical conventions and which are open to revision. Users need a visible channel for challenging definitions and reporting harm. The steward should evaluate feedback rather than treating every complaint as user resistance.

This is an intelligence question because evidence is distributed across people. A common representation should aggregate that evidence without pretending that the loudest or highest-ranking participant owns all relevant knowledge. For a related but distinct authority problem, read Decision Rights — Expertise, Authority, Escalation and Responsible Action.

An interface between teams, not a master file of everything

A boundary object is often most effective as a small interface. It states what one team promises to supply and what another team may rely on. This could be an agreed set of data fields, a schedule with precise milestone definitions, a diagram with controlled connection points, or a joint register of outstanding actions.

Do not automatically centralise all local information into one database. That may create privacy risks, unwieldy governance and a single point of failure. A shared interface can reference separate authorised records by stable IDs. Each specialist keeps its necessary local detail while publishing enough shared meaning for the next team to act.

Good interface design also specifies failure states. What happens if a required value is missing? Who resolves contradictory entries? Can the receiving team reject a malformed record? When a definition changes, who must confirm compatibility? These questions convert a static artifact into a dependable working agreement.

Boundary tests are more revealing than happy examples

An ordinary example rarely exposes the weakness of a shared definition. Use ambiguous, rare and disputed cases. Test a deadline that crosses midnight or a public holiday. Test a record with two plausible owners. Test a location that straddles administrative boundaries. Test a status whose evidence arrives after its nominal effective date. If users disagree, ask whether the object lacks a field, a definition or an escalation rule.

Run two groups through the same cases independently. Compare their classifications and ask for reasons. A high agreement rate can be useful, but it must be interpreted alongside accuracy and possible shared misunderstandings. If everyone agrees because the form hides an essential distinction, improved agreement is not improved intelligence.

A productive boundary test produces a concrete change: revised definition, new example, better field type, clearer responsibility or an explicit exception route. Keep the old case as a regression test so the ambiguity does not quietly return.

When dashboards make the misunderstanding worse

A dashboard can make incompatible terms look commensurable through neat bars and percentages. If Team A defines a “completed request” as acknowledged and Team B defines it as resolved, their counts should not appear on the same success chart under an undifferentiated label. Common visual style is not common measurement meaning.

Trace each chart back to its source records, definition and denominator. Include the time window, inclusion criteria, missing data treatment and version of any business rule. Ask what operational decision the chart supports. If the decision is allocation of next week’s capacity, a count of pending actions may be more useful than a historical total of acknowledgements.

The first repair often belongs in the shared object below the dashboard. Renaming a chart without fixing source fields leaves a cosmetic agreement. The W3C’s guidance on providing structural metadata and provenance is relevant because a measure’s interpretation travels with its underlying data.

Measuring whether coordination actually improved

Possible indicators include fewer handoffs rejected for missing information, shorter time to resolve cross-team questions, fewer contradictory definitions, fewer rework cycles, higher record completeness and improved correct action on independently reviewed cases. No single metric captures the whole benefit. A team could reduce rejection rates by weakening checks; it could raise completeness by entering invented placeholders.

Define a small set of intended outcomes, unintended effects and independent quality checks. For example, count cases requiring clarification per 100 handoffs, but also inspect whether users feel pressured to misclassify hard cases. Measure both the effort to enter data and the effort saved downstream. Include people who were previously excluded from the information flow.

A before-and-after trend is suggestive, not automatically causal. Workload, staffing and case mix may have changed simultaneously. If the decision matters substantially, use a stronger evaluation design and label any uncertainty. An artifact earns trust through better work, not merely through a more attractive dashboard.

Repairing a failed boundary object

When a shared form stops working, first locate the mismatch. Was the object inaccessible, too complex, stale, wrongly scoped or semantically ambiguous? Are users entering the same source fact in multiple places? Is a field named “approved” actually blending review, authorisation and completion? Do teams interpret units differently? Repair the mechanism that produced the error, not just the incident’s visible symptom.

Next agree a revised minimum core, test it against the failure case, identify affected reports and historical records, and publish a version change. Communicate the difference in ordinary language. If an old report is now misleading, mark the affected period or rebuild it with a defensible conversion. Do not silently rewrite history to make the new taxonomy appear universal.

Finally, confirm that people can use the artifact on their next real decision. Asking them whether it “looks better” is weaker than observing whether the old error can still happen.

Changed-context exercise: an emergency map across agencies

Imagine a fictional municipal flood response where a road authority reports an “open road” meaning the physical roadway has not been formally closed, while emergency crews use “open” to mean safe for a standard response vehicle at the current water depth. A shared map colours both states green. A volunteer coordinating supplies sees the green route and assumes it is safe. What failed?

The error is not merely insufficient communication. One visual field compressed two different predicates into one symbol. The repaired boundary object needs separate fields for legal closure status, measured or estimated passability for a defined vehicle class, observation time, data source and confidence. It needs a legend and time-sensitive expiry policy. Emergency crews can then see operational passability while road administrators retain the legal status, and both reference the same route ID.

Suppose a route was inspected at 10:00, water rose at 10:30, and the map was checked at 11:00. The last observation is 60 minutes old. A policy requiring operational observations no older than 30 minutes would reject that route as unverified for emergency passage, even if the legal closure status had not changed. The age calculation is 11:00 minus 10:00, or 60 minutes, exceeding the 30-minute freshness threshold by 30 minutes. A shared timestamp makes this decision possible.

Another transfer: a school-to-family support plan

Imagine a teacher documenting a learner’s difficulty with written explanations, a parent reporting successful oral explanations at home and a tutor observing that the learner understands concepts when diagrams are provided. A one-dimensional label of “weak in science” discards important variation. A better common artifact records the learning objective, observed task, modality, evidence date, support tried and next check, while preserving the distinct observations of each participant.

The teacher can use curricular standards, the parent everyday language and the tutor targeted practice examples. The shared object permits those views to coexist around a stable learning goal. It does not turn one observation into a permanent diagnosis. The next action can be tested: ask the learner to explain a familiar concept in writing after diagram-supported practice, then compare with earlier evidence using the same assessment criteria.

The broader educational principle is learning transfer into life. A shared record is useful when it helps everyone recognise and improve the learner’s actual capability, not merely repeat an assessment label.

Limits: not every conflict is a data-definition problem

Sometimes groups genuinely disagree about values, budgets, risk tolerance or priorities. A perfect map cannot decide how scarce resources should be allocated. A standardised form cannot resolve a legal dispute or substitute for qualified clinical judgment. Boundary objects clarify the facts and interfaces so the remaining disagreement can be addressed honestly by legitimate decision makers.

Nor should teams overstandardise creative or exploratory work. Early brainstorming may benefit from multiple provisional descriptions before a shared taxonomy is ready. Prematurely forcing every idea into a fixed set of categories can suppress novelty. The useful boundary object may be a lightweight sketch or question register until the decision requires more precision.

An additional limit is maintenance. A mapping that was helpful last year may become dangerous after rules, interfaces or participants change. Long-term success depends on stewardship, revision, usable feedback and clear retirement of obsolete meanings.

Frequently asked: must everyone use the same software?

No. A boundary object is about stable shared reference and meaning, not necessarily a single platform. Teams can use different systems if identifiers, essential definitions, update rules and evidence links interoperate. Sometimes a simple diagram or paper form is more appropriate than a complex database.

Frequently asked: what makes a boundary object different from a glossary?

A glossary defines terms, but a boundary object also supports actual cooperative work. A common record or map can carry identifiers, current status, evidence, local annotations and agreed interactions. A glossary is often one component of a useful boundary object, especially when language is the main point of confusion.

Frequently asked: can multiple versions coexist?

Yes, if each version is clearly labelled and the receiving parties know which is authoritative for a particular decision. Historical research may need an old scheme; a live workflow may require a new one. The danger is not the existence of versions but an unmarked mixture of their meanings.

Frequently asked: does a high agreement score prove we built it well?

No. Participants can agree on a wrong or overly simplistic classification. Independently verify cases, examine exceptions, check consequences and ask whether affected people can challenge misleading fields. Agreement is only one piece of evidence.

Frequently asked: who owns the final definition?

Responsibility should match the legitimate authority and knowledge needed for the field. A joint interface may require jointly accepted changes, while specific policy definitions belong to their authorised policy owner. Record the steward, approval route and correction process, rather than relying on personal relationships.

A practical reader pathway

If you are a learner, begin by comparing two uses of the same familiar word and identifying the hidden denominator or time window. If you coordinate school or family support, create one shared action record with evidence, responsible person and next review date. If you lead a multidisciplinary team, test a draft interface against five difficult real cases before mandating it. If you design software or policy, version fields and document how older meanings map to new ones. If you audit results, trace every reported number back to its source definition and affected population.

The lasting lesson is that intelligence across people is not merely the sum of their individual knowledge. It depends on the quality of the references through which their knowledge meets. Shared artifacts are useful when they make the relevant differences visible, connect evidence to action and preserve enough meaning for another person to do the next part correctly.

Primary references and connections

For the original research concept, see Star and Griesemer’s 1989 boundary objects article. For current practice in documenting technical responsibility and interface changes, see NASA’s Interface Management. For discoverable, understandable and reusable structured data, see the W3C Recommendation Data on the Web Best Practices.

For related but distinct questions, read the How Intelligence Works guide, Institutional Forgetting, Decision Rights, and Collective Forecasting. For the wider relationship between organisations, learning and technical systems, explore the How X Works hub.

Discover more from eduKate Singapore

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

Continue reading