A text-based interface protocol for intelligent agents.
SIL (Semantic Interface Layer) is an open specification for providing AI agents with a direct, semantic interface to web applications.
A conventional web application is primarily designed for human interaction. Its interface exposes information through visual layout, navigation, controls, client-side behavior, and other presentation mechanisms. An agent can use that interface, but often has to reconstruct the application's structure and meaning from those presentation artifacts.
SIL adds another interface to the same application: a structured textual representation of its application state, available objects, relationships, navigation, capabilities, and actions.
The human interface remains. SIL does not replace it.
The goal is to give an agent the equivalent of a well-defined interface rather than requiring it to reverse-engineer one.
The two interfaces can share the same backend, business logic, data, authentication, authorization, and application state.
βββββββββββββββββββββββ
β Application β
β β
β business logic β
β data & state β
β permissions β
ββββββββββββ¬βββββββββββ
β
βββββββββββββββ΄ββββββββββββββ
β β
βΌ βΌ
Human Interface Semantic Interface
HTML SIL / STF
β β
βΌ βΌ
Humans Agents
This is not necessarily duplication of information. It is a separation of presentation according to the capabilities and requirements of the consumer.
Agents can already interact with web pages, APIs, MCP tools, and other interfaces. SIL addresses a different problem:
How can an agent understand an application itself β its structure, current state, available actions, navigation, and boundaries β without reconstructing that information from presentation-oriented artifacts?
For example, an HTML page may contain a button whose meaning is determined by its surrounding elements, styling, JavaScript handlers, application state, and visual context.
A SIL representation can state that meaning directly:
DownloadButton
Type: Button
Role: PrimaryAction
Id: btn_download
Caption: Download
Actions: Activate
The difference is not that one contains information and the other does not.
The difference is where the interpretation has to happen.
With a conventional interface, the agent may have to infer semantics from presentation. With SIL, the application can expose those semantics explicitly.
SIL defines an application vocabulary and interface protocol for intelligent agents.
As of SIL v1.1.0, the underlying syntax and semantic core are no longer defined inline. SIL is now specified as an extension of STF core β a separate, standalone specification (Semantic Text Format) published independently at github.com/ais-space/stf.
The relationship is now:
STF core (standalone specification)
βββ syntax (Β§2)
βββ semantic model (Β§3)
βββ structural security (Β§4)
βββ data / serialization model (Β§5, Β§6)
SIL v1.1.0 (this specification)
βββ SIL Vocabulary β application extension of STF core (Β§3)
βββ Application Vocabulary (Β§4)
βββ SIL Protocol β discovery & interaction (Β§5)
βββ Interaction Patterns (Β§6)
βββ Security-specific guidance (Β§7)
βββ Conformance profiles (Β§8)
βββ Extensions & Future Directions (Β§9)
STF core is referenced normatively, by reference, without version pinning: any SIL document is, by construction, a valid STF document. When STF core evolves, SIL tracks it at the application layer. STF core is intentionally textual and hierarchical, designed to remain readable by humans while being straightforward for language models to interpret.
The SIL specification is itself written in STF, making it a self-describing, conformant document rather than merely a document about the format.
A SIL-enabled application exposes semantic pages through HTTP.
A typical interaction looks like this:
Agent SIL Server
β β
β GET /revizor.sil β
βββββββββββββββββββββββββββββ>β
β β
β STF document β
β<βββββββββββββββββββββββββββββ
β β
β POST /revizor.sil β
β {"intent":"activate", β
β "target":"btn_download"} β
βββββββββββββββββββββββββββββ>β
β β
β Updated STF document β
β<βββββββββββββββββββββββββββββ
The returned document can contain:
- application context;
- site navigation;
- page structure;
- semantic objects;
- object state;
- relationships;
- available actions;
- forms and fields;
- validation information;
- permissions and interaction constraints;
- user data boundaries;
- agent-only application spaces.
The exact capabilities available depend on the SIL conformance profile implemented by the server.
Objects describe their type, role, state, and available capabilities instead of requiring the agent to infer them from presentation.
SIL is designed for direct interpretation by language models. It does not require task-specific fine-tuning or a vision model merely to understand the application's basic structure.
A SIL response represents the application's current state. It can therefore be used for interaction rather than serving merely as static documentation.
Actions are represented explicitly and submitted through the SIL protocol. The agent does not need to synthesize arbitrary JavaScript or reconstruct UI event handlers.
SIL distinguishes application-defined knowledge from user-provided data at the structural level.
This allows an implementation to establish explicit trust boundaries between information that defines application behavior and information that must be treated as data.
SIL does not claim to make an application inherently secure. Authentication, authorization, validation, transport security, business rules, and implementation-specific security remain the responsibility of the application.
A SIL interface does not have to correspond one-to-one with an HTML page.
An application can expose Agent Spaces that exist specifically for agent interaction and have no human-facing counterpart.
SIL defines conformance profiles so that an implementation can start with a limited read-only interface and add interaction capabilities progressively.
Current profiles include:
CoreCore ReadFormsEventsAgent Spaces
For example:
This implementation conforms to SIL v1.1.0: Core + Forms + Events.
SIL can be discovered through several mechanisms.
An implementation may advertise its SIL interface through HTTP Link
headers, HTML <link>
elements, the /.well-known/sil
endpoint, or other mechanisms defined by the specification.
For example:
Link: </.sil>; rel="sil"; type="text/sil"
A well-known discovery endpoint may provide information about available SIL resources:
GET /.well-known/sil
Once an agent enters a SIL interface, SiteNavigation
can provide the application's navigation structure directly within the semantic representation.
Discovery is optional and implementation-dependent: a site must explicitly provide these mechanisms for an agent to use them.
curl https://ais-platform.dev/.sil
https://ais-platform.dev/feedback.sil
This is a SIL-only application space with forms, pagination, and events.
curl https://raw.githubusercontent.com/ais-space/sil/main/SIL_Open_Specification.sil
| Technology | Primary purpose | Relationship to SIL |
|---|---|---|
| HTML | ||
| Human-facing web interface | SIL provides an additional semantic interface for agents | |
| REST APIs | ||
| Programmatic access to application resources | SIL can complement APIs by exposing application semantics and interaction | |
| MCP | ||
| Standardized access to tools and resources | SIL and MCP address different layers and can be used together | |
| OpenAPI / JSON Schema | ||
| Describe APIs and data structures | SIL describes an interactive application and its semantic state | |
| Structured data / metadata | ||
| Add machine-readable information to documents | SIL provides a complete agent-facing interface rather than isolated metadata |
SIL is therefore not intended to replace HTML, REST, OpenAPI, or MCP.
It occupies a different layer.
The canonical specification is:
SIL v1.1.0
SIL_Open_Specification.silβ canonical specification in STFSIL_Concept.mdβ conceptual backgroundgrammar/stf.ebnfβ formal STF grammarschema/intent.schema.jsonβ JSON Schema for intent requests
The specification is self-hosting: it is itself represented as a valid STF document.
The specification originated from a working implementation and was refined through iterative review with multiple AI models.
The implementation experience preceded the final specification. The specification was then separated from the implementation's architecture, technology stack, and other project-specific details.
sil/
βββ SIL_Open_Specification.sil
βββ SIL_Concept.md
βββ README.md
βββ CHANGELOG.md
βββ ROADMAP.md
βββ LICENSE
βββ LICENSE-CODE
βββ CONTRIBUTING.md
βββ SECURITY.md
βββ CODE_OF_CONDUCT.md
βββ grammar/
β βββ stf.ebnf
βββ schema/
β βββ intent.schema.json
βββ examples/
An implementation may claim conformance to one or more SIL profiles.
The fundamental SIL protocol:
- semantic document retrieval;
- STF processing;
- interaction requests;
- application-defined security boundaries.
Read-only semantic interfaces.
Form fields, input handling, and validation.
Real-time event delivery.
SIL interfaces without an HTML counterpart.
See Β§8 of the specification for the normative conformance requirements.
SIL is not:
- a replacement for HTML;
- a replacement for REST APIs;
- a replacement for MCP;
- a search-engine optimization format;
- a requirement to duplicate an application's business logic;
- a claim that language models possess a special biological or "native" language;
- a security mechanism that makes unsafe applications safe automatically.
SIL is an interface layer intended to make an application's semantics directly available to intelligent agents.
The web has historically been built primarily around human interaction.
SIL explores a simple extension:
If intelligent agents are going to use the web as users, they should have an interface designed for them too.
Humans can continue using the visual interface.
Agents can use the semantic interface.
Both can operate on the same application.
Specification:Creative Commons Attribution 4.0 International(CC-BY-4.0)** Reference code, tests, and tooling:**Apache License 2.0
Implementations do not inherit these licenses and may be released under other licenses.
Specification issues:GitHub Issues** Security:security@ais-platform.dev Website:**ais-platform.dev