Change the AI without rebuilding the organization's context.
Portable AI context keeps authoritative organizational information in open, predictable structures outside any individual AI product. When a team changes tools, the new system can retrieve the same applicable sources instead of requiring the organization to recreate its brand rules, definitions, data architecture, and company context from scratch.
1. Organizational context should outlive the tool
Tools are temporary; the organization is not. Brand rules, definitions, and data architecture should survive the replacement of any single model, application, or vendor.
2. Separate durable standards from temporary prompts
Durable truth—what a term means, which claims are approved—belongs in published standards. Prompts and settings are disposable configuration. Mixing the two is what makes tool changes expensive.
3. Publish through open formats and stable locations
Context published in open formats at stable, canonical locations can be read by anything that implements the standard. Portability comes from openness and stability, not from any specific vendor integration.
4. Scope retrieval to the task
A consumer retrieves only the fields relevant to its job. Scoped retrieval keeps portability practical: a new tool asks for what it needs and gets a predictable answer.
5. Support people, agents, applications, and vendors
The same sources serve human readers, autonomous agents, applications, and outside vendors. Portability is not limited to software; a new agency can read the current brand rules as easily as an internal tool.
6. Replace a consumer without replacing the source
When a tool is swapped, the canonical source stays put. The new consumer points at the same location and retrieves the same context, so the switch does not restart the organization's documentation effort.
7. Avoid proprietary schema lock-in
If the structure belonged to a vendor, moving tools would still mean re-encoding everything. An open common structure means the context is not hostage to the product that happens to read it.
8. Maintain compatibility through versions
Versioning lets sources evolve without breaking consumers. A tool can target a known version and migrate deliberately, rather than being surprised by a silent change in structure.
9. What a consuming system must implement
A consumer must be able to discover the published sources, retrieve the relevant fields for the current version, and apply them. That minimal contract is what makes any compliant tool interchangeable.
Proprietary tool context vs portable SchemaFirst context
| Proprietary tool context | Portable SchemaFirst context |
|---|---|
| Stored inside one product | Published by the organization |
| Recreated for each tool | Reused across compatible tools |
| Uses vendor-specific structure | Uses an open common structure |
| Changes may remain isolated | Changes originate from a canonical source |
| Difficult to validate across tools | Outputs can reference a shared standard and version |
What this does not guarantee
- Portability does not force any vendor to implement the standard.
- A new tool must still implement discovery and retrieval to benefit.
- Open structure does not, by itself, migrate settings or prompts specific to the old tool.
Governing standards
See How Systems Consume SchemaFirst
See How Systems Consume SchemaFirstLast reviewed · Maintained by the SchemaFirst Standards Working Group