Skip to main content

Manifest

A document detailing what the intent is and guides Linnet to deliver the best user expereance.

Task Chat Branch API
note

These details are only updated with each release, for more acurate updates and keeping track of progress, see the task in GitHub.

Team​

OwnerLead
MendySergey

Status​

Doc StatusProduct StatusLast UpdateVersionReleasePhase
In ProgressUp Next04.03.20240.01InternalAlpha

Description​

Manifest: A Manifest is a static document (authored as YAML) that contains a list of messages, rules, components and actions for the Manifest Executor to execute. The Executor itself holds no messages — it only interprets Manifest documents, which lets new manifests be authored without backend code changes as long as they only reuse already-supported step types, components, actions and YAML fields. A Manifest that references a new target (e.g. NewPaymentCard) still requires implementing that widget in the Flutter client before the Manifest can render it.

Manifest documents are static YAML files in [manifests/] (auth_Manifest.yaml, intro_Manifest.yaml, preference_manifest.yaml), loaded once at startup by ManifestYamlLoader and cached in InMemoryManifestRegistry. Adding or editing a Manifest usually requires only a YAML change and does not require changes to the Manifest Executor code — provided the Manifest only reuses step types, target components and action keys the Flutter client already supports. Because the YAML files are bundled with the backend, the service must currently be redeployed or restarted for the changes to take effect.

Each YAML Manifest maps directly onto the following metadata fields: Manifest_name, auth_required, session_isolation → inline|new_conversation, trigger_type → intent|condition|cta, condition, intents, persistence_mode → save_and_resume|volatile, topics, topic_restriction → no|limited|yes, start → top|anywhere, steps_mode → strict|dynamic, initiation — plus a steps list. A step's type is one of:

  • text — plain message (content).
  • component — client-rendered UI component (target = component name), optionally with a key so the Manifest can be entered directly on that card.
  • action — backend action or client-interpreted navigation (action key).
  • Manifest — hands off/chains into another Manifest (target = Manifest name).

Example (manifests/preference_manifest.yaml, trimmed):

note

Add the option to allow Colibri to choose the component, all the dev needs to provide is the data they want to collect or handle.

manifest_name: preference_manifest
trigger_type: intent
intents: [preferences, settings, "set up my account", ...]
persistence_mode: save_and_resume
start: anywhere
steps_mode: dynamic
steps:
  - { type: component, key: overview,      target: AccountPreferencesCard }
  - { type: component, key: last_name,     target: PreferenceLastNameCard }
  - { type: component, key: address,       target: PreferenceAddressCard }
  - { type: component, key: date_of_birth, target: PreferenceDateOfBirthCard }
  - { type: component, key: citizenship,   target: PreferenceCitizenshipCard }
  - { type: component, key: tax_details,   target: PreferenceTaxDetailsCard }
  - { type: component, key: expires,       target: PreferenceExpiresCard }

For how these documents get selected, run and delivered to the client at runtime (engine, sessions, API surface, Flutter contract), see the Manifest Executor document.

To Do​

  • Add the option to detail component position (e.g. com:Nav, Position:bottom left)
  • allow devs to give a component decsriotion and use cane to allow Linnet to choose rather than referencing an exact component from the library.

Reminders​

Links & Resources​