Engelbart for Spaces¶

p1What fifty years of Doug Engelbart’s work says about building steward-run workrooms for humans and agents, and about large-scale distributed coordination in general.

p2Prepared 2026-09-03 from a full read of dougengelbart.org: the Institute’s vision, strategy, glossary, OHS specification and technology template pages; the 1961 program proposal, the 1962 framework, the 1968 and 1969 demos, the 1972 community-services paper, the 1973 knowledge-workshop paper, the 1980 “organization of the future” paper, the 1985 lab history, the 1988 BYTE article, the 1990 interoperability paper, the 1992 groupware strategy paper, the 1995 CACM paper, the 1998 NSF proposal, the 2002 and 2003 “Improving Our Ability to Improve” talks, the 2004 call to action; the 140-slide Paradigm Map deck; and the 2000 Stanford colloquium sessions on collective IQ, bootstrapping, improvement communities, scalable infrastructure, pilot outposts, and next steps. Source URLs are listed at the end. Quotations are verbatim.

1. Why Engelbart, and why now¶

p3Engelbart’s stated goal from 1951 on was not the mouse or hypertext. It was to boost “mankind’s collective capability for coping with complex, urgent problems.” Everything else was, in his words, a secondary derivative. Between 1963 and 1977 his Augmentation Research Center at SRI built and lived inside a networked system in which a distributed community of humans, plus an automated “clerk,” kept a permanent citable record of dialog, worked from shared structured documents, tracked tasks and roles, reviewed each other’s work, and ran a public information center for the entire ARPANET. That is the Spaces problem, solved once, at 1970s scale, with lessons about why it eventually dispersed.

p4Two things make him unusually relevant to Spaces specifically:

• He treated the organization, not the individual, as the unit of augmentation. “Three people working together in this augmented mode seem to be more than three times as effective in solving a complex problem as is one augmented person working alone.” He predicted the group effect would matter more than the individual effect, and built for it.
• He anticipated agents as members. The 1998 NSF proposal describes knowledge work as “the concurrent contribution of a broad diversity of players (potentially including intelligent software agents or other entities derived from artificial intelligence), over time and space.” His line between augmentation and automation is exactly the line Spaces draws: does the machine widen the human channels inside the shared record, or does it “stand over there, apart from the human, doing its thing”?

2. The framework in one page¶

p5Engelbart’s ideas form a loop, not a list. The Institute’s Paradigm Map lays out fifteen tiles, each a shift in thinking an organization must make. In reading order:

p6Three supporting structures recur everywhere:

p7The Dynamic Knowledge Repository (DKR). Every organizational unit, of any size, owns “a living, breathing, rapidly evolving repository of all the stuff accumulating moment to moment.” It has three domains: recorded dialog (memos, minutes, decision trails, rationale, change requests, commentary, lessons learned), intelligence collection (what the unit ingests from outside), and knowledge products (plans, proposals, specs, source code, the community “handbook”). Collective IQ is a property of how well these three interact.

p8The OHS requirements. Every object has a global, human-readable, stable address. Every object is time-stamped with its author. Documents are explicitly structured. Views are generated on demand: level clipping, truncation, content filtering, algorithmic reorderings. Links jump, transclude, or execute, and carry a view specification. Back-links show who cites any passage. A Journal accepts submissions, assigns permanent catalog numbers, notifies recipients with links, records supersession, and guarantees access. Replies cite rather than copy. Signatures verify segments even after copy or move. Access control reaches down to the object. One verb-times-noun command vocabulary underlies many look-and-feel interfaces.

p9The NIC and Meta-NIC. An improvement community is any group jointly improving a capability. A NIC is one that deliberately works on its own collective IQ and its own DKR. A Meta-NIC, or “C community,” is a NIC of NICs: the C activities of many organizations pooling the pre-competitive work of improving how they improve. “Even competitors could consider cooperating, ‘out of their back doors’ while competing like hell out of our front doors.”

3. What actually ran, and what it taught¶

p10The 1962 framework is often read as vision. The more useful material is the record of what ARC built and used daily.

p11Statements and addresses. Every paragraph, code line, roster entry, and message was a statement in an explicit hierarchy, with a positional number that changed on restructure and an optional stable name that did not. Every statement carried author and last-edit time, and the file could be filtered by author since a given time. A citation like (27143,6A5) meant Journal item 27143, statement 6A5, and it could be followed by hand from paper.

p12Viewspecs. Level clipping, truncation, content filters written as ordinary text and compiled on demand, frozen statements pinned above the scrolling window. Users changed views “several times in as many seconds.” Links carried the view the author wanted the reader to land in.

p13The Journal (1970). “A mail item was a document, so any part of all of an NLS document could be sent.” Submissions received permanent catalog numbers, were stored read-only, notified recipients with links, declared what they superseded, carried keywords, and were indexed. Email was for “throw-away communiques”; “all memos, status reports, meeting minutes, design change requests, field support logs, bug reports” went to the Journal. Review comments attached to the object in question with links to related passages. The ARC Journal from 1970 onward is now an archival collection at the Computer History Museum with its own finding aid.

p14The Ident system. People were addressed by identifier “with no need to know or specify which host they used.” Groups expanded into distribution lists.

p15Shared screen (1968, generalized 1972). The viewer saw the shower’s screen with a second cursor; control was reserved to the owner and could be passed: “Here, you control it.” Later, moderated and free-for-all modes.

p16The Network Information Center (1969-1991). Engelbart volunteered on the spot at the 1967 ARPANET planning meeting to run it: who is up, what services, which protocols, user guides, host tables, the ARPANET Resource Handbook. It gave the lab a real outside community, drove hyper-mail and the Journal, and outlived the lab by fourteen years under its own principal investigator.

p17Roles. Workshop architects as “change agents” in customer organizations; trainers, cataloguers, facilitators, database administrators as budgeted “people-support services”; psychologists and social scientists on staff “as important to our team as the hardware and software developers”; a Knowledge Workshop Architects Community across pilot sites. A program librarian process recompiled changed code nightly and linked a new system only if everything compiled.

p18Dogfooding by principle. By 1966 all source code, documentation, plans, budgets, and proposals lived in NLS. In 1974 the lab gave up its fast local displays “to make ourselves live with the same remote services as our NIC clients and Utility customers.”

p19Why it dispersed. Engelbart’s own retrospective names three causes. The institutional form was wrong: SRI ran labs as a “farmers’ market” of short projects, while ARC was a long-lived infrastructure and service program. Funding drifted after 1974 to targets set by others, and “the continuing pursuit of augmentation along my strategic vector virtually stopped.” And the market was not ready: “it isn’t the market’s fault if someone fails in trying to sell it something that it isn’t ready for.” The industry then optimized for the novice; his verdict was that “if ease of use was the only requirement, everybody would still be riding tricycles.” Bootstrapping also had a cost he acknowledged: “as soon as we became used to ways of doing things, we replaced platforms to which we were just becoming accustomed.”

4. Insights for building Spaces¶

p20Each item below names the Engelbart idea, the current state of the Spaces protocol as of this writing, and a concrete move. Current-state claims come from the repo’s schemas, protocol docs, and backlog.

4.1 The event log is a Journal. Finish making it one.¶

p21Spaces already has the hard part: an append-only, typed, actor-stamped event log with host-wide monotonic cursors, and content-addressed immutable Resource versions. That is Engelbart’s Journal in substance. Four Journal properties are missing:

• Citable addresses. Task IDs and message IDs are per-Space integers, event IDs are host-wide serials, and none survive a merge across hosts. Engelbart’s rule: “every object that someone might validly want/need to cite should have an unambiguous address, capable of being portrayed in a manner as to be human readable.” Give every event, task, message, result, review, and resource version a stable, portable, typeable address that includes the Space and survives export and replay.
• Supersession as an event. Resources have versions, but tasks, results, and messages have no supersedes relation except the administrative linked_task_id on closure. Add a supersedes field to the common event envelope, and let readers of an old item see the pointer forward. “A backlinking facility within the recorded dialogue system is also necessary to handle superseding of old documents by new.”
• Back-links as a served index. The Journal’s most distinctive coordination feature was that a reader of any passage could see later passages that cite it. On an append-only log this is cheap: index every citation at write time and serve a back-link query. Today TaskLinks and MessageLinks are convenience URLs, not relations.
• Two tiers of talk. Spaces already has the principle: “Messages provide context; typed records change state,” and chat is “information, never instruction.” Engelbart drew the same line between throw-away email and Journal submissions. Make the line visible: a one-step “promote this message to the record” action, and views that clip chat away and show only journaled items.

4.2 Address inside objects, not just objects¶

p22Spaces addressing bottoms out at the task, message, or resource. Reviews cannot anchor to a paragraph of a result; a message cannot cite a clause of the charter. Engelbart’s purple numbers are the fix: auto-assigned paragraph identifiers in every Message, Result, Resource, and Charter body, plus author-assignable stable labels, so a citation can be (task 42, result 2, paragraph 3b). Represent citations as structured link fields, not only Markdown, so the server can maintain the back-link index. Replies should cite the parent rather than quote it; the client transcludes.

4.3 Build the handbook, and make accepted work flow into it¶

p23The backlog’s “Space handbook” item, a per-Space Markdown document that is “the space’s CLAUDE.md,” steward-gated, content-addressed, and emitting a revision event, is Engelbart’s community handbook almost word for word: “a uniform, complete, consistent, up-to-date integration of the special knowledge representing the current status of the community,” containing “principles, working hypotheses, practices, glossaries of special terms, standards, goals, goal status, supportive arguments.” It is also the prompt-injection boundary, which is a good reason to build it first.

p24What Engelbart adds beyond the backlog item is the handbook cycle: dialog and intelligence, then facilitated integration, then a new certified version. Today done tasks do not become knowledge; the arrow from Done to Resource in the collaboration-primitives diagram is a diagram, not code. Make the accepted result the “certified community position,” let later tasks cite and supersede it, and have the handbook expose the current position with the trail of superseded versions. A clerk agent can draft handbook revisions from accepted results; the steward ratifies.

p25Partition the Space’s record into Engelbart’s three domains as views over one log, not separate stores: recorded dialog (messages, task threads, reviews), knowledge products (accepted results, goals, handbook, charter), intelligence (external material cited from dialog, held in the content-addressed store).

4.4 Goals are recursive, and they carry their reasons¶

p26Goals are advertised but not built, and there is no task-to-task parent link. Engelbart’s model is a contractor network: each capability “is represented by an independent contractor whose mode of operation is to do the planning, make up specifications, subcontract the actual work, and supervise the performance of his subcontractors.” A task’s plan is a goal at the next level down. So:

• Build the Goal contract the backlog describes, but make goals recursive: a task may decompose into child tasks, and reviewing is supervising the subcontractors.
• Link every goal and task to the considerations that justified it. Engelbart’s own eight-year card system taught him that “when that product statement came to be modified through some other consideration, it was not always easy to remember why it had been established as it had.” Losing the why is the default failure of large records.
• Propagate specification changes. His central cost of flexibility: when the top changes its mind, “each contractor involved in the process would have the specifications upon which he bid continually changed.” Emit a spec_changed_since_claim event for every open claim beneath a changed goal or parent, and let the clerk list what changed.

4.5 Contention is data, placed where it applies¶

p27Review in Spaces is a gate with independence rules and proof stages. Engelbart’s team practice adds the argument. An objection is “appended where the disagreement lies,” tagged with “a special cue that signals a point of contention that must ultimately be resolved,” and “most points of contention are resolved quite naturally, over a period of time, as the developing structure of argument bears out one, or the other, or neither stand.” For Spaces: a typed objection review note anchored to a paragraph of the result, visible in the steward’s queue until resolved by supersession or decision. Review events should carry fields for decision, rationale, and citations, plus a “lessons learned” tag so a later C-level pass can harvest them. Claim expiry and review-request expiry already exist; they are Engelbart’s “automatic ticklers to those who do not respond.” Extend them to unanswered proposals and stale contention.

4.6 The steward is a facilitation unit, and the clerk should do its bookkeeping¶

p28Engelbart’s answer to organizational hill-climbing was “an explicitly chartered, full-time, internal organizational unit whose main work is to facilitate the organization’s self-development.” In Spaces that unit is one role, the steward, which is today an accountability record rather than an authorization boundary. Two moves:

• Give the steward the views the job needs: unresolved contention, review backlog, stale claims, spec-changed claims, the ready queue, plan-change alerts, and a digest whose cadence scales with velocity.
• Install the Clerk. Engelbart’s 1962 clerk “look[s] over the structure to detect inconsistency or redundancy,” points out effects on the rest of the structure, and installs “road signs” for humans; the 1992 Journal clerk assigns numbers, notifies, records supersession, and catalogs. “We could expect significant gains from automating the H-LAM/T system if a computer could do nothing more than increase the effectiveness of the executive processes.” A per-Space clerk agent whose duties are executive (keep the plan current, detect duplicates, summarize, surface supersessions, run the tickler pass) is the highest-leverage agent role, and leaves the steward with judgment: acceptance, rule changes, contention. “Even a necessary superstructure is a burden.”

4.7 The charter is the Space’s language and method, versioned and addressable¶

p29The charter is today a 10,000-character string on the Space with no revision event. Engelbart’s charter equivalent is the handbook’s glossary, categories, and operating sequence, and his rule for any specification is that it be “concise, unambiguous, canonical, natural, easy to compose, study, and modify” and that “everything described actually works as indicated.” So: store the charter as a statement hierarchy with named clauses, so tasks and decisions cite charter:review-gate by name; emit charter_revised; make rule changes tasks whose acceptance supersedes clauses. Where a rule is enforceable (review policy, join policy, claim TTL), make it configuration the server reads, so charter equals configuration equals documentation. The Zod-to-OpenAPI decision is this lesson applied to the protocol; extend it to per-Space rules.

4.8 One vocabulary, many interfaces, and do not cap at easy¶

p30Engelbart’s architecture put a common command-language interpreter under every interface so that “users should learn about their tools and materials, and do their discussing with others about their work, using the underlying common-vocabulary terms no matter what form of user interface they employ.” Spaces is close: the MCP tools mirror the REST operations, and the spec is generated from one schema. Formalize it: publish the verb-times-noun vocabulary (propose, claim, submit, review, decide, cite, supersede, over task, result, goal, message, resource, charter) and use the same words in UI labels, MCP tool names, docs, and the activation pack. Then honor his warning: the web app is the novice path, the protocol is the high-performance path, and “it is quite unlikely that the road to truly high performance can effectively be traveled by people who are stuck with vehicular controls designed to be easy to use by a past generation.” Reward proficiency; do not remove capability from the protocol to simplify the UI.

4.9 Agents: executive first, at many levels, with a handoff protocol¶

p31Engelbart’s ordering of payoff is the opposite of most agent deployments. Automate the executive layer first, because it compounds through every level; leaf execution is one-shot. His specialist-helper protocol is worth copying literally: the helper “would keep track of the complex procedure and execute all the steps he could. When he came to a step that was too big for him, he would hand you enough information to allow you to take that step, whereupon he would take over again.” In Spaces that is a task state, not a chat message: a needs_human transition carrying exactly the information a human needs, after which the agent resumes. The activation pack’s lenses (Reviewer, Driver, Scout, Facilitator, Skeptic) are Engelbart’s roles; make them structured, Space-editable records rather than prose delivered once. And keep the accountability rule absolute: every agent action is an event with authorship and the operator it acts under, because “accountability is absolute” is what made open participation safe in the Journal.

4.10 Spaces of Spaces: the Meta-NIC is the growth pattern¶

p32Cross-Space networking is today one endpoint, a cross-Space open-work feed. Engelbart’s structure for scaling is the NIC of NICs: a community whose members are the improvers of other communities, whose tasks are cross-community improvement work, and whose products are handbook entries others adopt. The spaces-product Space is exactly a C-level Space, and the Bootstrap Alliance’s three-tier channeling (alliance to member pilots to member organizations, feedback up) is the pattern for it. Protocol needs: global rather than Space-local addresses, cross-Space citation and back-links, and an “adopt this result into my Space” operation that preserves provenance and signature. His “frontier map” idea, a DKR that shows what leading members are doing so each can choose its own next move, is what a Meta-NIC Space should render across member Spaces, read-only, through the public protocol.

4.11 Portability is the Journal’s guarantee of access, not a feature¶

p33Export and replay are claimed founding properties and are not implemented; nothing today survives a host merge. Engelbart’s Journal guaranteed access by catalog number forever, and his memex reading treated trails as copyable “as a whole or by pieces of concept, principle and technique.” Export must preserve addresses, stamps, signatures, and cross-Space citations, and replay must accept a view-spec filter so a Meta-NIC can import only accepted results. Add optional signatures to events and results now, so verification survives the move: “signed document segments can be copied or moved in full without interfering with later signature verification.”

4.12 Measure the two things Engelbart required, and no more at first¶

p34His minimal methodology for a bootstrapping group was to know “(a) when an improvement in effectiveness has been achieved, and (b) how to assign relative value to the changes derived from two competing innovations.” The participation doc already names the right measure, useful accepted work per unit of review attention, and nothing computes it. Compute it from the log. His usage-monitoring idea, a periodic review package that “almost always reveals things to me that change at least the slant of my approach during the next hour,” becomes a Space digest at velocity-scaled cadence. His contribution-scoring idea, a process over the action record that “pick[s] out the steps which contributed the most,” had “a surprisingly positive psychological effect” on a cooperating team precisely because it was derived from the structure rather than declared. Offer it as a steward-visible analysis, never a leaderboard.

4.13 Run outposts, dogfood strictly, budget the human system¶

p35The deployment advice is specific. Mode 1, rolling a change across the board, yields incremental gains. Mode 2 is the pilot outpost, “an elite expeditionary force forging a path further out on the frontier.” Mode 3 expands its scope; mode 4 clones it. A prototype team of “five to ten people” is the organizational model. So the first Spaces should be a handful of high-intensity workrooms with a steward who journals lessons learned, before any broad rollout.

p36Dogfooding is the method, not a nicety. “Be your own most rigorous and demanding end-users.” The Spaces backlog already plans to move itself into a Space; do it early, and prefer living with the protocol’s limits over adding private shortcuts, because “OHS-1 to OHS-2” is how the next requirements are generated.

p37Budget the human side. “The important part of the organization’s evolution is the human part. These elements take much longer to establish or change than do new hardware or software.” Onboarding, facilitation, and handbook editing are roles with time attached. Expect “an initial period of negative reaction in reading explicitly structured material,” and log method changes as decisions so the human-system side of co-evolution is in the record too.

p38Finally, match institutional form to the activity. ARC died inside a short-project institution while running long-lived infrastructure. “Hosted equals self-hosted, same artifact” and open source are the right hedges; Engelbart’s colloquium verdict was that “there’s just absolutely no way it can evolve with a proprietary push underneath it.”

The first five moves, in order¶

1. Global, human-readable addresses for every object and paragraph, plus cites[] and supersedes on the event envelope and a back-link query.
2. The Space handbook with a revision event, and the handbook cycle that draws accepted results into it.
3. Recursive goals with consideration links and spec-change propagation to open claims.
4. A per-Space clerk agent with executive duties and a needs_human handoff state.
5. Export and replay that preserve addresses and signatures, then cross-Space citation, so a Meta-NIC Space can exist.

5. Insights for large-scale distributed coordination generally¶

1. p39Coordination capacity is a property of organization, not of participants. “Intelligence seems primarily to be associated with organization.” Improving coordination at scale means redesigning the structure of steps, links, and views, not recruiting smarter participants, human or machine.

2. p40Improvement needs its own infrastructure, and improving the improvers is the highest-leverage layer. Make A, B, and C explicit, budget them, and give each its own recorded knowledge base. Left implicit, C never happens. “Surprisingly, most organizations are barely conscious of their C Activity.”

3. p41Cooperation is easiest at the C level. Proprietary content falls off from A to B to C, so cross-organization networks should form around how members work, not what they make. That is where competitors, agencies, and nonprofits can share.

4. p42Coordination scales with addressability. Unless any participant can cite any statement in any prior contribution with a stable, human-readable address, dialog degrades into copies and paraphrase. The core query of a coordinating community is “who cited this, later, and what did they say.”

5. p43An immutable record with explicit supersession beats mutable documents. Never edit the record; submit a new version that declares what it supersedes, and let readers of the old find the new. Version history becomes a social object.

6. p44Two tiers of talk must both exist and be distinguishable. The failure mode of email and chat is one tier. Engelbart’s disaster-response example: “the chaotic flow of messages between the different people and organizations during a disaster falls far short of creating the information framework that is required.” Promotion from chat to record should be one action.

7. p45One canonical structure, many views. Level clipping, filtering by author, time, and type, and shareable view parameters let a single shared record serve as agenda, status board, roster, and archive. Filters are themselves stored, shared artifacts.

8. p46Decisions carry their antecedents; arguments are networks, not chains. Link every product statement to the considerations that produced it so “How come?” and “So what?” are answerable later by newcomers and machines.

9. p47Contention is data, placed where it applies. Objections appended at the point of disagreement, typed as contention, mostly resolve as the argument develops; only residual contention needs an authority. “No one can dominate the show, since seldom do you have to ‘listen’ to the person concurrent to the developments he is pursuing.”

10. p48The executive superstructure is where the cost is. Planning, specifying, supervising, re-specifying, and record-keeping consume the scarce talent. Automate bookkeeping first; it compounds. Flexibility at the top is paid for by cheap change-propagation down the chain.

11. p49Concurrency and nesting are the normal case. Every unit runs its knowledge loop concurrently with siblings, parents, children, and partners; much of one unit’s intelligence is another’s dialog. Interoperability of knowledge domains is a first-order requirement, not a later integration.

12. p50Co-evolve human and tool systems, and expect the human side to be slower. Roles, conventions, vocabulary, and training must be designed and recorded alongside tools, or tools automate obsolete processes. Bring observers in; expect resistance in yourselves.

13. p51Bootstrap, and select for recursiveness. The network’s own operation should run on the capability it is improving. Recruit members whose improvement focus aligns, so their results feed the pool. Feedback loops turn linear gains into compounding: “the better we get at getting better, the faster we will get better.”

14. p52Explore with outposts, transfer through people. Advanced pilots staffed by rotating members who then work from home sites carry knowledge both ways; the experience “living out there in a real, hard-working CODIAK frontier” transfers what documents cannot. Scale by expanding then cloning outposts.

15. p53Standardize the vocabulary, not the interface. A shared verb-noun vocabulary under many look-and-feels lets beginners and experts, humans and agents, work the same record. Reward proficiency.

16. p54Frontier maps over central plans. A coordinating body’s product is a map of what leading members are doing so each can choose its next move. It integrates, analyzes, and portrays multi-source contributions; it does not mandate.

17. p55Signatures, stamps, and permanence make accountability portable. Time and author stamps on every object, verifiable signatures that survive copying, and read-only journals let trust move between organizations and hosts.

18. p56Machine helpers work best as clerks and specialists with a handoff protocol. Rule-following and bookkeeping autonomously; hand the human exactly what is needed at the steps that exceed them; then resume. The mature state is role reversal, where the machine installs navigation for humans.

19. p57Language is infrastructure. Coin names for recurring processes, define categories and relation types explicitly, provide a terminology interface between groups. Vocabulary design is coordination design.

20. p58Paradigm work is real work. Perception of scale, of what is possible, and of the need for C activity must be cultivated deliberately: “cultivating the appropriate paradigm about how to view and approach the future will be the single most critical success factor of all.”

21. p59Markets will not fund the record. Discontinuous coordination infrastructure has to be built by a chartered group that uses it, then offered outward. Match institutional form and funding horizon to the life of the record.

6. Where to be careful¶

p60Engelbart was right about structure and wrong about timing, and some of his mechanisms never shipped.

• The 1962 clerk, contribution scoring, and hourly self-review were vision, not practice. ARC ran the Journal, viewspecs, shared screen, and the NIC; the automated consistency-checker and the action-record scorer did not exist. Agents make them plausible for the first time, which is a reason to build them carefully, with the steward in the loop.
• Self-undercutting is a real cost. Continuous replacement of one’s own platform is expensive in morale and skill. Log method changes as decisions and pace them.
• The interoperability standards never landed. Even now, “the ability to link directly to any point in any file” remains ad hoc across the web. Spaces cannot fix the web, but it can make fine-grained addressability a conformance requirement for hosts.
• Ease of use won the market for thirty years. Engelbart lost that argument commercially. The hedge is not to reject ease but to keep the high-performance vocabulary complete under it.
• The human system is slower than any of this. Every recommendation above that touches roles, conventions, or training will take longer than the code. Budget accordingly.

Sources¶

p61All from dougengelbart.org unless noted.

• Vision, Strategy, Call to Action, Academy, Paradigm Map, Key Concepts glossary, About OHS, Bootstrapping Brilliance, Initiatives, Vision and Mission: /Vision, /Strategy, /Call-to-Action, /Academy, /Paradigm-Map, /Glossary, /ohs, /Bootstrapping-Brilliance, /Initiatives, /content/view/102/
• Program On Human Effectiveness (1961): /content/view/409/
• Augmenting Human Intellect: A Conceptual Framework (1962): /pubs/augment-3906.html
• A Research Center for Augmenting Human Intellect (1968): /content/view/140/
• 1968 demo transcript and outline: /pubs/video/fjcc68/Englebart's-1968-Transcription.html, /content/view/333/; 1969 demo: /content/view/378/
• Coordinated Information Services for a Discipline- or Mission-Oriented Community (1972): /content/view/113/
• The Augmented Knowledge Workshop (1973): /content/view/133/
• Evolving the Organization of the Future (1980): /content/view/143/
• Workstation History and the Augmented Knowledge Workshop (1985): /content/view/112/
• Working Together (1988): /content/view/131/
• Knowledge-Domain Interoperability and an Open Hyperdocument System (1990): /content/view/114/
• Toward High-Performance Organizations: A Strategic Role for Groupware (1992): /content/view/116/
• Toward Augmenting the Human Intellect and Boosting our Collective IQ (1995): /content/view/376/
• OHS Technology Template (1998): /pubs/alliance-980.html; Draft OHS Project Plan (2000): /content/view/189/
• NSF KDI proposal, Augmenting Knowledge Networks (1998): linked from /KDI-Proposal
• Improving Our Ability to Improve (2002, 2003): /content/view/348/, /content/view/399/
• Augmenting Society’s Collective IQs (2004): /content/view/132/, /content/view/194/
• Stanford Colloquium 2000, sessions 3, 5, 6, 7, 8, 9, 10: /colloquium/session_NN/session_NN.html
• Paradigm Map slide deck: /pubs/slides/paradigmmap.pdf
• Firsts: Networking, Knowledge Work, Hyperlinked, Collaborative: /content/view/160/, /content/view/339/, /content/view/158/, /content/view/157/
• Community and Technology Showcases: /projects/community-showcase.html, /projects/technology-showcase.html

Image credits

• Augmentation Research Center Wired Article.jpg: SRI International, Public domain, via Wikimedia Commons.
• ON-Line System (NLS), SRI (1960-1970s) - three-button mouse and chord keyboard - Computer History Museum.jpg: Michael Hicks from Saint Paul, MN, USA, CC BY 2.0 (https://creativecommons.org/licenses/by/2.0), via Wikimedia Commons.
• SRI Bill English 1968.jpg: SRI International, CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0), via Wikimedia Commons.
• SRI Computer Mouse.jpg: SRI International, CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0), via Wikimedia Commons.
• SRI Douglas Engelbart 1968.jpg: SRI International, CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0), via Wikimedia Commons.
• SRI Douglas Engelbart 2008.jpg: SRI International, CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0), via Wikimedia Commons.