Processes — Your Living SOPs

Every recording in Scout produces an SOP and diagram for that one interview — a faithful snapshot of what was recorded. Processes sit on top of that (browse them in the Library, stacked-files icon in the sidebar): each one is the single, official, maintained version of a process your organization actually uses, kept up to date over time and independent of any one recording.

Sessions vs Processes — the mental model

A session is one recording/interview; a Process is the living, deduplicated document. Usually one session makes one process, but the relationship flexes both ways:

• Many sessions → one process. Recording more of a process you already have doesn't create a duplicate — the interview is filed against the same process: as evidence when it confirms what is documented, as a new version when it corrects it, or as a variant when your region or team runs it differently (see How processes are created and updated). Use the "Part of an existing process" picker in the New Session dialog (type to search by name), or confirm the "looks like an existing process" suggestion after an interview finishes.
• One recording → several processes. If one recording walks through several different processes, turn on "This recording covers multiple processes". After analysis you confirm the split, and each process you keep becomes its own separate process with its own SOP and diagram.

What chat reads

Every session still produces its own SOP and diagram — the faithful record of that one interview, read (never edited) from the session page in Scout and from the process's Interviews tab — but the Library and Chat work from the process, and the process is what gets edited. Only a process's published SOP is searchable in chat, and it becomes searchable the moment it is published (a first version, a confirmed update, a version you publish from the Versions timeline). Chat follows the published version: if a process is left with nothing published — its only published version came from an interview or document you removed — or the process is deleted, chat stops quoting it. An interview's own SOP is not filed as a separate document and is not quoted by chat: it has either become the process's document, confirmed it, or is waiting for you to decide what it is. So a draft version added by an automatic match, or an interview whose "looks like an existing process" suggestion you have not answered yet, is not in chat's knowledge until it is published or filed.

The Library (folder icon in the sidebar) is where your processes and documents live, filed in your organization's folders and managed in one place. Older links to the Processes page and to Collections open here; a link to a collection opens the folder it was filed in.

The folder panel sits on the right, with the open folder's ancestors expanded and the open folder highlighted; each folder lists the processes filed in it, so a process can be opened from the panel too. Drag the panel's left edge to make it wider or narrower — the width is remembered. The panel collapses from the toggle beside Add and remembers that choice too.

Folders belong to your organization, but with an initiative selected the panel (and the Folders group of the table) shows only the folders that have something to do with that initiative: a folder that holds one of its processes — or an organization-level process, which every initiative lists — a folder tagged with one of its departments (with that folder's subfolders), or a folder holding its documents or organization-wide documents. The heading reads Folders · this initiative when the tree has been narrowed. A folder you open from a link stays visible even when it holds nothing of the initiative. Choose All initiatives to see every folder; nothing is moved or hidden anywhere else. The main area shows a breadcrumb (each step clickable; Library steps back to the top), the folder's name with a one-line count (3 folders · 12 processes · 8 documents), and one table of what the open folder holds, in three groups: Folders inside it, Processes filed in it or in any folder beneath it (so a service line shows its whole branch), and Reference documents — the files and written documents filed in the folder that are not about any one process: a policy, a template, a guide, an emailed decision. The top of the Library is a place like any other: it lists the top-level folders and only the processes and documents filed in no folder yet (the documents group is simply Documents there), not everything in the organization — open a folder for its processes, or use sidebar Search to find any process by name.

A process holds its own documents. The file a process was read from, the files you added alongside it, and the written documents filed on it belong to that process, not to the folder: they are listed on the process page's Documents tab (see The process page), and the process's row in the Library counts them on its detail line (2 sources · 4 supporting documents). They do not appear again in the folder's Reference documents, and neither a process's generated SOP nor the as-recorded SOP of any interview behind it is listed as a separate file — open the process to read its SOP; an interview's own SOP is on its session in Scout and on the process's Interviews tab.

Every row has the same columns: Name (with a detail line — a process's description and how many documents it holds, a file's processing state, who recorded a written document), Kind (Folder, PDF · 1.2 MB, Written document, …; for a process, its department), Access (who can see a document — Organization, Initiative, Only you — or a process's state: Published · v3, Draft, Needs deliverable), Modified, and a ⋯ menu at the end. Click a folder to open it here, a process to open its page, a file to open it in its viewer, a written document to read it in place.

There are no collections to manage any more. Files uploaded into a folder simply belong to that folder; a file that was uploaded into a nested collection before carries an In … note on its detail line saying where, and is listed with the rest of its folder's documents.

The ⋯ menu on each row offers what you may do to that row, and nothing you may not:

• Folder — Open, Pin to Home (or Remove from Home). A pinned folder shows up on Initiative Home as a quick link on the Processes card, for you only — up to eight. The pin beside an open folder's name does the same thing. For admins, Rename or retag, New subfolder, Delete folder (subfolders and anything filed move up one level).
• Process — Open, Add files… (the same dialog as the process page's Add files, see Adding files to a process), Record with Scout (opens Scout's New Session dialog already tagged as part of this process), Move to folder; and, when you created the process or administer its Initiative or the organization, Rename (the same rename as the process page's — the new name is written into the process's documents too, see Renaming a process below), Make a variant of… (or Move to the variants of… when it already is one), Remove from variants, Merge into another process… and Delete — see Reorganizing the library below.
• File — Open, Download, Rename, Who can see, Move to folder (into that folder's reference documents, or to the top of the Library), Delete.
• Written document — Open; Move to folder and Delete when you added it or administer the Initiative.

Rename, move and delete follow the same rules as everywhere else: the person who added an item or an admin may change it, a read-only member of an Initiative may change nothing on its items, and a generated file is never deleted here (regenerate it from its process). Who can see is the owner's call — only the person who added a file can change it — and offers Organization (everyone in your organization), Initiative (its members, including invited partners), Only you.

Hover a row to reveal its checkbox; select several and a bar appears at the bottom with Move, Who can see, Delete and — for two or more processes you may reorganize — Group as variants; each shown only when every selected row allows it (so a mixed selection of processes and files offers Move alone), plus a count and a clear button. Move to folder puts processes where you choose (a process takes the folder's department; a department someone set by hand is kept), and files and written documents into that folder's documents — or, for documents, to the top of the Library (Library (no folder) in the picker).

Deleting a source reverts what was read from it. A file you imported as a Process (or added to a process as its next version) is the source of that process's steps and versions; it is listed under Sources on the process page. Deleting it removes those versions and steps: the process goes back to the version it had before the import (or to Needs deliverable when nothing predates it), a later version that had merged the file's text is rebuilt from what remains, and a process that existed only because of the file is removed with it. The confirmation says those versions and steps will be reverted, including on any other process that was read from the same file. Chat and analysis stop reading a deleted document at once. Deleting cannot be undone.

The box in the header beside Add filters the folder you have open (press / to jump to it). It narrows the table — processes by name, description or department; folders and files by name; written documents by title, text or who added them — and, while a folder name matches, narrows the folder panel to those folders with their parents so each match reads in place; picking one opens it and clears the filter. It stays on this page. Sidebar Search (⌘K, Ctrl+K on Windows) is the other control: it jumps to a named initiative, process, person, folder, interview, chat, or page from anywhere, and it does not filter this table. A row of chips under the header narrows the processes by status (Published, Needs deliverable, Draft awaiting review) and department; only values present in the open folder are offered, one per group, click again to clear. The open folder, the filter, those chips, and which variant groups are expanded stay in the address, so Back from a process returns to that same view.

On an Initiative that belongs to another organization, the Library shows what that organization has shared with you; its folders, uploads and written documents are managed there, and the page says so.

Variants

A process that runs differently by region, entity, system or team is one process with variants, and the Library shows it that way. Two or more variants of one process are gathered under a single row in the Processes group — the shared name, a branch icon, 3 variants · 2 published — which expands to the variants beneath it, each named by what varies (New Request · Brazil) with an Applies when: line when it is known. The variants hang under that row on a purple line, the same way the parts of a multi-process recording hang under it in Scout, so the next process in the list is clearly not one of them. The group's name opens the variant group's page — a page shaped like a process page, with the variants down its right side — and the row ends in Compare, which opens the same page on its Steps tab, the step-by-step grid of how the variants differ. Both open straight from the Library, no analysis needs to have run, and Back returns to the Library view you opened them from. See The variant group page below.

Variants come from three places and all land here: an import that read one file into several variants or grouped several files as variants (see Import existing process), a Scout interview recorded as a variant of an existing process, and Architect, which looks for variants across the initiative when an analysis finishes. When Architect proposes a group it has not been confirmed yet, so the Library shows it as Possible variants · <name> with Architect's reasoning on the row and two buttons: Confirm makes it a variant group like any other; Not variants leaves the processes as they are and Architect will not propose that pair again. Anyone who can open the Library can answer; until someone does, the processes are still listed and open as usual.

Variants live in one folder. Variants of one process are filed together, so the Library's list, its folder panel, the sidebar tree and the process page all show the same set and the same count. Grouping processes files them together: Make a variant of… and Move to the variants of… move the process into the folder the group is in (the dialog says so); Group as variants files the group in the folder most of its processes are already in; confirming a group Architect proposed files its members together the same way; and a Scout interview or an import filed as a variant goes where its sibling is. Moving a variant moves its family: Move to folder on a variant (or on a selection that includes one) and Move on a variant's page take the other variants along — the dialog says how many, and the confirmation counts them ("Moved 1, and 4 variants with them"). Giving an unfiled variant a department (here or in Architect) files it where its family already is; when the whole family is unfiled, the department's folder takes them together. A group row's count is the whole family's, and whenever fewer variants are listed under it the row says why: 3 elsewhere in the Library when some are filed in another folder, 2 hidden by the filter when a status chip or the search hides them. A family grouped before this rule took effect can still be spread over folders: the folder panel then shows the part filed in each folder as 2/5 with the rest named on hover (a sibling the panel's search hides is named separately, as "hidden by the filter", not as filed elsewhere), and a variant alone in a folder carries a Variant of … detail, so the tie is never lost; moving any member, or grouping them again, gathers them — the variants you could move yourself; one you cannot see or edit stays where it is. Archived processes — ones Architect no longer surfaces and that were never published, which the Library hides — are not counted as variants anywhere, and a group left with a single process is not shown as a group. In Architect's Variants lens a group counts the variants on the map; when the family has more in the Library (a variant not analysed yet, or outside the run or source filter shown) the group says so: "8 of this family's 10 variants are on this map". See Variants in the library below for how a variant's own page reads.

How a group is named. A group Architect detected is named by Architect. A group you make yourself — Group as variants, Make a variant of…, a version split out as a variant, an interview or an import filed as a variant — starts out named after one of its processes and is renamed a moment later, after all of them: Linc reads the variants' names (and what each applies to) and names the process they are all versions of, so "Accounts Payable · Brazil" and "Accounts Payable · Global" gather under Accounts Payable. Refresh the Library to see the new name. A name you typed when grouping is kept as is, and joining an existing group never renames it.

Adding to the Library

One Add button offers Upload or paste and, for admins, New folder (it goes in the folder you have open, or at the top level; the menu says which). The dialog (Add to <folder>, or Add to the Library at the top) opens on a drop zone; drop files or click Paste text instead. Each picked item gets a row with a Process / Document switch that says what it will become:

• Process — the file is read into a process: the documented flow that Scout interviews are matched against, that Architect analyses, and that has its own process page. This is the import described under Import existing process below. SOPs, diagrams, spreadsheets, transcripts and walkthrough notes open as processes.
• Document — kept as a reference document in the folder, beside its processes: a policy, a template, a guide, an emailed answer, a decision. Reference documents are listed under Reference documents and searchable in chat, and Architect reads the ones that describe a procedure as supporting evidence (see Architect). A document never becomes a process of its own — no process page, no versions, and the interviewer does not match against it. A file the import cannot read (a .markdown, say) opens as a document; a short paste (a few sentences) opens as a document too. When any item is a document, a Who can see the documents picker appears, bounded by the folder's own visibility.

An option an item cannot take is disabled and says why — a .bpmn or a transcript cannot be a document. Files can be kept as documents at the top of the Library as well as in a folder; they sit in the Documents group there until you move them into a folder. Pasted text kept as a document becomes a written document (below) filed in the open folder, or at the top when none is open; it takes an optional title, which becomes its name. The button reads what the batch will do (Import 2 processes · keep 1 document), documents are kept first, and the results screen lists them above the imported processes.

When it is about a process that is already in the library, say so in the same dialog and the item goes to that process instead of the folder:

• Under Process, the question Is this process already in the library? lets you pick the process and how the file relates to it: Update it reads the file as that process's next version (published if nothing is published yet, otherwise a draft for you to review), or New variant of it reads the file into its own process shown with the one you picked as variants, filed where it is filed. Several files can only be new variants — a process takes one new version per import. The button reads Update the process or Import 2 variants.
• Under Document, Is the document about one process? lets you pick the process; the file is then kept as a supporting document of that process (the button reads Add 1 supporting document) and is listed on its Documents tab, not in the folder's reference documents. Supporting documents follow the limits of a process's Add files (30 MB each, 5 MB for images), and a short paste becomes a written document on that process.

The same choices are available from the process itself — Add files on its page, or Add files… on its Library row — which is the quicker route for a single file about a process you are already looking at. The folder dialog is for sorting a batch: some items new processes, some updating or varying existing ones, some kept as reference.

Written documents

Not every fact arrives through an interview — someone replies by email, answers on a call, or corrects something in chat. With an Initiative selected, the Library lists those under Documents as Written document rows: each says who recorded it and how (Pasted by …, Saved from chat, Saved from Architect chat, Answer to an Architect question, Learned from interviews) and when. Click one to read it; an initiative admin, or the person who added it, can edit the title and text there or delete it, and move it between folders. The filter in the header finds them by title, text, or who added them.

When Chat or the Architect's Analysis chat records a fact for you (Saved from chat, Saved from Architect chat), it is saved the moment the assistant does it — there is nothing to approve — and the conversation shows a Saved to the initiative card with an Undo button that removes it again. After that, the Library is where to edit or delete it.

One of them writes itself. Learned from interviews is a single document per Initiative that Scout keeps up to date: each time an interview completes, the terms and abbreviations the person used, the systems and tools by the names they call them, roles, teams and sites, rules later work must respect, and facts a later interviewer would otherwise ask again are added to it as one line each, under headings (Terms and abbreviations, Systems and tools, People, roles and teams, Places and sites, Rules to respect, Facts already established), with the interview and date each came from. A later interview that explains a term differently replaces that line rather than adding a second one, so there is always one current meaning. Later Scout interviews use those meanings instead of asking what a word means, and Architect reads the evidence with them. Edit or delete a line in the Library to correct it; an initiative admin can delete the whole document and Scout starts it again from the next interview. It appears once the first interview on the Initiative completes, and only when that interview established something worth keeping.

Add one with Add → Upload or paste: paste the text (give it a title if you like) and keep it as a Document. It is filed in the folder you have open, or at the top of the Library. Anyone who can add to the Library can do this; a read-only member sees them but cannot add. The Library is the only place written documents are managed: the Architect page's Run Analysis window counts them and opens the Library, and an older Settings → Business Context link opens the Library too.

A written document can also be about one process. Those appear on the process page's Documents tab under Notes, and Scout reads them when it records that process, so an interview about it starts from what is already known.

Every analysis run and the assistants read these as clearly-labeled background — useful, but weighed below what interviews show. A short text document kept in a folder (.txt or .md under 20,000 characters) is read the same way; longer documents are read as procedure evidence when they describe a procedure, as before. A new one counts as new input for the next run.

Managing folders

Admins manage the tree from the panel itself. Drag a folder onto another to nest it there (dropping on a process row nests it in that process's folder), or onto any empty part of the tree — the whole tree highlights — to move it to the top level. Hover a folder for its ⋯ menu: New folder inside, Rename or retag (name, where it sits, who can see the documents, department and process-type tags), Move up a level (out of its parent, beside it), Delete (subfolders and anything filed move up one level).

Who can see the documents is the folder's audience — Organization (everyone in it) or Initiative (members of an initiative only, including invited partners). Everyone always sees the folder itself; the setting is the widest a document inside may be shared. Saving it narrows every document and subfolder in the folder that is shared more widely; a document already shared more narrowly (an initiative document, someone's Only you draft) keeps its own setting. The Access column on a folder row shows it. A subfolder is at most as open as the folders above it, and inside an initiative-only folder Who can see on a file no longer offers Organization. Choosing Initiative — or moving a folder under an initiative-only one — needs an initiative selected in the Library, which the folder's organization-wide documents join; without one the save is refused and says so, and nothing changes. Adding a document to an initiative-only folder likewise asks for an initiative to be selected first. The ⋯ at the top of the panel offers New folder, New top-level folder, Create a folder per department (one tagged folder per department, with that department's unfiled processes filed in; shown only while some department has no folder) and File unfiled processes (moves every process with no folder into its department's folder). The header stays put; the table and the folder panel each scroll on their own. An empty folder says so. The address bar carries the selected folder, so a view inside the structure is a shareable link.

An organization with no folders yet still has a working Library: every process and document sits at the top, uploads land there, and admins see Create a folder per department to build a starting tree in one click or New folder to begin by hand. Other members see a note that an organization admin can add folders.

A process is filed into a folder from its own page: Move in the header (or File in folder when it has none) opens a picker listing every folder by its full path, with Library (no folder) first. The import dialog has no folder picker of its own: opened from inside a folder it shows one line, Files into …, with the folder path and the department it implies, and the department picker is left out when the folder carries one; opened with no folder open (the top of the Library, or Import it from Scout's New Session dialog) you pick the Department, and the process goes into that department's folder when the tree has one. The same holds for every new process, whatever created it: a process Scout creates when an interview completes, one Architect adds from an analysis, a variant seeded from an interview or split out of a version, or a department assigned in Architect all land in the folder tagged with their department when the tree has one, and at the top of the Library otherwise. Changing the department of a process that is not in any folder files it the same way; a process already in a folder stays where it is. Filing applies the folder's department: if the folder, or one above it, carries a department, the process moves to that department. The picker says what will change before you confirm.

A process is a container with two sides. Its definition is the versioned deliverable:

• A current (published) deliverable — the official SOP, BPMN diagram, and flowchart in use right now. The top of the SOP shows which version you're looking at, its date, and the interview it came from.
• A version history — every revision, with the date, source interview or file, and a short summary of what changed.

Around it sit the things it was built from and the things kept with it: its interviews (the recordings that have fed into it), its documents (the sources it was read from, the supporting documents kept with it, and written notes about it), and, when it runs differently by region, entity or team, its variants (see Variants above).

The process page

Open a process and you land on its page. The header is two short lines. The first is where it lives: a back arrow that returns to the folder the process is filed in, then the path Library / … / that folder with each step a link, and its status (Published · v3, Draft · not yet published, or No deliverable) at the right. The second is the name, with the department (click it to open the department page) and initiative beneath it, and on the right Add files (see Adding files to a process below), Start a to-be when the process has a published diagram, and Move (or File in folder when it has none) to change where it is filed. A ⋯ menu at the end holds Rename… for anyone who may edit the process's deliverable (see Who can edit a process's deliverable below) and, for those who may reorganize the library, the variant, merge and delete actions (see Reorganizing the library).

Below the header the page is split in two:

• Tabs on the left — Document (the SOP), BPMN, Outputs, Analysis, Coverage, Activities, Intended vs Actual, Documents (its Sources — the files the process was read from — its Supporting documents — files kept with it, including a file uploaded in Scout on an interview of this process — and written Notes about it, with a count — click a file to open it) and Interviews (the recordings it has absorbed, with a count). Analysis is the rest of the process in one place: cards for what is still missing from its steps (this is there before Architect runs), the gap notes from the latest Architect run when there is one, and the suggestions that name this process (the same suggestion is listed on every process it spans; only people who can see To-Be see suggestions). Full analysis in Architect opens the run those notes came from, and the tab also links to its Scout sessions. Coverage, Activities and Intended vs Actual only appear when the process has something to show there — a process with no step outline has no Coverage or Activities tab, and Intended vs Actual appears once its department has been graded. An older link to the Sources tab opens Documents.
• Versions on the right — drag its left edge to give the timeline more room; the width is remembered. A timeline of every version, newest first, each marked Published (green, ticked), Draft (newer than the published version, awaiting review) or Superseded (older than the published version), with its date, where it came from (an interview, an imported file, or a hand edit) and a short summary of what changed. Click a version to open it in the Document tab; the one you're reading is marked Viewing.

Moving between processes. While a process page is open, the Library's folder tree hangs under Library in the app sidebar: the same folders as the Library's panel, with the processes filed in each listed beneath it and the process you're reading marked. Click another process to open its page; click a folder to open it in the Library. To find a process by name, use the sidebar's Search (⌘K) above the tree. With an initiative selected it shows only that initiative's folders, as the Library does.

Reading the tree. In both the Library's folder panel and the sidebar, each folder shows how many processes it holds (counting its subfolders — hover for how many are published), and each process carries a dot: green Published, amber Draft · not yet published, hollow Needs deliverable (hover for the label). Variants of one process gather under a group node in their folder — a branch icon, the group's name and how many variants — with the variants beneath it on a purple line that runs through their dots; the chevron folds the group, and clicking the group's name opens the group's page (see The variant group page). Variants are filed together, so the node's count is the family's; a family left spread over folders from before that rule shows 2/5 on each part, with the rest named on hover. From one variant's page, its siblings and their group are right there in the sidebar; on the group's page the tree marks the group as the page you are on.

The Document tab shows the version you picked with a toolbar above it: the version number and status, Edit, Download (PDF, Word or Markdown), a ⋯ menu (Open BPMN diagram, Open flowchart, Regenerate) and — on any version that isn't the published one — a Publish button. Edit, Publish, Regenerate and the BPMN tab's Edit are only offered to the people who contributed to the process — see Who can edit a process's deliverable below; everyone else sees a Read-only marker in the toolbar and can still read, download and compare. Edit is also only offered on the process's latest version. An older version — one that was superseded, or the published version while a newer draft waits for review — shows Superseded by vN in place of Edit, with an Open latest shortcut; it can still be read, downloaded and published. Editing an older version would fork the history, so changes always start from the newest one. The BPMN tab shows that version's diagram. Edit opens the same BPMN editor as a Scout diagram, including the properties panel, AI Edit, and a BPMN 2.0 download. It always edits this version's own diagram — including on a version that came from an interview — so what you save is what the process page shows; the interview's own copies are not touched. Saving from either editor on a process page first asks what kind of change this is: Update v3 in place or Save as a new version to review (v4). Pick in place for a correction that doesn't change how the work is done — a typo, a clearer sentence, a tidier layout. Pick new version when the process itself changed — a step, lane, decision or connection added, removed, renamed or moved. The BPMN editor lists the changes it detected and proposes new version whenever it found any; the SOP editor proposes it when AI Edit flagged the accepted edit as a process change, and otherwise leaves the choice to you.

A new version is written as the process's next version — a draft in the Versions timeline, dated when you saved it and noted as "Revised from v3 in the editor" (with your AI Edit or diagram changes listed) — and the version you started from is left exactly as it was. The other deliverables are brought into line on the new version right away: a saved diagram updates the SOP and the flowchart there (tick off the ones you want in the same dialog), and a saved SOP updates the BPMN diagram and flowchart. The editor reports when each one has been updated, already matched, or failed (with a Retry). The page then opens on the new draft, so the person who approves changes reads it beside the published version and makes it official with Publish when it is right.

An in-place save overwrites that version's own document. The diagram editor still offers to update the SOP and flowchart on it to match, and after a saved SOP a bar offers to update the BPMN diagram and flowchart. Every in-place edit leaves a note under the version in the timeline ("SOP edited in the editor", "BPMN diagram updated to match the edited SOP"), so a version that was changed in place says so.

Renaming a process

Rename… on the process page — or Rename on the process's row in the Library — renames the whole process, not just its entry in the list. The new name is written into every version of its deliverable: the SOP's title (and a header field that repeated the name, such as Document title) in the published version, any draft and every earlier version, and the pool of its BPMN diagram where it was named after the process. Chat's copy of the published SOP is refreshed under the new name too, so a search finds it by what it is called now. The body of the SOP is not touched — a sentence that mentioned the old name stays as its author wrote it. Interviews and documents the process came from keep their own names, and a process that also appears in Architect keeps the name the analysis gave it there.

Adding files to a process

Have a document about a process that already exists — a newer SOP someone found, the form the team fills in, the policy the process follows, a checklist, a screenshot? Open the process and click Add files (in the header, or on the Documents tab), or pick Add files… on the process's row in the Library. Drop one or several files; PDF, Word, PowerPoint, Excel, CSV, text, Markdown, PNG, JPG and WebP are accepted, as are a BPMN 2.0 file and a Teams/Zoom transcript, up to 30 MB each.

Each file is kept as a supporting document of the process unless you say otherwise: it appears under Supporting documents on the Documents tab, marked Kept with the process, and is searchable in chat, but the process itself is not changed — and Architect keeps reading the process, not the file beside it, so nothing is counted twice. For a file that could also be a description of the process (a PDF, Word or PowerPoint document, an image, a spreadsheet), a picker on its row offers Update the process from it instead: its steps are read and merged into the outline and become the process's next version — published if nothing is published yet, otherwise a draft for you to review — exactly as Import existing process with Add to does. A .bpmn file or a transcript can only describe the process, so those always update it. One file at a time can update the process; keep the others as supporting documents or add them in another round. Contributors on the initiative can add files; viewers and guests see the list only.

A supporting document has a remove button on its row (the person who added it, or an admin); removing deletes the file. A file the process was read from is listed under Sources instead (The process was read from this file). It is not listed in the folder, so deleting it — which reverts what was read from it — is offered on that row, for anyone who can add files to the process. The confirmation says the versions and steps that came from the file will be reverted, including on any other process that was read from it.

A document uploaded in Scout, on an interview that belongs to this process, is a supporting document of the process — the same row, opened the same way, as a file added on this page. It is not listed again when the process already keeps that file. Removing it from the process is not offered, because the interview still uses it. Adding a file in the Library and uploading one in Scout both end up on this tab.

Below the files, the Documents tab lists the Notes about this process — written documents from the Library that were filed on it (see Written documents). Click one to read or edit it. Every analysis run reads them, and so does Scout when it records this process.

None of these documents are listed in the folder the process is filed in: the folder's Reference documents are only the documents that are about no particular process. The process's Library row counts them instead (1 source · 3 supporting documents).

When a process has no interviews yet, the Interviews tab offers Record with Scout (also on the process's Library row): it opens Scout's New Session dialog already tagged Part of an existing process with this one, so the recording deepens the same steps rather than creating a duplicate.

Reorganizing the library

A library that grew out of many imports and interviews ends up with processes that should not be separate, versions that should be, and the odd process nobody meant to create. The person who created a process, an administrator of its Initiative, or an organization admin can put that right from the row's ⋯ menu in the Library or the ⋯ menu on the process page. Nobody else sees these actions.

• Delete. Removes the process with all its versions and documents. Before you confirm, the dialog says exactly what goes with it and what stays: the interviews it was built from stay in Scout, files you uploaded or added to it stay in the Library, and an unfinished interview tagged to it simply loses the tag. If it was one of several variants, it is taken out of them; the other variants are untouched, and a pair left with one is no longer shown as variants. A process that is also on an Architect process map is listed again after the next analysis run — the dialog says so when that applies. Select several processes to delete them together.
• Make a variant of… / Move to the variants of… The picker lists the Initiative's existing Variant groups (each once, by the group's name, searchable by its variants' names) and, under Processes, the processes that are in no group yet; a process already in a group is reached through its group rather than listed on its own. Pick a group and this process joins it; pick a process and the two are shown together as variants. If this process was itself among other variants, it leaves those first. It moves into the folder the group (or the process you picked) is filed in.
• Group as variants. Select two or more processes and choose the shared name they appear under. If one of them already has variants, the rest join it; a group Architect proposed but nobody confirmed is confirmed by this. The group is filed together — in the folder it already lives in when joining one, otherwise in the folder most of the selected processes are in.
• Remove from variants. The process stands on its own again; its former siblings keep each other.
• Merge into another process…. For a "variant" that is really the same procedure, or a duplicate created by two imports. Its current document is added to the other process as that process's next version — published straight away if the other process had nothing published yet, otherwise as a draft for you to review and publish — its interviews and its documents move across (its supporting documents, and the files its other versions were read from, become supporting documents of the other process), and it is removed from the library. Only its current document comes over as a version; its earlier versions do not.
• Make this version its own variant. On the process page, open the version in the Document tab and choose it from the ⋯ menu. For the version that was added as an update but really describes how one region, team or category runs the process. A new process is created beside this one, shown with it as a variant, with that document as its first version; the version leaves the original. When the version came from an interview, the interview itself moves to the new variant with everything it contributed, and the original goes back to the document it had before — the same as Keep as a separate variant on the interview. If the version leaving was the published one, the original is left with nothing published until you publish another. The only version of a process cannot be split out — delete the process or merge it instead.

None of these touch the recordings: a Scout session is never deleted by reorganizing processes.

How processes are created and updated

• Automatic first version. The first time an interview's SOP and BPMN finish generating for a process Linc hasn't seen before, a process is created automatically, seeded from that interview as version 1.
• Recording in parts, or your version of it. Tag a session with "Part of an existing process" — when you're capturing one process across several recordings, or when you're recording how your region or team runs a process the library already documents. The interviewer starts from that process's documented steps rather than asking you to describe the process from scratch, and when what you do differs from what is written it asks whether the documentation is out of date, whether that's how your region or entity does it, or whether it's your own workaround. You never have to say what the finished interview should do to the process — Linc reads that off the recording (see What an interview does to a process below) — with one exception you can settle up front: once a process is picked, a checkbox "My region, team or category runs this differently" appears under it. Tick it when you are recording your own way of running the process rather than correcting the documented one. The interview is then kept as a variant alongside the process you picked, the existing document is left as it is, and the interviewer spends its questions on how your version works and when it applies instead of asking whether the documentation is wrong. Leave it off when it is the same procedure and what you say should update the document.
• Automatic matching to the library. If you don't tag it, Linc matches the finished interview against every process in the initiative and at org level — including imported or outlined processes that have no written SOP yet (it compares their step list) — by name, description and the actual procedure, not just shared department or systems. Then:
  • Clear match — after a second check that reads both procedures in full, Linc files the interview against that process the same way as a tagged one (below), with one difference: a corrected version added by an automatic match stays a draft (published only if the process had nothing published yet). The interview's Process area shows what happened — "Recognised as this process and added as vN (draft)", or "Recognised as this process — it confirms the documented procedure, so it was attached as evidence" — with the match strength and why, and, for the interview's owner or an org admin, a Not the same process button that pulls the interview back out and gives it its own process.
  • Likely match — nothing is changed; a proposal appears on the interview's completion screen and the Processes page: "This interview looks like it is about the existing process [Process X]." Only the interview's owner (or an org admin) decides: Same process, Same process, run differently here, Different process, or Dismiss. After Same process, Linc works out what the interview does to the process and tells you: attached as evidence, merged and published as a new version, or kept as a variant. Same process, run differently here skips that guess — the interview is kept as a variant alongside the process and the existing document stays as it is. Different process makes a new process from the interview, unless that interview is already filed on a process in the Library (for example one built from it by analysis). Then Linc keeps that process, tells you its name, and offers to save the interview's documents as a new draft version of it instead of adding a second process for the same interview. When several interviews are waiting, the Processes page folds them into one strip — "N interviews look like processes already in the library" — and Review opens the cards. The same decision is flagged where the interviews are: in Scout, the session shows a Needs a decision chip, and its Processes tab carries the count and opens first.
  • No match — a new process is created from the interview, unless the interview is already filed on a process in the Library, in which case that process is kept.
• Gap interviews are checked against the process they were planned for. When the interview planner sends an interview for a gap on a process that already exists in the library, the invitation remembers that process. Once the recording finishes, it is compared against that process first; if it really is the same work it is filed against it like a clear match (with the same Not the same process undo) rather than becoming a parallel process. If the comparison doesn't hold, the normal matching above runs instead.
• What an interview does to a process. Once Linc knows an interview is about an existing process — because you tagged it, confirmed a match, or the match was clear — it reads the recording against the documented procedure and does one of three things. The distinction matters: a variant is not an update.
  • Confirms it — the respondent describes the same procedure (wording, level of detail, and personal shortcuts don't count as differences). The interview is attached as evidence of the current version: it appears on the process's Interviews tab and deepens its Coverage, but the official document is not rewritten and no new version is created.
  • Updates it — the documentation is out of date or incomplete for the work it covers: the respondent said so, or described steps, approvals, owners or systems the document lacks or contradicts. The interview becomes a new version — the current official SOP merged with the new interview, so nothing already documented is lost. It is published when a person vouched for the pairing (a tagged session or Same process) and left as a draft after an automatic match.
  • Is a variant of it — the same process, run a legitimately different way because of the respondent's region, entity, site, team or system. The documented process stays right for its own scope; the interview becomes its own process, grouped with the original as a variant (see Variants below), not a new version of it. The interview's Process area says so: "a variant of [Process X], not a new version of it". When Linc cannot tell, it keeps the interview as a reviewable new version — the one outcome that loses nothing and can be undone.
• Changing your mind: "Keep as a separate variant". When an interview was added to a process as a new version, or kept as evidence of it, but it is really how your region, team or category runs the process, open the interview's Process area. The card says what happened in one line — "This interview updated the process — it is now v4" or "…kept as supporting evidence of v2" — with a Why? link for Linc's reasoning, and, for the interview's owner or an org admin, a Keep as a separate variant button. Confirming it takes the interview's changes back out of the process — if the interview's version had been published, the document it replaced is published again; if other interviews were added after it, a fresh draft is rebuilt from what remains — creates the interview's own process grouped with the original as a variant, and the card updates to "a variant of [Process X]". The same button sits next to Not the same process on an automatic match, for the case where it is the same process but run differently where you are.
• Deleting an interview rolls back its contribution. Deleting a Scout session removes the version it produced; the deliverable reverts to the newest remaining version, or is rebuilt from the remaining interviews if others were added after it. The reverse is not true: deleting a process never deletes its interviews (see Reorganizing the library).
• Generate deliverable. A process that came from analysis or an import but has no written SOP yet shows a Generate deliverable button on its page (Generate on its row in the Processes list) that builds one from the interviews behind it — or, for an imported process, from its documented steps.
• Written to your SOP template. A generated or merged process SOP follows your organization's default SOP template: its sections, with the template's titles and in its order (disabled sections are left out), and its header fields (Document ID, Owner, Version, …). Every enabled section is present exactly once — a section the sources say nothing about reads "Not documented in the sources." rather than being dropped. Without a customized template, the standard sections are used in a fixed order, so two processes in one organization always share the same structure.
• Shown in your template. The process page's Document tab shows the SOP in your organization's designed template (logo, numbered headings, header table, footer) — the same look as a Scout interview's SOP. Edit opens the same editor as a Scout SOP (formatted text, not raw markdown). Without a designed template, the formatted document is shown and Edit still opens that editor.
• Process flows inside the SOP. If the template has a process map slot (see Settings → SOP templates), the version's BPMN diagram is drawn into that section, and any flow fragments the SOP places after its steps show the matching part of the diagram. They come from the version's own BPMN, so a version without a diagram shows the prose alone. A map too wide to read at page width is drawn as consecutive numbered parts ("part 1 of 3: Request received → Check budget"), each following the flow, rather than shrunk to fit.
• Your own diagram is kept. If the process was imported from a .bpmn file, or from a diagram (PDF, image or slide) whose flow Linc could read as drawn, Generate deliverable and Regenerate keep that diagram and only write the SOP — the map is not redrawn from the prose. The first SOP generated over a map-only version is published alongside it rather than left as a draft. A process imported from a written Word procedure or a spreadsheet gets a generated map; when an imported document held a process map picture, that picture is also added to the same section as an "As documented in …" figure so the two can be compared.
• Pictures from the imported document. Screenshots and figures found in an imported Word, PowerPoint or PDF file (or an imported image) are carried into the generated SOP next to the steps they illustrate, each captioned from the text around it. Logos, header/footer artwork, tiny icons and duplicates are left out. On the Coverage ladder, a step with such a picture shows a screenshot marker citing the file and page or slide it came from; hover it to see the picture.
• Download. The Download menu on the Document tab offers PDF — the SOP as shown in the template, map and fragments included (a plain layout when there is no designed template); Word (.docx) — editable, with the process flows embedded as images; and Markdown (.md) — the plain text. Open BPMN diagram and Open flowchart are in the ⋯ menu beside it.
• Regenerate. On a process that already has a deliverable, Regenerate (in the ⋯ menu) writes a new version from the process's sources in the current template. It is added as a draft to review and publish — the published version and its history are kept.

Import existing process — no interview needed

If a process is already documented, you don't have to interview anyone to get it into the library. In the Library, click Add → Upload or paste (the New Session dialog also links to it, under "Already documented?"). Dropping a PDF, image, Word, PowerPoint, Excel, .bpmn, transcript, or notes file on Home's Documents card offers the same import. Select an initiative first — imported processes are filed under the initiative you have open, the same as recorded ones, and the dialog says so if none is selected. Anyone who can contribute to the initiative can import; read-only viewers and guests can't. If the file names a person — a full name or an email, not a job title or a team on a step — that person is suggested on Settings → People. The suggestion waits for review; the directory changes only when someone accepts it. Drop one or many files:

• BPMN 2.0 XML (.bpmn, or .xml from a modelling tool) — the uploaded diagram is the deliverable. You get a published version 1 with your BPMN exactly as drawn (a layout is added only if the file has none), plus a step outline read from its tasks, lanes and gateways.
• PDF, PNG, JPG, WebP — an exported diagram or a scanned procedure. Linc reads the steps, roles, systems and decisions off the page. For a drawn diagram it also transcribes the flow itself — every arrow, each gateway with its kind (a parallel split stays a parallel split), the start and end events, notes, and boxes that name other processes feeding or consuming this one — and publishes that as version 1's process map, exactly as drawn, the same way a .bpmn upload is. The result line says process map transcribed as drawn; Generate deliverable then writes the SOP and keeps the map. Referenced upstream/downstream processes are named in the step they feed and in the process description. A written procedure (no arrows) lands as steps only, with its map drawn later. A decision point shows up in the ladder as its own Decision: … entry, right after the step it follows, with the labelled outcomes. A PDF of meeting notes or of a transcript is read as interviewed evidence instead, like the Notes and Transcript entries below — see Word for how Linc tells them apart and how to correct it. A scanned PDF has no text Linc can read as notes; paste the notes or export them as text.
• Word (.docx) or PDF — a written procedure, or a Teams transcript or meeting notes saved to Word or PDF. Linc detects which from the contents: a transcript by its timestamps and speakers, meeting notes by their shape (a date, attendees, what was discussed, decisions). If it gets it wrong, click Treat as next to the file and pick Process document, Transcript, or Notes. A procedure lands as outlined steps; a transcript or notes land as interviewed. That override appears on Word, PDF, transcript and notes files only — images, decks, spreadsheets and .bpmn are always read as process documents. When a Word or PDF file yields no steps as a procedure, its result row offers Retry as notes.
• Teams/Zoom transcript (.vtt, .srt, Zoom .txt) — the recording of the conversation is the evidence. Steps are graded interviewed, with a speaker/timestamp citation on Coverage. No Scout session is created. The SOP and process map are generated as part of the import. A transcript downloaded from Microsoft Stream or a Teams recording — each timestamp on its own line, then what was said, with no speaker names — is recognised too, whether it comes as .txt or as the Word download; its steps cite the timestamp alone.
• Notes (.txt, .md, Word, PDF, or pasted straight into the dialog) — meeting notes, notes from a walkthrough, or a written description of how the work is done, treated the same way: interviewed evidence, with the SOP and process map generated as part of the import. To paste, click Paste text instead under the drop zone, paste (give it a title if you like), and click Add — it joins the file list as Pasted notes (or under your title). In the Library, a short paste opens as a Document rather than a process; flip the row's switch to read it as one. A transcript that's too long to import in one go is refused with a message — split it into a shorter excerpt and import again.
• PowerPoint (.pptx) — a deck with the process drawn or written on its slides. Each labelled shape in a flowchart becomes one step, in the order the arrows point; diamonds become decisions or parallel splits and the connectors become the flow, so a drawn slide gets its map transcribed as drawn like a PDF diagram; a group or swimlane around shapes becomes the role for those steps; SmartArt, tables, bullets and speaker notes are read too. Pictures pasted onto a slide aren't read for steps — export that slide as PNG or PDF instead — but they are kept and carried into the generated SOP as figures.
• Excel (.xlsx, .xls) / CSV — a step ladder (one row per step, with columns such as Step, Description, Responsible, System).

A file usually becomes one process — but see When one file holds several processes below: a deck that draws the same flow once per region, or a procedure manual with a chapter per operation, is read as several. When the process is already in the library, say so: Is this process already in the library? lets you type to search and pick it, then choose Update it or New variant of it. Update it (one file at a time) adds the document as that process's next version — it's published if the process has nothing published yet, otherwise it's added as a draft for you to review (and it keeps the existing process's department). A .bpmn is that version as drawn; any other document has its steps merged into the process's outline first, and the new version's SOP and BPMN are generated from that outline together with the process's existing interviews. New variant of it reads the file (or each file, when several are picked) into its own process and shows it with the one you picked as variants (see Variants), filed in that process's folder. The results screen says when a variant could not be grouped and how to do it from the Library row. Leave the question unanswered and the file becomes a new process of its own.

Set a Department for new processes if you want one. Type to search; the picker offers the initiative's departments in scope — the same rule as Scout, and all departments when none are set — and No department is fine. Steps arrive at outlined depth in the Coverage ladder when the file is a diagram or procedure, or interviewed when it is a transcript or meeting notes — so the process shows up on the department tile straight away. Recording it later with Scout ("Part of an existing process") deepens the same steps to recorded instead of creating a duplicate. For diagram and procedure imports, click Generate deliverable on the process to produce the SOP in your organization's template and theme — with the transcribed map kept when the diagram was read as drawn, or a map drawn from the steps otherwise. A transcript or notes import generates those deliverables as part of import.

Turn on Use as industry reference model when the file is a target to compare against (a published methodology, an APQC-style map, your own PMM) rather than how the organisation currently works. Architect's Benchmark tab uses it as the cited reference and does not treat it as observed as-is evidence. The switch is offered when you're importing new processes. It isn't available when you're adding a file as a new version of an existing process — a reference model has to come in as its own process.

Importing several variants at once. Drop the regional versions of one process together (for example NA_…, BR_…, APAC_…) and turn on These files are variants of one process. Linc guesses the shared name and a label per file from the file names — edit either — and creates the processes already grouped as variants of one process. If the group couldn't be recorded (or only one of the files imported, so there was nothing to group), the results say so — the processes are still imported, each standing on its own.

When one file holds several processes

Documentation often isn't one process per file: a deck draws the same flow once per region or entity; a procedure manual has a chapter per operation (create, modify, block…); an overview page routes to detail flows; integration flows are shared by all of them. Read as one process, those versions would merge into a single flow that nobody actually runs — so before a PDF, image, Word or PowerPoint file is read, Linc first looks at what it holds.

If the file holds one process, nothing changes: it is imported straight away as before. If it holds several, the import pauses on a confirm screen that lists what was found in each such file, one row per unit, with a role:

• Process — a process of its own.
• Variant — one of several variants of the same process, applying in different circumstances (a country, an entity, a system). Variants of one process are imported as separate processes and grouped together, exactly as if you had dropped one file per variant and turned on These files are variants of one process. Each variant's description starts with Applies when: — the conditions Linc read off the file's routing table or the version's title (for example New Purchase Request · category RGA, Indirects · all regions except Brazil and NA). (Not to be confused with a process's versions — v1, v2 — which are revisions of one process's deliverable over time.)
• Overview — a page that routes rather than executes (a macro workflow, a "which procedure applies" map). Imported as a process of its own, with the flows it routes to named as the processes it hands off to. It is never part of the variant group.
• Sub-process — a flow the others hand off to (an integration, a shared approval). Imported as a process of its own; the processes that end in it say so in their description (Hands off to:).

Each row shows the unit's pages, its name, and — for a variant or overview — the process it belongs to. You can untick a unit to leave it out, edit its name or the process it belongs to, change its role, or flip Read as one process to import the whole file as a single process after all (the right call when the units listed are really the stages of one flow).

Paths inside one process. Not every variant deserves a process of its own. When two variants are done by the same people in the same systems and differ only by their trigger or a condition — a change request instead of a new request, one extra approval, a value threshold — Linc suggests reading the smaller one as a path of the other: it appears indented under that variant with the reason (for example same lanes and steps; differs only by the trigger), and the header counts how many processes the file will become. The two are then read together as one flow, with the difference drawn as a decision (a gateway) whose branches carry each alternative's condition, and the process's Applies when: names both cases. Each variant row has a selector — Its own process or A path of "…" — so you can split a suggested path back out, or fold a variant in that Linc kept separate. A variant that runs in a different system, is done by a different team, or shares only part of its steps (a regional flow that starts in a different tool, say) is never suggested as a path. Pages Linc decided are not a process — covers, legends, glossaries, coding-rule tables, a lifecycle figure that only sets the scene — are listed as Left out. Nothing is written until you click Import; Cancel removes the uploaded files again.

Each unit is then read on its own pages (a deck is re-read with only that unit's slides; a PDF with only its pages), so a variant never picks up steps from its neighbour. The results list every process the file became, with its role, and say when variants were grouped. Files that hold one process are listed as such on the confirm screen and imported alongside. A file added as a new version of an existing process is always read as one process, since that process is what you chose.

A file with an unusually large number of units — more than about sixteen — is flagged on the confirm screen: that usually means a process library rather than a document, and importing chapters separately gives cleaner results.

Variants in the library

Variants of one process — grouped at import, whether from one file or several — show up together. In the Library, two or more variants of the same process are gathered under a variants row (the shared name, a branch icon, "6 variants · 4 published"); the chevron at its left collapses or expands it, and clicking the name opens the variant group's page (below). Anywhere in the app a variant group opens the same way a process does — in this tab, with Back returning to where you were (the Library row and its Compare button, the folder tree in the sidebar, Open variants on a variant's page). Each variant beneath it is named by what varies ("New Request · Brazil", "BR") and, when the import read it, shows Applies when: with the circumstances it applies in. A variant whose siblings are filed in other folders keeps its full name and carries a Variant of … detail instead, so the tie is never lost.

The variants row ends in a Compare button that opens the group's page on its Steps tab — the step-by-step grid of how the variants differ. It works straight from the library: no Architect analysis needs to have run, and a variant imported from a document compares through its published SOP.

On a variant's own page, one line under the title says which variant of which process it is — Variant Brazil of Accounts Payable — and ends in Open variants, which opens the group's page. The other variants are not listed there: the sidebar's tree keeps the whole group together on its purple line, so you step through the variants from the sidebar.

The variant group page

A variant group has a page of its own, laid out like a process page: the group's name under a Library / folder breadcrumb, a status at the right (3 variants · 2 published, or Possible variants while Architect's proposal is unconfirmed), a line saying how many ways the process runs and in which departments and initiative, and tabs across the top. Down the right side, the Variants rail lists every variant — its short name, published / draft / no-deliverable status, Applies when:, department and people, and, once the comparison has run, its coverage of the standard and how many steps it would change. Click a variant to focus the Map and Changes tabs on it; click again to clear. The arrow at the end of a row opens that variant's own page. A variant in an initiative you can't open is not listed — the rail says how many are missing, and the comparison covers the ones you can see. When fewer than two are visible, the tabs say that the rest are in initiatives you can't open, rather than that the group has shrunk to one process.

The comparison the tabs show is the one Architect uses (see Architect → Working with several processes at once). It is generated the first time the page opens — Aligning 3 variants… — and kept, so coming back is instant; Regenerate rebuilds it after a variant changes, and Export downloads it as JSON. The comparison reads each variant's Activities grid too — fill in Responsible and System there and the scorecards show how many roles and systems each variant touches.

• Overview — why these are variants (Architect's or your reasoning), the alignment and coverage badges, a scorecard per variant, the summary and top recommendations, and a When each applies list.
• Map — the standard's diagram with the selected variant's changes drawn over it (Standard), or every variant's diagram at once (Side by side).
• Steps — the step-by-step grid. Steps as rows lists each step of the standard with a cell per variant (same / different / missing / extra), with the alignment strip above it; Variants as rows turns it round, one lane per variant, and clicking a step in the strip jumps to it there.
• Standard — the harmonized standard the variants reconcile into: the impact strip, the standard's diagram and its step-by-step list with a Decision needed panel under every divergent step (adopt one variant's way, keep the recommendation, write the standard, allow a local variation, or defer), and Workshop mode.
• Changes — what each variant would change to meet the standard, or only the selected one.

A group with fewer than two reachable variants shows its details but no comparison. While a group is still Possible variants, an amber strip under the header carries Architect's reasoning with Confirm and Not variants — the same choice the Library row offers; Not variants returns you to where you came from. The ⋯ menu offers Rename group… when you may reorganise every variant in it.

Renaming a variant group. The shared name over a group can be changed: on the Library's variants row, click the pencil beside Compare (Rename group), type the new name and save. The name changes everywhere it shows — the Library row, the sidebar tree and the line under each variant's title. The pencil is offered when you may reorganise every variant in the group (you created them, you administer their Initiative, or you administer the organization); a group Architect has only proposed (Possible variants) is confirmed first.

Each file gets its own result line when the import finishes — how many steps were outlined or interviewed, whether a version was published, the folder it was filed in when it went into one, and low read confidence — check the steps when Linc wasn't sure about a diagram or scan; that process was still created, so open it and check the Coverage ladder against the original.

The source files are kept as provenance: the process page lists them under Sources on its Documents tab (click a file or Open file to open it), each version says which file it was imported from, and the files are searchable in chat. Pictures inside the file (screenshots, a drawn process map) are kept too, and appear in the SOP once you generate the deliverable — see Pictures from the imported document above. Files up to 30 MB each, or 5 MB for images (PNG, JPG, WebP), or 1 MB for transcripts and notes; a file over the limit is skipped when you add it, with a message naming it. Imports that Linc can't read (an XML that isn't BPMN, a spreadsheet with no step column, an image with no legible steps) are reported per file, and the rest of the batch still goes through.

Imported processes take part in analysis. When Architect runs, every imported process in the initiative is analysed alongside the interviews and uploaded procedure documents, whether or not anyone has been interviewed about it yet. Its documented steps are the evidence; if no one has been interviewed about it, its published SOP is read too. It appears in the Architect process map — filed in its department, with a Documented, not observed badge until a Scout interview or recording is attached — and is counted in variant detection, gap and opportunity analysis, and the roadmap. Like every process, its published SOP is what chat quotes (see What chat reads above). Turn this off for an initiative with Include imported library processes under Settings → Project brief; it is on by default. Variants you grouped at import time are kept: Architect does not re-propose a group that already exists.

An imported process that has never been interviewed can still be redesigned: its page shows Start a to-be, which opens Designer on its published diagram.

Activities — the attributes every step must state

A process with a step outline has an Activities tab: a grid with one row per step and the attributes your process-design standard expects on each one — Responsible, Input, Output, System, Evidence (the record the step leaves behind, as an auditor would ask for it) and Manual / Automatic.

Linc fills in whatever the source stated. A swimlane diagram gives Responsible; a data store gives System; a modelled task type gives Manual or Automatic; a spreadsheet gives whichever columns it had, matched by header (so "Owner", "Tool", "Proof" and "Type" land in the right places); a PDF, Word document or picture of a process gives whatever it states in words. Anything the source didn't state is left blank rather than guessed.

• Edit any cell in place. Type in a text cell and click away (or press Enter) to save, or press Escape to discard what you typed. Manual / Automatic is a dropdown — Manual, Automatic, Semi-automatic, or Not stated to clear it. Emptying a text cell clears it. Anyone who can contribute to the initiative can edit the grid; read-only viewers see the same grid as plain text, with missing required cells still highlighted. If a save fails, the cell goes back to what it held and a message says why.
• Responsible offers your job roles as a picklist. These are jobs (Accounts Payable Clerk), not the named people in Settings → People. Once your organization has job roles under Settings → People, the Responsible cell becomes a searchable picklist of them: pick a job and that spelling is written, so the same job reads the same way across processes. You can still type anything (Use "…" saves exactly what you typed), and a value the list doesn't recognize is marked with a small warning rather than rejected; an org admin can click that warning to add it to the job roles on the spot. Values written before the list existed keep rendering unchanged, and a job later retired from the list stays on its steps with a "Retired" hint. With no job roles defined, the cell stays a plain text field.
• Required attributes are highlighted when a step doesn't state them, and counted in the % complete score beside the title — the share of required cells filled in across every step. An admin chooses which answers are required under Settings → People (Step requirements); by default all of them are.
• Export downloads the grid as an .xlsx. The sheet uses the same column headers the importer reads, so you can fill it in offline and add it back through Import existing process — pick the same process under Is this process already in the library? and Update it, since importing it as a new process creates a second process instead. The steps match by name, keep everything they already had, and the upload becomes that process's next version, published or left as a draft to review by the usual rule. A decision in the ladder exports as an ordinary row named "Decision: …" and comes back as one.

Re-importing a document never blanks an attribute: a source that says nothing about Systems leaves the Systems already recorded alone. Clearing one is something only a person does, here in the grid.

Where the attributes show up in the deliverable

When you generate (or regenerate) a process's deliverable, the attributes go into both documents:

• The SOP gets an "Activities" section — the same grid as a table, one row per step with every attribute column, "—" where nothing was stated, and required attributes starred in the header. It is written straight from the grid, not paraphrased, so it always matches what the grid shows. It fills your SOP template's Activities section, under that section's title and in its place in the order (for a template without one, it sits after the procedure and before the closing sections). A process with nothing stated on any step gets no table — the section is then written from the sources like any other. If your organization's default SOP template has the Activities section turned off, the SOP is left without it.
• The BPMN diagram honours them. Each step's Responsible becomes its swimlane (a lane is added if the diagram didn't have one by that name); Manual / Automatic sets the task type (a person's step is a user task — or a manual task when no System is stated — and an automated step is a service task); System is drawn as a data store connected to the step; Input and Output as data objects flowing into and out of it; and Evidence as a note on the step. Steps are matched to the diagram by name; a step the diagram doesn't have is left as the diagram drew it.

Editing the grid doesn't rewrite a deliverable that has already been generated — regenerate it to pick the changes up.

Coverage — how much is captured

When a process has a step outline (for example from an uploaded process map), its page has a Coverage tab: a ladder of its steps, each marked by capture depth — not documented, outlined, interviewed, or recorded — with a headline like "6 of 12 recorded" and a % recorded figure. This is capture depth, not correctness. Each step shows a chip for the evidence behind it — a recording, an interview, a document, a Transcript or Notes. A transcript or notes chip also carries the speaker and timestamp it was read from (for example Transcript · Jane 00:01:02), and a step that came in with an imported transcript or set of notes is tagged from transcript or from notes. A Capture next list shows the steps still to record, with a shortcut to set up a Scout session for them.

Intended vs Actual — does it match what leadership intended?

For when a department head says "my team doesn't do it like that." They supply a document describing how the department's processes are meant to work — the prior — and Linc grades the department's actual processes against it. It lives on the department's page (View department from the Processes page, or click a department name on a process), in the Intended vs Actual section under the process list.

1. Upload the prior. PDF, Word (.docx), PowerPoint (.pptx), or markdown, up to 25 MB each; more than one is fine. Each shows Reading while its text is extracted, then Read. Priors are kept in a managed Intended Process Priors collection, managed from the department page.
2. Grade against the prior. Enabled once every upload has been read. It compares each documented process in the department — its published SOP, or the interviews behind it when there's no deliverable yet — against what the prior says. Grading takes a few minutes and can be cancelled.
3. Read the scorecard. A score out of 100 with the headline finding, then one row per process: what the prior says beside what the team actually does, and each difference (missing step, extra step, different owner, system, sequence, trigger, or outcome) with its severity. Below the rows, the processes the prior describes that the department has never documented.

Each process's own page then gets an Intended vs Actual tab with that process's verdict, and says when the grade is out of date — a newer version published since, or a grade taken from the interviews before there was an SOP.

Reviewing, editing, and publishing

• Same process on a match card confirms that the interview is about this process; Linc then reads what it does to it (a "Working…" state shows for about a minute) and reports the outcome — attached as evidence, merged and published as the new official deliverable, or kept as a variant. A version Linc added on its own after a clear match stays a draft until you publish it here.
• Click any version in the Versions timeline to read its SOP and open its BPMN/flowchart.
• Edit opens a version in the same rich-text editor used for Scout SOPs. On save, choose Update vN in place for a wording fix or Save as a new version to review for a change to the process — the latter lands as the next draft with the diagram and flowchart synced to it, ready to Publish (see The process page above). Your edits are durable — re-running analysis or recording again proposes a new version rather than overwriting what you've curated.
• Publish (in the Document toolbar, on any version that isn't the published one) makes that version the current official deliverable.

Who can edit a process's deliverable

Being able to open a process is a read grant. Its deliverable — the SOP, the BPMN diagram and the flowchart — follows the same rule as a Scout session's deliverable: it belongs to the people whose material it was built from. You can Edit, AI Edit, Publish and Regenerate a process's deliverable — and Rename the process, since what it is called is part of it (the rename reaches the SOP's title and the BPMN, see Renaming a process) — when you:

• recorded one of its source interviews (the interview that seeded it, or any interview later merged into it);
• uploaded one of its source documents — a file a version or a step was read from (an import, or a document added with Update it). A file merely added alongside the process with Add files is supporting material and does not count;
• created the process; or
• are an owner or admin of the initiative it belongs to, or an admin of the organization that owns it.

Everyone else who can see the process reads it: the toolbar shows a Read-only marker instead of Edit, and Publish and Regenerate are not offered. A viewer or guest on the initiative is always read-only here, whatever they contributed — the same rule as for activities and adding files. A session collaborator who helped answer an interview does not get edit rights on the process through it, just as they don't on the session's own deliverable; recording or uploading something for the process does. Contributing later (recording another interview for it, or adding a document the process is updated from) makes you an editor from then on.

Because processes have their own stable identity, they are not replaced when Architect re-analyzes your work — your published SOPs and edits are preserved across re-analysis.

Combined deliverables

Roll several processes into one end-to-end deliverable (one SOP + BPMN + flowchart): tick checkboxes on any processes and click Combine for a combined deliverable of just that selection.

Click Generate / Regenerate to build or refresh; it updates as the underlying processes change.