Des contrats typés pour les applications et les agents

Un produit.
Plusieurs interfaces.
Les mêmes règles.

Définissez le comportement de votre produit en TypeScript. Reliez-le à votre API, à vos interfaces et aux outils de vos agents, avec des entrées, permissions et règles d’approbation explicites.

Explorer l’exemple ↗Voir comment l’intégrer ↓

Commencez par une opération dans le code que vous possédez déjà.

COMPORTEMENT / 001Explicite par conception

{ }report.publishv1.0

ENTRÉEreportIdstring

EFFETPublier le rapportwrite

APPROBATIONRequise avant l’exécution↳

RÉSULTATTrace de publicationtyped

↗Votre APIAdaptateur REST

▤Votre interfaceInterface reliée

⌘Votre agentOutil MCP

[ intention partagée ]Vos gestionnaires réalisent toujours le travail.

ESSAYER UNE RÈGLE COMMUNE

Changez la règle.
Voyez chaque interface s’y conformer.

Une demande d’équipement, trois points d’entrée. Ajustez la politique et voyez l’application, l’API et l’agent aboutir à la même décision.

Illustration interactive · Données d’exemple · Exécution locale

Autorisé par cette politique de démonstration

The local request satisfies the supplied policy.

APP

Demande d’équipement

Installation du studio · Espace d’exemple

€2,400.00

DemandeurAucune validation requise

Essayez l’action et examinez le résultat.

APIJSON

{
  "operation": "request.submit",
  "allowed": true,
  "reviewRequired": false,
  "reviewRecorded": false,
  "role": "requester",
  "amount": 2400,
  "threshold": 5000,
  "reason": "permitted"
}

Structure de réponse illustrative

AGENT

La prochaine étape autorisée.

Lire la même demande et le même acteur.
Vérifiez le seuil de vérification €5,000.00 et le rôle requester.
Proposer l’envoi de la demande.

Suivre la limite de l’outil ↗

Examiner la définition partagée de la démonstration

{
  "kind": "educational-fixture",
  "operation": "request.submit",
  "reviewFrom": 5000,
  "submitRoles": [
    "requester",
    "reviewer"
  ],
  "approvalIsIndependent": true,
  "interfaces": [
    "app",
    "api",
    "agent"
  ]
}

This is an educational JSON fixture, evaluated by this page. It is not an importable ContractSpec definition.

01 Comportement explicite02 Interfaces connectées03 Effets vérifiablesComprendre les limites ↗

01 / LE PROBLÈMEUNE OPÉRATION, PLUSIEURS POINTS D’ENTRÉE

Chaque nouvelle interface
doit rester cohérente
avec votre produit.

Une personne clique sur un bouton. Une intégration appelle une API. Un agent invoque un outil.

Lorsque ces parcours implémentent séparément la même opération, un changement de permission ou une nouvelle exigence d’entrée peut échouer à plusieurs endroits.

ContractSpec donne à ce comportement une définition explicite, puis y relie les adaptateurs pris en charge et vos implémentations.

QU’EST-CE QU’UN CONTRAT ?

Une description typée de ce qu’une opération accepte, de ce qu’elle renvoie et des règles qu’elle doit respecter. Votre gestionnaire implémente le travail. Le moteur configuré contrôle la limite d’exécution.

Définir le comportement.

Les entrées, sorties, politiques, effets et responsabilités figurent dans un contrat que l’on peut examiner.

Relier les interfaces.

Reliez votre gestionnaire et exposez l’opération via les adaptateurs dont votre application a besoin.

Examiner ce qui se passe.

Rendez visibles les appels réussis, les refus et les preuves requises à la frontière d’exécution.

Changez le point d’entrée. Gardez le sens.Trace the mechanism · 3 ways to look closer

Follow a request to export a report through three interfaces. The useful common ground is the registered operation and its boundary.

Where does this request begin?

UNE SITUATION CONCRÈTE

A form helps someone make a valid request.

A person selects a report and gives a reason for the export.

01 / Form

Collect the report and reason, and explain errors in the person’s language.

Ce qui change

Labels, validation messages and the way the result is presented.

Ce qui reste explicite

The report, required reason, business implementation and configured execution checks.

SUIVRE LA CONSÉQUENCE

The form can make a requirement clear. The server still needs to reject a request that bypasses the form.

CONTINUE WITH THE DETAIL

Expose one operation through API and MCP Contracts, handlers and adapters

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

Expose one operation through API and MCP Contracts, handlers and adapters

Choose a situation to inspect its explanation.

A person

A CONCRETE SITUATION

A form helps someone make a valid request.

A person selects a report and gives a reason for the export.

Form — Collect the report and reason, and explain errors in the person’s language.
REST binding — Translate the request and construct trusted caller context in the host.
Registered operation — Prepare the call, apply configured checks and invoke the bound handler only when permitted.

What changes

Labels, validation messages and the way the result is presented.

What stays explicit

The report, required reason, business implementation and configured execution checks.

FOLLOW THE CONSEQUENCE

The form can make a requirement clear. The server still needs to reject a request that bypasses the form.

An API client

A CONCRETE SITUATION

A structured request reaches the same business boundary.

A script sends the report identifier and required reason through the API.

HTTP request — Supply the declared input in the adapter’s expected transport shape.
Context factory — Resolve the subject from the host’s authentication boundary.
Handler result — Inspect the canonical result and the adapter’s actual response mapping.

What changes

HTTP payload, status mapping and the client’s error handling.

What stays explicit

The meaning of the operation and the host’s responsibility for identity, policy and dependencies.

FOLLOW THE CONSEQUENCE

Compare the meaningful result and actual effect with the form path. A matching endpoint name does not establish matching behavior.

An agent

A CONCRETE SITUATION

A tool call supplies input; it does not supply authority.

An agent prepares the export tool arguments from the task context.

Tool shape — Expose the operation through the MCP registration supported by the chosen source version.
Tool context — Construct trusted context and adapt request-specific approval evidence.
Shared invocation — Call the registry path; preserve its meaningful failure information in the tool result.

What changes

Tool discovery, input schema and the structured tool result.

What stays explicit

The registered operation, handler and configured approval boundary.

FOLLOW THE CONSEQUENCE

A tool argument saying “administrator” remains input. Trusted identity comes from the host; an agent must understand a denied or approval-required result.

02 / RENDRE LES CHOSES CONCRÈTESEXPLORER LE COMPORTEMENT

L’approbation se contrôle
à l’exécution.

Une même opération est accessible de plusieurs façons.
L’exigence d’approbation doit toujours s’appliquer.

Interactive illustration · local fixture, not a live runtime trace.

LA RÈGLE DÉCLARÉEExtrait TypeScript

// Part of an operation definition
execution: {
  effects: ['write'],
  approval: {
    required: true
  }
}

↳

An approval requirement is explicit metadata. Enforcement also needs a configured runtime and approval port.

Preuve d’approbation

HTTP REQUEST · ILLUSTRATIVE

POST /reports/demo-report/publish
Content-Type: application/json

{ "reportId": "demo-report" }

↳

PRÊT À ESSAYER

Que se passe-t-il sans approbation ?

Tentez l’opération, puis ajoutez une preuve d’exemple valide et réessayez.

Appels du gestionnaire lors de cet essai —Awaiting attempt

The illustration explains the proposed experience. The inspected REST test asserts denial before handler invocation; this page does not execute ContractSpec packages.

Examiner la base source ↗

03 / GRANDIR À PARTIR DE CETTE FONDATIONADOPTER CE DONT VOUS AVEZ BESOIN

Un point de départ limité.
Un système composable.

Réutilisez les comportements du produit en faisant évoluer l’expérience. Ajoutez des interfaces adaptées, des capacités réutilisables et des contrôles de changement à mesure que le produit grandit.

A / NOYAU

Modéliser le comportement.

Describe operations, data and events with typed contracts. Bind implementations through a runtime built around explicit boundaries.

Contracts + Runtime

B / CHANGEMENT

Rendre les décisions vérifiables.

Connect supports scoped decisions and receipts, with durable verification supplied by a configured host. Your host performs the actual merge, deployment or effect.

Relier

C / EXPÉRIENCE

Adapter l’expérience.

RoleMorph and presentation contracts support different interfaces for different roles, with authorization kept explicit.

RoleMorph + Surfaces

D / COMPOSITION

Composer des capacités.

Feature Hubs declare their needs and provide reusable functionality. Installation, readiness and starting effects remain distinct steps.

Feature Hubs

One workflow. Two useful views.

Presentation illustration

EDITOR / PREPARE

Quarterly report

Content, supporting sources and the next review step.

Brouillon prêtVérification nécessaire →

REVIEWER / ASSESS

Publication review

Changed content, requested effect and approval evidence.

Evidence attachedReview publication →

Shared operation report.publishPresentation changes. Backend authority stays explicit.

Construit chez LSSM. CompanyOS is an application built on this shared foundation, bringing contracts, operations and interfaces into a business workflow.

A reusable piece comes with a set of relationships.Trace the mechanism · 3 ways to look closer

A communication capability might need an operation, a provider port and a policy binding. Explore what happens when one piece is missing.

What is ready in the composition?

UNE SITUATION CONCRÈTE

You can inspect the promise before enabling an effect.

The capability is described, but no active installation or provider has been selected.

01 / Declare

Name the operations, capabilities and required ports.

Ce qui change

The product can discover the capability and its requirements.

Ce qui reste explicite

A declaration alone does not send a message or initialize a provider.

SUIVRE LA CONSÉQUENCE

Use the dependency map to choose what to bind. Do not treat catalogue presence as runtime readiness.

CONTINUE WITH THE DETAIL

Compose features with explicit dependencies Bind external services deliberately

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

Compose features with explicit dependencies Bind external services deliberately

Choose a situation to inspect its explanation.

Only the declaration

A CONCRETE SITUATION

You can inspect the promise before enabling an effect.

The capability is described, but no active installation or provider has been selected.

Declare — Name the operations, capabilities and required ports.
Inspect — Identify which requirements your product actually uses.
Prepare — Choose the host configuration and a bounded installation to evaluate.

What changes

The product can discover the capability and its requirements.

What stays explicit

A declaration alone does not send a message or initialize a provider.

FOLLOW THE CONSEQUENCE

Use the dependency map to choose what to bind. Do not treat catalogue presence as runtime readiness.

A fixture is bound

A CONCRETE SITUATION

The product behavior becomes testable without external effects.

The selected composition uses a deterministic fixture port.

Install — Activate the selected capability in the test host.
Check — Verify operation, port, actor capability and policy requirements.
Observe — Record the fixture callback and denial paths within this environment.

What changes

You can exercise the declared effect gate and inspect the fixture result.

What stays explicit

The fixture does not establish provider delivery, remote quotas or live retry semantics.

FOLLOW THE CONSEQUENCE

Keep the fixture label attached to the result. Qualify the provider separately when an external effect becomes part of the intended use.

A provider is chosen

A CONCRETE SITUATION

The boundary now includes an operating dependency.

A concrete provider supplies the required port for an intended environment.

Bind — Supply the provider behind the host-owned port.
Fulfill — Satisfy policy obligations before the effect callback runs.
Qualify — Exercise the supported provider path and record its actual scope.

What changes

Credentials, provider behavior, failure modes and operational ownership matter.

What stays explicit

The composition must still satisfy its declared requirements and policy obligations.

FOLLOW THE CONSEQUENCE

Check the behavior the application depends on, including unavailable service, duplicate requests and recovery. Matching a method signature is only a starting point.

04 / VOTRE PREMIER RÉSULTAT UTILEDANS VOTRE CODE EXISTANT

Apportez une opération.
Gardez votre application.

Commencez là où plusieurs interfaces doivent déjà s’accorder.

Choisissez une action délimitée, avec des entrées claires, un gestionnaire et un échec à détecter. Ajoutez un contrat, reliez deux points d’entrée et testez directement cet échec.

01
Choisir la limite
Une opération réelle avec une règle répétée.
02
Relier l’implémentation
Votre logique métier existante reste la vôtre.
03
Démontrer la règle
Vérifiez une réussite et un parcours refusé.

Explorer la documentation ↗Vérifier la disponibilité ↓Vérifiez les versions de packages prises en charge avant de commencer.

Choose an evaluation that can teach you something.Explore a situation · 3 ways to look closer

Keep the existing application. Make one operation explicit, then decide what the next useful proof would be.

Which situation sounds closest?

UNE SITUATION CONCRÈTE

Start with behavior you can compare.

An existing account lookup already returns a useful result to an API consumer.

Ce qui change

The operation gains an explicit input, result, errors and ownership boundary.

Ce qui reste explicite

Its business implementation can remain in place.

SUIVRE LA CONSÉQUENCE

Compare the current route with the new binding using the same valid and invalid cases. Widen the scope only after the difference is understood.

CONTINUE WITH THE DETAIL

Follow the first operation Adopt ContractSpec in an existing codebase Test the promise at the boundary

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

Adopt ContractSpec in an existing codebase Test the promise at the boundary

Choose a situation to inspect its explanation.

The API already works

A CONCRETE SITUATION

Start with behavior you can compare.

An existing account lookup already returns a useful result to an API consumer.

What changes

The operation gains an explicit input, result, errors and ownership boundary.

What stays explicit

Its business implementation can remain in place.

FOLLOW THE CONSEQUENCE

Compare the current route with the new binding using the same valid and invalid cases. Widen the scope only after the difference is understood.

An agent needs access

A CONCRETE SITUATION

A second entry point makes consistency observable.

An operation already used by the application needs a tool interface.

What changes

Tool discovery and transport handling are added around the registered behavior.

What stays explicit

The host still supplies identity, validation, policy and provider dependencies.

FOLLOW THE CONSEQUENCE

Exercise the actual API and MCP bindings. Compare meaningful error codes and effect counts rather than expecting identical wire payloads.

A rule is duplicated

A CONCRETE SITUATION

Make the invariant the center of the evaluation.

A required reason or approval rule is repeated across several interfaces.

What changes

The shared declaration makes the intended obligation visible to each consumer.

What stays explicit

Business logic and trusted runtime enforcement must still be implemented and tested.

FOLLOW THE CONSEQUENCE

Choose one denied request that would expose a bypass. Show that it cannot enter the handler through either selected entry point.

05 / SAVOIR CE QUE VOUS ADOPTEZDES LIMITES EXPLICITES AUSSI

Comprenez la promesse.
Examinez les limites.

Que dois-je encore implémenter ?+

Your business logic, host authentication, infrastructure and provider integrations. Contracts describe behavior; adapters and configured runtime ports connect that description to execution.

Déclarer une politique suffit-il à la faire appliquer ?+

Enforcement requires the appropriate runtime path and configuration. In the inspected operation model, approval is explicitly enabled through execution metadata. Descriptive tags alone do not protect an operation.

ContractSpec régénère-t-il et déploie-t-il tout ?+

No. Supported artifact generation exists. The inspected integration CLI still restricts generation apply to a dry run. Review, merge, deployment and real effects remain separate responsibilities.

Ai-je besoin de CompanyOS ou de Studio ?+

The developer foundation has its own adoption path. Packaged applications are separate products built on top; they are not a prerequisite for using the foundation.

Find the point where the handler can begin.Trace the mechanism · 3 ways to look closer

Take an operation that explicitly requires approval. Change one condition and inspect the expected path from the captured runtime guide.

Which request are you inspecting?

UNE SITUATION CONCRÈTE

Input preparation stops the path early.

The request omits an input required by the operation schema.

01 / ENTRÉE

Parse and validate the request against the declared schema.

Ce qui change

The request cannot become a valid prepared input.

Ce qui reste explicite

No visible button or descriptive tag makes the missing value valid.

SUIVRE LA CONSÉQUENCE

A denial test for approval should use otherwise valid input, so it actually reaches the approval boundary.

CONTINUE WITH THE DETAIL

What the runtime checks Authentication, policy and scoped approval Test the promise at the boundary

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

What the runtime checks Authentication, policy and scoped approval Test the promise at the boundary

Choose a situation to inspect its explanation.

Required input is missing

A CONCRETE SITUATION

Input preparation stops the path early.

The request omits an input required by the operation schema.

Input — Parse and validate the request against the declared schema.
Stop — The malformed request fails before the intended handler entry.
Recover — Explain the missing input; then retry through the same trusted boundary.

What changes

The request cannot become a valid prepared input.

What stays explicit

No visible button or descriptive tag makes the missing value valid.

FOLLOW THE CONSEQUENCE

A denial test for approval should use otherwise valid input, so it actually reaches the approval boundary.

Approval evidence is absent

A CONCRETE SITUATION

An explicit approval requirement blocks handler entry.

The input is valid, the fixture subject is known, and the receipt is omitted.

Prepare — Use valid input and a trusted fixture identity.
Require — Apply the operation’s explicit execution.approval requirement.
Observe denial — Inspect the adapter’s failure and verify the disposable effect remains untouched in your test.

What changes

The shared preparation path reports APPROVAL_REQUIRED with missing_receipt at the inspected snapshot.

What stays explicit

The handler should not have produced an effect.

FOLLOW THE CONSEQUENCE

Use a disposable counter or fake outbox through the real adapter to observe the denied path. This illustration is not that test run.

The returned result is invalid

A CONCRETE SITUATION

A late check cannot promise to undo an earlier effect.

The handler returns a value that fails output validation.

Invoke — The handler carries out the bound business work.
Validate output — Check the returned value against the declared result shape.
Recover deliberately — Use the application’s persistence and retry design; output rejection is not automatic rollback.

What changes

The final operation result reports the invalid output.

What stays explicit

A database change or provider request may already have occurred inside the handler.

FOLLOW THE CONSEQUENCE

If the effect and its record must be atomic, the host needs an appropriate transaction, outbox or recovery design.

06 / SOURCES ET DISPONIBILITÉOBSERVÉ LE 27 OCTOBRE 2026

L’exemple s’appuie
sur des sources.

The concept is grounded in inspected repository code. It is a design review, not a fresh runtime verification or a claim of production qualification.

Approval fixture at inspected release ↗

The repository link currently requires access.

La disponibilité compte.

Observé

Several packages have public npm metadata. That metadata and the current source tree describe different dependency layouts.

À vérifier

A clean, anonymous installation of the exact starter and versions advertised on the new site.

Ce concept

A local illustration of an approval boundary. No provider calls, backend execution or production data.

VOIR L’IDÉE PRENDRE FORME

De l’intention à une expérience
que vous pouvez vous approprier.

Une courte présentation illustrée du sens partagé, de la création assistée par l’IA et de l’exécution réutilisable.

Puis essayez vous-même ↗

Lire la présentation

Intention. Partez d’un objectif. ContractSpec donne aux éléments un sens, des données, un comportement et des règles communs.

Créer et exécuter. L’IA peut aider à générer du code source ou à composer les interfaces prises en charge. Des composants réutilisables et des moteurs d’exécution classiques exécutent le travail défini.

Adapter. Un même travail peut se présenter différemment sur ordinateur, sur mobile ou pour un agent, dans les limites d’action applicables.

Composer. Réunissez les capacités des domaines autour du résultat : communication, facturation, croissance, création et bien plus.

Télécharger la transcription complète ↓

COMMENCER PAR UNE RÈGLE QUI COMPTE

Donnez à votre prochaine interface
une règle explicite à suivre.

Explorer l’exemple ↗Discuter de votre opération ↗

Un produit.Plusieurs interfaces.Les mêmes règles.

Définissez la demande.

Définissez la politique.

Demande d’équipement

La prochaine étape autorisée.

Chaque nouvelle interfacedoit rester cohérenteavec votre produit.

Définir le comportement.

Relier les interfaces.

Examiner ce qui se passe.

A form helps someone make a valid request.

L’approbation se contrôleà l’exécution.

Que se passe-t-il sans approbation ?

Un point de départ limité.Un système composable.

Modéliser le comportement.

Rendre les décisions vérifiables.

Adapter l’expérience.

Composer des capacités.

One workflow. Two useful views.

Quarterly report

Publication review

You can inspect the promise before enabling an effect.

Apportez une opération.Gardez votre application.

Start with behavior you can compare.

Comprenez la promesse.Examinez les limites.

Input preparation stops the path early.

L’exemple s’appuiesur des sources.

La disponibilité compte.

De l’intention à une expérienceque vous pouvez vous approprier.

Donnez à votre prochaine interfaceune règle explicite à suivre.

Un produit.
Plusieurs interfaces.
Les mêmes règles.

Chaque nouvelle interface
doit rester cohérente
avec votre produit.

L’approbation se contrôle
à l’exécution.

Un point de départ limité.
Un système composable.

Apportez une opération.
Gardez votre application.

Comprenez la promesse.
Examinez les limites.

L’exemple s’appuie
sur des sources.

De l’intention à une expérience
que vous pouvez vous approprier.

Donnez à votre prochaine interface
une règle explicite à suivre.