Context Object Specification (COS)

Version: 0.2
Chapter: 120 — Problem Statement
Status: Informative
Category: Informative

1. Purpose

This chapter explains the problems that motivated the creation of the Context Object Specification (COS).

Unlike the Core Philosophy, which defines the guiding principles of the specification, or the Vision, which describes the future ecosystem, this chapter focuses on the limitations of existing approaches.

Understanding these limitations is essential for understanding why a new protocol is necessary.

This chapter is informative.

It does not define requirements.

Instead, it establishes the motivation for the specification.

2. The Current State

Modern browsers already provide mechanisms for obtaining user selections.

Typical examples include:

window.getSelection()

or

Selection.toString()

These APIs are sufficient for retrieving the characters selected by a user.

However, they provide very little information about the selection itself.

Applications typically receive only plain text.

For example:

const text = window.getSelection()?.toString();

Once the text leaves the browser API, almost all contextual information has already been lost.

3. Plain Text Is Not Context

Plain text answers only one question:

What characters were selected?

It does not answer more important questions such as:

• Where does the selection come from?
• What document contains it?
• Which section is it located in?
• Is it code, prose, a heading, or a table?
• What language is it written in?
• What content appears before or after it?
• What surrounding structure gives it meaning?

Without these answers, downstream systems must reconstruct context using incomplete information.

This reconstruction is often inaccurate, expensive, and inconsistent.

4. Every Application Rebuilds Context

Today, every AI-enabled application performs similar work.

Whether the application is:

• a browser extension
• a documentation website
• a PDF viewer
• a note-taking application
• an online editor

the workflow is usually similar.

1. Obtain the selected text.
2. Search for surrounding content.
3. Detect document structure.
4. Determine semantic information.
5. Build prompts.
6. Send data to AI.

Although implementations differ, the underlying process is remarkably similar.

Each product rebuilds the same contextual understanding independently.

This duplication results in:

• repeated engineering effort
• inconsistent behavior
• incompatible data structures
• difficult integration

The industry lacks a common representation for contextual information.

5. Existing Browser APIs Stop Too Early

Browser APIs intentionally provide low-level primitives.

Their responsibility ends once the user’s selection has been identified.

Everything beyond that point is left to individual applications.

For example, browser APIs do not describe:

• document hierarchy
• semantic meaning
• surrounding nodes
• reading order
• contextual relationships
• recommended downstream actions

These responsibilities belong to higher-level software.

The Context Object Specification defines a standard way to represent this higher-level information.

6. AI Applications Need Structure

Large Language Models consume text.

Software applications consume structured data.

When AI becomes part of software systems, both requirements exist simultaneously.

Applications therefore need a representation that is:

• structured
• portable
• deterministic
• extensible

Passing plain text directly into AI models tightly couples applications to prompt engineering.

Instead, applications should first produce a structured representation.

Prompt generation becomes a separate concern.

This separation improves interoperability and long-term maintainability.

7. The Missing Standard

Many standards already exist.

Examples include:

These standards successfully describe documents.

None of them describe the contextual meaning of a user’s current selection.

Consequently, every application invents its own representation.

The result is fragmentation.

The Context Object Specification addresses this gap.

8. Context Should Be Portable

A browser extension and a PDF viewer may implement completely different technologies.

However, if a user selects the same paragraph, downstream consumers should not care how that selection was produced.

They should receive the same contextual representation.

This portability allows:

• reusable AI integrations
• reusable workflow engines
• reusable automation
• reusable plugins
• reusable prompt adapters

Portability is impossible without a shared representation.

9. Why Another Protocol?

The purpose of COS is not to replace existing standards.

Existing standards already solve different problems.

Instead, COS introduces a new layer.

Browser APIs
        │
        ▼
Selection
        │
        ▼
Context Object
        │
        ▼
AI / Search / Workflow / Automation

The Context Object acts as a bridge between low-level browser interactions and higher-level intelligent systems.

Without this intermediate layer, every application must repeatedly solve the same problem.

10. Design Implications

The problems described in this chapter directly influence the design of the specification.

Therefore:

• Context MUST be represented as structured data.
• Browser APIs MUST remain implementation details.
• AI models MUST remain consumers rather than producers.
• Prompt generation SHOULD remain outside the core protocol.
• Context Objects SHOULD be portable across applications.

These implications are explored in subsequent chapters.

11. Summary

The Context Object Specification does not exist because browsers cannot obtain selections.

Browsers already solve that problem.

The specification exists because software lacks a standard representation of contextual understanding.

The missing capability is not text extraction.

The missing capability is context representation.

The Context Object Specification defines that representation.