Open design draft

This first public draft defines a vendor-neutral interface through which organizations publish authoritative information, preserve brand identity, accept authorized actions, and synchronize operational data with AI systems. It is numbered 0.1 because implementers should expect changes before 1.0.

The interface between organizations and intelligent software

SAII defines how an organization exposes knowledge, identity, capabilities, actions, events, and presentation rules without forcing either side into one database, AI provider, model, or transport.

Goals

• Replace ambiguous scraping with direct, permission-aware access to structured records.
• Keep data ownership with the organization and intent ownership with the user.
• Let AI assemble interfaces from approved components instead of arbitrary production markup.
• Carry provenance, claim type, freshness, and source authority with every fact.
• Support leads, appointments, quotes, orders, support, and controlled updates.
• Work across CMS, CRM, commerce, scheduling, and data systems.

Non-goals

SAII is not a truth oracle, search engine, model, CRM, or replacement for every website. It does not require a business to move all data into one vendor platform.

Trust, ownership, and user direction

Shared language

Organization

The legal or operational party publishing a SAII endpoint.

Provider

An AI platform, agent, application, or other SAII consumer.

Record

A typed entity with identifiers, fields, relationships, provenance, and version metadata.

Declared authority

The system permitted to originate and resolve a particular field.

Intent

A structured representation of a user goal, constraints, requested information, and context.

IDI

Intent-Driven Interface, an experience assembled from approved components and trusted data.

Action

A requested state change sent from an AI system to an organization.

Event

A signed statement that a state change occurred.

Provenance

Machine-readable lineage describing origin, verification, transformation, and freshness.

Workspace

User-controlled saved context that may span organizations.

Canonical sources, one gateway

A deployment separates canonical sources from the public interface. The gateway resolves authority, applies access policy, records provenance, and exposes read and write capabilities. A provider plans an experience, validates it against the component registry, and renders it in its own environment.

CMS · CRM · Commerce · Scheduling · Brand library
                         ↓
SAII Gateway: Discovery · Query · Actions · Events · Provenance · Policy
                         ↓
AI planner → Validated page specification → Intent-Driven Interface

The semantic model is transport-neutral. REST, GraphQL, MCP, gRPC, and event streams may carry the same meaning. The core profile defines HTTP and JSON for immediate interoperability.

Conformance classes

Publisher, Composer, Actor, Synchronizer, Analytics Producer, and Full Gateway. Each class declares its required capabilities.

One well-known entry point

A public origin supporting SAII must publish /.well-known/saii. The document identifies the version, organization, issuer, endpoints, authorization methods, and capabilities. Read access never implies write access.

{
  "saiiVersion": "0.1",
  "organizationId": "org_veraform",
  "endpoints": { "schema": "/saii/v1/schema", "query": "/saii/v1/query", "compose": "/saii/v1/compose" },
  "capabilities": { "read": ["organization", "product"], "actions": ["lead.create"] }
}

Stable identity, explicit control

Each organization, brand, endpoint, entity, action, and event has a stable identifier. A publisher proves control through DNS, a domain challenge, or another registered verification method. Verification proves control of an identity endpoint; it does not prove every published claim.

{ "fieldAuthority": {
  "organization.hours": { "system": "gohighlevel", "mode": "authoritative" },
  "product.inventory": { "system": "shopify", "mode": "authoritative" },
  "organization.brand": { "system": "saii-cms", "mode": "authoritative" }
} }

If two sources claim authority without a precedence rule, the gateway creates a conflict and stops automatic publication.

Information organized around entities, not pages

Each record contains an identifier, type, lifecycle state, fields, relationships, provenance, version, and timestamps. Core entities include organizations, brands, locations, people, products, services, ingredients, formulas, claims, studies, policies, reviews, availability, appointments, quotes, orders, intents, workspaces, actions, and events.

{ "id": "product_daily_foundation", "type": "product", "version": "7",
  "status": "published", "fields": { "name": "Daily Foundation", "salesRank": 1 },
  "provenance": { "class": "saii-verified", "sourceRecord": "cms:product:814" }
}

Lifecycle states are proposed, reviewed, published, superseded, archived, and withdrawn. Public queries must not return proposed or withdrawn records without an authorized scope.

Structured answers before prose

Queries return structured records, not finished prose. They support entity selection, filters, relationships, sorting, pagination, freshness requirements, and provenance requirements.

POST /saii/v1/query
{
  "select": ["product"],
  "where": { "healthGoals": { "contains": "sleep" }, "price.amount": { "lte": 40 } },
  "include": ["ingredients", "claims", "reviewSummary"],
  "provenance": { "include": true }, "limit": 12
}

Every returned field retains provenance. Calculated values include method, inputs, units, and rounding behavior. Partial responses identify omitted fields and the data version used.

Intent is a first-class object

Intent records what the user is trying to accomplish, the constraints supplied, the information requested, permitted sources, and memory scope. It remains separate from business ranking preferences.

{ "id": "intent_vitamin_c_compare", "goal": "compare three vitamin C products",
  "constraints": ["show dosage", "price per serving", "testing", "reviews"],
  "scope": "workspace", "parentIntent": null,
  "refinements": [{ "text": "tell me more about this company", "operation": "focus" }]
}

A focus request creates a child intent without destroying its parent comparison. The user can return without restating their context.

Approved components, validated state

An IDI is assembled from approved components, trusted data, external sources, and explicit transformation rules. A composer must select from a declared registry and must not invent production components, actions, or unsupported fields.

{ "page": { "title": "VeraForm best sellers", "sections": [
  { "component": "product-grid", "source": "q_best_sellers" },
  { "component": "founder-profile", "source": "q_founder" },
  { "component": "review-grid", "source": "q_verified_reviews" }
] }, "explanation": "Products are ranked by sales rank." }

Refinements should update only affected sections while preserving stable context. The composer emits diffs such as add, remove, move, replace, and update.

The AI controls composition. The organization controls identity.

A brand profile describes official names, assets, colors, typography, voice, terminology, legal language, component preferences, and prohibited transformations. Rules are required, preferred, adaptive, or prohibited.

• Required rules must be followed wherever technically and legally possible.
• Preferred rules guide capable surfaces.
• Adaptive rules may change with user need, device, accessibility, or composition.
• Prohibited rules must never be used.

Brand preferences cannot defeat accessibility or an explicit request for a simpler format. Attribution, correct naming, legal text, and safety notices remain in effect.

SAII does not certify truth. It certifies provenance.

Every substantive field or statement carries a provenance class. A renderer preserves the distinction between company information, external material, community observations, calculations, and AI synthesis.

Trust rule SAII Verified means the authenticated organization published the record. It does not mean SAII independently proved the claim.

Businesses can signal. Users keep the objective.

Businesses may publish recommendation signals and policies. Providers must not misrepresent paid, preferred, or business-controlled ordering as neutral relevance. The active policy and ranking factors must be inspectable.

• AI optimized: rank for user intent and disclosed safety rules.
• AI assisted: use business signals as inputs, with provider override for relevance.
• Business controlled: published rules determine permitted order within a branded experience.
• Compliance controlled: a regulated profile restricts recommendations and review.

The system retains the original user goal and material refinements. Commercial preference must not silently replace an explicit criterion.

Read, decide, act

Actions carry a requested state change from an AI system to an organization. The envelope includes an action identifier, idempotency key, actor, scopes, confirmation, authorized fields, payload, attribution, requested time, and risk level.

Every write action must include an idempotency key. Repeating an accepted action returns the prior result rather than creating a duplicate.

Changes travel back to the interface

Events report completed changes from an organization to authorized consumers. Events are immutable statements. Corrections are new events that reference earlier events. Publishers retry transient failures, consumers deduplicate by event ID, and subscriptions declare event types, filters, callback identity, and expiration.

Synchronization follows declared authority. Non-authoritative updates become proposals or conflicts. Implementations must not create update loops.

Permission before action

SAII separates organization identity, provider identity, user identity, authorization scopes, and consent. Authentication proves who is calling. Authorization determines what the caller may do. Consent records what the user agreed to share or execute.

Tokens are limited by organization, capability, scope, audience, and time. Public read access never implies access to personal records or operational writes. Consequential actions attach a consent receipt identifying the receiving organization, exact fields, financial effect, disclosure, confirmation time, and withdrawal method.

The workspace belongs to the user

A workspace may compare multiple organizations while preserving each source, brand, data version, and sponsorship state. A company cannot edit another company's records or the user's neutral comparison order.

• Temporary: discard context at the end of the session.
• Saved: preserve the intent chain and interface state.
• Ongoing: refresh changed prices, availability, reviews, or evidence under a disclosed policy.

Analytics and action payloads contain only fields needed for their stated purpose. Persistent personal context requires explicit user choice, with inspection, export, deletion, and revocation available.

Measure what people were trying to decide

SAII can record the goal expressed, information requested, refinements made, and outcome. Standard events include intent.started, intent.refined, information.requested, comparison.changed, action.confirmed, intent.completed, intent.abandoned, and information.gap.detected.

Analytics must not infer sensitive traits merely because it can. Health, financial, legal, employment, identity, and similar profiles require an applicable extension profile, clear purpose, and stronger controls.

Businesses do not have to start over

SAII onboarding supports website scanning, platform connectors, direct upload, and guided entry. Extracted information begins as proposed unless policy permits publication.

1. Identify and verify the organization.
2. Choose scan, connector, upload, or guided-entry sources.
3. Extract entities, relationships, brand rules, and actions.
4. Attach source evidence and confidence to every candidate field.
5. Detect duplicates, contradictions, stale records, and missing fields.
6. Select authority, autonomy, recommendation, action, privacy, and synchronization policies.
7. Preview interfaces, test actions, and publish discovery.

Operator modes are red, yellow, green, or custom. Readiness reporting must expose unresolved high-risk issues.

Extensions for higher-risk domains

Regulated profiles add constraints where incorrect claims or recommendations can cause material harm. A health profile may require exact claim wording, evidence strength, population, dosage, formulation, limitations, contraindications, interactions, review date, and disclaimers.

A regulated profile may narrow the core standard, but it cannot weaken consent, provenance, intent integrity, accessibility, or audit requirements.

Fail closed when authority is unclear

Security covers discovery, authentication, authorization, request validation, source integrity, action execution, event delivery, storage, rendering, and audit. Controls include protected transport, request limits, signature verification, replay protection, idempotency, least-privilege credentials, secret rotation, immutable audit records, and rollback where supported.

When policy, identity, consent, authority, or provenance cannot be established, implementations must fail closed for writes. A read interface may show partial information only when it labels the gap.

Open stewardship

Core versions use major and minor numbers. Major versions may make incompatible changes. Minor versions add compatible fields or capabilities. Each record and envelope declares its version.

The specification is published openly. Proposed changes use public design notes, implementation evidence, compatibility analysis, and recorded decisions. Commercial products may host, connect, certify, analyze, or manage SAII implementations without restricting independent implementations.

A technical claim with a defined scope

Conformance is tied to a version, profile, and class. Certification may add identity review, security testing, interoperability testing, accessibility checks, and renewal. A product must publish a machine-readable conformance statement. Certification must not imply that every business claim is true.

Prove the complete path

The first reference implementation consists of an organization datastore or adapter layer, SAII gateway, HTTP/JSON API, MCP binding, component registry, IDI renderer, policy engine, audit log, and connector adapter.

GET  /.well-known/saii
GET  /saii/v1/schema
GET  /saii/v1/entities/{type}/{id}
POST /saii/v1/query
POST /saii/v1/compose
POST /saii/v1/actions
GET  /saii/v1/actions/{actionId}

VeraForm, a contractor, and a shared workspace

The VeraForm demonstration publishes organization, founder, product, ingredient, formula, claim, research, testing, certification, review, pricing, policy, and inventory records. A visitor asks for best sellers, founder information, and reviews. The composer queries those records, selects approved components, labels each source, and returns a page specification.

A contractor flow reads service coverage, lead requirements, and availability before asking permission to share personal information. A cross-business vitamin C workspace preserves separate company records while allowing neutral comparison, independent research, and SAII calculations.

Precedence, status codes, and open questions

Core precedence order

1. Applicable law and safety
2. Accessibility needs
3. Explicit user request and consent
4. Verified records and declared authority
5. Required brand and legal rules
6. Business recommendation policy
7. Preferred brand presentation
8. Provider defaults

Core HTTP status guidance

Open design questions

Future drafts will resolve global identifiers, signature discovery, component registry governance, portable consent receipts, neutral ranking audits, privacy-preserving analytics, certification policy, and interoperability boundaries with existing AI tool protocols.