Public draft

This first draft explains how businesses can share trusted information, keep their identity, accept approved actions, and send updates to AI systems. It is version 0.1 because the rules may change before version 1.0.

A shared link between businesses and AI

SAII explains how a business shares facts, identity, actions, updates, and display rules without forcing it to use one database, AI company, model, or connection type.

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 control

Words used in this standard

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.

Known sources, one gateway

The business keeps its main sources separate from the public interface. The gateway checks who controls each field, applies access rules, records the source, and allows approved reads and writes. AI plans the view and builds it from approved parts.

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 public starting 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"] }
}

Clear identity and 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 by things, 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.

Useful data before finished text

Queries return organized records, not finished writing. They can choose things, filter results, follow links, sort, split results into pages, and ask for current sources.

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.

The user goal is saved as data

Intent records the user goal, limits, requested information, allowed sources, and saved context. It stays separate from business ranking rules.

{ "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 parts, checked before use

An IDI uses approved parts, trusted data, outside sources, and clear rules for changes. The builder must use listed parts and must not invent parts, 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.

AI builds the view. The business controls its 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 prove that a claim is true. It shows where the claim came from.

Every important field or statement has a source label. The view keeps company information, outside material, community notes, calculations, and AI summaries separate.

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

Businesses can suggest. Users keep the goal.

Businesses may publish ranking suggestions and rules. AI providers must not present paid or business-controlled ordering as neutral. The active rule and ranking factors must be visible.

• 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, choose, act

An action asks a business to change something. The request includes who asked, what they can do, what was approved, the data sent, the time, and the risk.

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

Updates come back to the view

Events tell approved systems when a business change is complete. Events cannot be changed. A correction is a new event that points to the old one. 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 keeps business identity, AI identity, user identity, permissions, and consent separate. Authentication proves who is calling. Authorization says what they may do. Consent records what the user agreed to share or do.

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 user owns the workspace

A workspace can compare several businesses while keeping each source, brand, data version, and sponsorship label. 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 needed to decide

SAII can record the stated goal, requested information, changes to the request, and result. 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 can keep what they have

SAII can start with a website scan, a platform connection, an upload, or 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.

Extra rules for higher-risk areas

Extra profiles add rules for areas where a wrong claim or suggestion could cause serious 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.

Stop when control is unclear

Security covers finding the service, checking identity and permission, checking requests and sources, running actions, sending updates, storing data, showing views, and keeping audit records. 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 rules and shared review

Versions use major and minor numbers. Major versions may change how the system works. Minor versions add fields or features that still work with older versions. 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 claim about what the system can do

Conformance means the system follows a stated version, profile, and class. Certification may include identity review, security tests, connection tests, accessibility checks, and renewal. A product must publish a machine-readable conformance statement. Certification must not imply that every business claim is true.

Show the full 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.

Order of rules, 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.