Context Object Specification (COS)

Version: 0.2
Chapter: 100 — Core Philosophy
Status: Normative
Category: Foundation

1. Purpose

This chapter defines the core philosophy of the Context Object Specification (COS).

Unlike implementation details, APIs, or programming interfaces, the philosophy described here is intended to remain stable throughout the lifetime of the specification.

Every component of the specification—including the data model, pipeline architecture, extension mechanism, and future implementations—MUST follow the principles defined in this document.

Whenever an implementation decision conflicts with one of these principles, the principles defined here take precedence.

2. Why Context Object Exists

Large Language Models (LLMs) have fundamentally changed how software consumes information.

However, most applications still provide context in an extremely primitive form.

For example:

llm(selection.text)

Although technically valid, plain text rarely represents what the user is actually focusing on.

A text selection alone cannot answer questions such as:

• Where did this content come from?
• What document does it belong to?
• What section is it located in?
• What surrounds it?
• What is its semantic meaning?
• Why is the user likely interested in it?

These missing pieces are collectively referred to as Context.

The purpose of the Context Object is not to replace user content.

Its purpose is to describe the user’s current focus in a structured, portable, and machine-understandable way.

3. The Philosophy of Context

The Context Object Specification is built upon five fundamental philosophies.

These philosophies define the identity of the project and guide every future design decision.

Philosophy 1 — Context Over Content

Statement

Applications SHOULD describe context rather than only transmitting content.

Rationale

Content represents what the user selected.

Context represents what the selection means within its environment.

For example, these two selections may contain identical text:

this

Yet they may represent entirely different meanings depending on their surrounding context.

Without contextual information, downstream systems are forced to infer meaning from incomplete data.

The Context Object exists to eliminate this ambiguity.

Philosophy 2 — Attention Over Selection

Statement

The specification describes user attention rather than browser selection.

Rationale

A browser selection is only one possible way users express interest.

Other examples include:

• clicking an element
• tapping on mobile devices
• focusing an editor block
• selecting a PDF region
• selecting an image
• selecting OCR results
• voice highlighting
• AI-generated focus

These interactions all represent the same underlying concept:

The user is currently paying attention to something.

Therefore, the specification models attention, not browser APIs.

Browser selections are simply one implementation.

Philosophy 3 — Structure Over Prompt

Statement

Structured data MUST always be the primary representation.

Prompt generation SHOULD be treated as an adapter.

Rationale

Prompts are optimized for individual AI models.

Structures are optimized for interoperability.

A Context Object should remain valid regardless of whether it is consumed by:

• OpenAI
• Claude
• Gemini
• DeepSeek
• Search engines
• Workflow systems
• Automation tools

Prompt generation is therefore considered an output format rather than part of the specification itself.

Philosophy 4 — Protocol Over SDK

Statement

The Context Object Specification defines a protocol rather than an SDK.

Rationale

SDKs evolve.

Frameworks evolve.

Programming languages evolve.

Protocols tend to remain stable for decades.

The specification defines:

• object structures
• relationships
• semantics
• compatibility rules

Implementations are expected to follow the specification rather than define it.

Philosophy 5 — AI Is a Consumer, Not the Center

Statement

Artificial Intelligence is one consumer of Context Objects.

It is not the owner of the specification.

Rationale

Although the project originated from AI applications, the Context Object is intentionally designed as a general-purpose representation of user attention.

Potential consumers include:

• AI assistants
• Search engines
• Knowledge systems
• Browser extensions
• Automation workflows
• Multi-agent systems
• IDE tooling
• Analytics engines

The specification therefore avoids assumptions that only apply to AI systems.

4. What This Specification Defines

The Context Object Specification defines:

• how user attention is represented
• how contextual information is organized
• how semantic understanding is attached
• how implementations remain compatible
• how extensions integrate with the core model

The specification intentionally does NOT define:

• LLM APIs
• Prompt templates
• AI providers
• Embedding models
• Vector databases
• Chat history
• Agent orchestration

These concerns belong to higher-level application layers.

5. Long-Term Vision

The long-term vision of the Context Object Specification is to establish a common language for representing user attention across different document types, platforms, and intelligent systems.

Regardless of whether the source is:

• HTML
• Markdown
• PDF
• Office documents
• Rich text editors
• Images
• Future document formats

they should all be capable of producing a compatible Context Object.

Applications consuming Context Objects SHOULD NOT need to understand how the original content was produced.

Instead, they consume a unified representation of context.

6. Design Consequences

The philosophies defined in this chapter have several direct consequences.

1. The specification MUST remain implementation-independent.

2. Every pipeline stage MUST enrich the same Context Object rather than replace it.

3. New document formats SHOULD require adapters rather than changes to the core model.

4. Prompt builders SHOULD be implemented as optional consumers.

5. Extensions MUST NOT modify the semantics of the core specification.

These consequences guide every chapter that follows.

7. Summary

The Context Object Specification is not an AI SDK.

It is not a browser library.

It is not a prompt framework.

It is a protocol for describing user attention in a structured, portable, and extensible manner.

Everything defined in subsequent chapters is expected to follow this philosophy.

This philosophy is considered normative for the entire specification.