COS v0.2 Draft ChaptersSingle pageJSON Schema

Context Object Specification (COS)

Version: 0.2
Chapter: 130 — Terminology
Status: Normative
Category: Normative

1. Purpose

This chapter defines the normative terminology used throughout the Context Object Specification (COS).

Every capitalized term defined in this chapter has a specific meaning within the protocol.

Unless otherwise stated, implementations, documentation, plugins, and future specifications MUST use these terms consistently.

The terminology defined here serves as the common language shared by Producers, Consumers, Adapters, Plugins, and future implementations.

2. Terminology Conventions

The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

Unless explicitly redefined, each term has exactly one meaning within the Context Object Specification.

Implementations SHOULD avoid introducing alternative names for existing concepts.

For example, if the specification defines the term Selection, implementations SHOULD NOT replace it with:

Consistency of terminology is considered essential for interoperability.

3. Selection

Definition

A Selection is the portion of content explicitly chosen by a user within a supported environment.

In Version 1.x of the specification, the Selection is the primary source from which a Context Object is constructed.

Motivation

A Selection represents the starting point of contextual understanding.

The protocol does not attempt to describe the entire document.

Instead, it begins with the information intentionally selected by the user.

Normative Requirements

A Selection MUST represent a single continuous user interaction.

A Selection MUST NOT contain inferred semantic information.

Semantic understanding belongs to later stages of the Pipeline.

Related Terms

4. Context

Definition

Context is the collection of information that explains the meaning of a Selection.

Context extends beyond the selected content itself.

Examples include:

Motivation

Without Context, identical selections may have completely different meanings.

The purpose of the protocol is to standardize the representation of Context.

Normative Requirements

Context MUST always be represented as structured data.

Context MUST NOT rely solely on plain text.

5. Context Object

Definition

A Context Object (CO) is the standardized representation of a Selection together with its associated Context.

It is the primary data structure defined by this specification.

Motivation

Rather than exchanging isolated text fragments, applications exchange Context Objects.

This allows contextual understanding to become portable across implementations.

Normative Requirements

Every Context Object MUST conform to the schema defined in Chapter 200.

Context Objects MUST remain implementation-independent.

6. Pipeline

Definition

A Pipeline is the ordered sequence of processing stages that transforms a Selection and its associated Document into a Context Object.

Motivation

Building contextual understanding requires multiple independent steps.

The Pipeline separates these responsibilities into predictable stages.

Normative Requirements

Pipeline stages MUST execute in the order defined by the specification.

Each stage MUST enrich the same ContextState during Pipeline execution.

Pipeline stages MUST NOT replace previously generated information unless explicitly permitted.

7. Stage

Definition

A Stage is an individual processing step within a Pipeline.

Each Stage has a clearly defined responsibility.

Examples include:

Normative Requirements

Each Stage SHOULD perform one logical responsibility.

Stages SHOULD NOT duplicate work performed by earlier stages.

8. Producer

Definition

A Producer is any implementation capable of generating a Context Object.

Examples include:

Motivation

Different environments may produce Context Objects through different implementations while remaining compatible with the same protocol.

Normative Requirements

Every Producer MUST generate a valid Context Object.

A Producer MAY implement only a subset of optional capabilities.

9. Consumer

Definition

A Consumer is any system that receives and uses a Context Object.

Examples include:

Motivation

The protocol intentionally separates Context production from Context consumption.

Normative Requirements

Consumers SHOULD rely only on the standardized Context Object.

Consumers SHOULD NOT depend on implementation-specific metadata.

10. Adapter

Definition

An Adapter is a component responsible for converting implementation-specific data into protocol-compatible input.

Examples include:

Motivation

Adapters isolate implementation differences from the core protocol.

Normative Requirements

Adapters MUST preserve the meaning of the original Selection.

Adapters MUST NOT modify protocol semantics.

11. Semantic

Definition

Semantic information describes the machine-understandable meaning of a Selection.

Examples include:

Motivation

Semantic understanding enables downstream systems to reason about content without re-analyzing raw text.

Normative Requirements

Semantic information MUST be generated independently of presentation.

Semantic information SHOULD remain deterministic whenever possible.

12. Hierarchy

Definition

Hierarchy describes the structural position of a Selection within its parent document.

Examples include:

Motivation

Hierarchy provides structural meaning beyond the selected text itself.

Normative Requirements

Hierarchy SHOULD describe logical structure rather than visual layout.

13. Recommendation

Definition

A Recommendation is a suggested downstream action derived from the current Context.

Examples include:

Motivation

Recommendations improve user experience while remaining independent from AI implementations.

Normative Requirements

Recommendations MUST remain optional.

Recommendations MUST NOT execute actions directly.

14. Metadata

Definition

Metadata describes information about how a Context Object was generated.

Typical metadata includes:

Normative Requirements

Metadata MUST describe the generation process rather than document content.

15. Extension

Definition

An Extension is an optional protocol component that augments the Context Object without modifying the core specification.

Examples include:

Motivation

Extensions allow innovation while preserving compatibility.

Normative Requirements

Extensions MUST NOT redefine existing protocol semantics.

Extensions SHOULD use namespaced identifiers.

16. Relationship Between Terms

The following conceptual relationships exist among the core terminology.

Selection
     │
     ▼
Pipeline
     │
     ▼
Context Object
     │
     ├────────► Consumer
     │
     └────────► Extension

Producer
     │
     └────────► Pipeline

Adapter
     │
     └────────► Producer

These relationships are informative and intended to assist understanding of the protocol architecture.

17. Summary

The terminology defined in this chapter establishes the shared vocabulary of the Context Object Specification.

Subsequent chapters MUST use these definitions consistently.

Implementations SHOULD adopt these terms directly in documentation, APIs, and architectural discussions whenever practical.