CEP Field Notes

Modules together: The Future Matrix → Conceptual Map → Gantt Chart

Tue, 03 Nov 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Factor Future Contingency
Search: Factor Future Contingency
Develop factors and future stories, prepare responses, then review measures and captured signals in The Future Matrix.
Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Use Future Matrix stories, action rules and tracking to inform a dependency model and an agreed Gantt Roadmap.

Use the Future Matrix sections to explain why a response is being considered, then use Conceptual Map and Gantt Chart to work through its dependencies and agreed preparation. Return to the measures and captured signals when reviewing the plan.

The Future Matrix was created by Julio Graham, who operates Olive Professional Services.

Develop stories and proposed responses

Search Add Portlet for Factor Future Contingency. In Factor Analysis, review the Harbour Energy factors, then select LH and open Workshop Future Stories. Define connection timing and customer demand as the two dimensions, with names and descriptions for all four combinations.

Open Workshop Planned Actions. Compare a staged pilot response against each story and link useful metrics under Quadrant Associations. In Capacity squeeze, rising lead time and enquiries are associated with protecting delivery capacity. Keep those external conditions distinct from controllable preparation work.

Future Stories: define the two extremes, name each combination and explain what it means for the pilot.

Carry the measures and review rules into the model

Measures of Performance brings together Pilot readiness (%) and Partner preparation (%) from the factor groups. Use these to ask what evidence of readiness would be needed before a proposed action becomes a commitment.

Keep the response, the relevant story and its review rules alongside the dependency model. A connection estimate of twelve months is a fictional review threshold in this example. It is not a scheduled task, a probability or a reason to approve work automatically.

Measures of Performance aggregates measures entered against factor groups. No causal-loop portlet is selected in this example.

Model what the response depends on

Add Conceptual Map and create a separate model for the response. Give it concepts for the pilot, delivery capability, partner readiness, connection timing and a review point.

Ask your MCP assistant to analyse the scenario notes, propose the dependencies and record source references in concept notes. Review the proposal before it writes the model with the native Conceptual Map tools.

Plan the preparation in Gantt Chart

Search for Gantt Chart and create a separate plan. Use Roadmap to explain discovery, preparation and review phases; switch to Tasks or Timeline for detailed scheduling.

List the preparation activities the team has actually agreed to undertake.
Create phase rows, place work packages beneath them, and assign work_stream values such as Research, Design, Delivery and Governance.
Assign owners and prerequisites. Keep the scenario review rules in phase assumptions or supporting notes.
Use Timeline to check the schedule, then Roadmap to review phases above the work streams and their work packages. Export the phase graphic if needed.

Use tracking to revisit all three portlets

Open Operational Tracking in The Future Matrix and capture the selected values. The demo includes two manually entered samples: lead time rises from 9 to 14 months and enquiries from 120 to 180, while pilot readiness rises from 60% to 75%. Weekly is a cadence label, not an automated data feed.

Open Future Tragectory Workshop to read the evidence behind the story affinities. Capacity squeeze matches the configured direction and targets in this sample. Pilot readiness is tracked but is not linked into the affinity calculation. The percentages summarise rule matches, not forecast probabilities.

Review the proposed response in Planned Actions, then check whether the conceptual dependencies and Gantt work packages still fit. Update each affected portlet after agreement; this workflow does not automatically create or reschedule Gantt tasks.

The Conceptual Map and Roadmap screenshots below are separate onboarding samples that illustrate the modelling and planning pattern. The downloadable Future Matrix state and Gantt import are independent examples, not a linked energy programme.

Future trajectory explains the captured values, directions and targets behind each affinity score. Affinity is a rule-match summary, not a probability.

Conceptual Map provides the modelling pattern. This screenshot is the onboarding example; create a separate energy model for the exercise.

The onboarding Roadmap illustrates the phase view. Use a separate energy plan when following this workflow.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Modules together: interview evidence → maps → Gantt Roadmap

Tue, 03 Nov 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Lemon Slice Hosted Avatar Test
Search: Lemon Slice Hosted Avatar Test
Prepare the avatar interviewer, session briefing and transcript processing.
Narrative Mapper
Search: Narrative Mapper
Present findings with evidence, objections, responses and open questions.
Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Combine the Lemon Slice interviewer, Narrative Mapper, Conceptual Map and Gantt Chart to move from evidence to reviewed delivery work.

Use a different module for each review task: collect the conversation, inspect the argument, check the dependencies and plan the agreed work. Keep the source evidence available as you move between them.

Start with the interview briefing

Add the Lemon Slice Hosted Avatar Test module and choose its Interviewer agent. Prepare the briefing and processing prompt as described in the interviewer post. After a real session, review the transcript and generated notes before handing them to an assistant.

For this exercise, use workshop-evidence.txt instead. It is explicitly scripted input, with N01–N05 references, so you can reproduce the later steps without starting an avatar session.

Review the findings in two modules

Ask your MCP assistant to propose findings and keep the note IDs. Use Narrative Mapper for the case, supporting evidence and objections. Use Conceptual Map for the capability, ownership and approval dependencies.

Before revising the Conceptual Map or Gantt plan, ask the assistant to discover its native graph schema and query the saved records with the returned snapshot. The current demo queries read six concept connections and six Gantt work packages. Review these saved results alongside the evidence notes; the modules still need deliberate hand-offs.

Keep observations, proposals and open questions distinct in the assistant’s initial analysis.
Create a new Narrative Mapper portlet and review the pilot proposal with its automation-first objection.
Create a Conceptual Map in a separate portlet and inspect the proposed ownership and unresolved approval authority.
Resolve or assign follow-up for the open questions before turning a proposed change into delivery work.

Put agreed actions into Gantt Chart

Search for Gantt Chart and use Roadmap for the phase discussion. For example, place baseline collection and authority clarification in discovery, prototype review in preparation, and evidence review in the pilot phase.

Use Tasks and Timeline to maintain the individual work, owners and prerequisites. Ask the assistant to prepare a separate draft plan if you want help; review it before using it. The existing demo Roadmap is illustrative, not an automatically generated consequence of an interview.

Keep the hand-offs explicit

Place all the portlets in one workspace and add notes explaining the sequence. After a review, update the source model or plan intentionally. These modules do not automatically synchronise every change into each other.

The maps and Gantt example are available in the demo files. The useful result is that a reviewer can trace an agreed task back to the finding, the proposal and its source note.

The Lemon Slice avatar supplies the conversation view. This screenshot is a short room demonstration; the worked mapping exercise uses scripted notes.

Conceptual Map shows the dependencies and unresolved responsibilities behind the proposal.

Gantt Chart’s Roadmap view is used to review phases, objectives and assumptions before editing task detail.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Conceptual Map: show the dependencies found by an MCP assistant

Tue, 03 Nov 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Maintain Markdown
Search: Maintain Markdown
Keep source notes and evidence IDs available to the assistant and reviewers.

Model a service, its capability, proposed ownership and an unresolved approval dependency using native Conceptual Map tools.

Use Conceptual Map when you want to inspect what the assistant believes the concepts and dependencies are. It is a different view of the same notes used in the Narrative Mapper example.

Add an empty Conceptual Map portlet

Search Add Portlet for Conceptual Map and create a separate portlet for the exercise. Tell the assistant its portlet ID and the permitted source notes. The native MCP tools work on an existing portlet.

Use the source notes to agree six starting concepts: customer outcome, welcome service, eligibility check, named case owner, exception authority and pilot review. Record uncertainty in the notes rather than creating extra certainty through a diagram.

Ask for concepts and relationships

The assistant should propose the model, check it with you and use the current revision for each native write.

Try this prompt in your MCP assistant

Read N01–N05. In my empty Conceptual Map portlet, model the outcome, service, eligibility capability, proposed case owner, unresolved approval authority and pilot review. Cite note IDs in concept notes. Create connectors only where the relationship is justified. Read the saved model back and list the questions that still need a person to answer.

Call conceptual_map_list_models and use the returned revision for conceptual_map_create_model.
Create concepts with conceptual_map_create_concept, including source references in notes.
Create connections with conceptual_map_create_relationship. Pass the newest returned clientRevision on every edit.
Read the result with conceptual_map_get_model, then open the model in CEP and inspect its notes.

Check the interpretation in the map

The saved example has six concepts and six connectors. Select Named case owner: its note says it is a proposal from N03, not an appointment. Select Exception authority: its note records an unresolved approval question from N03–N04.

Hide the panel and choose Fit model to screen to review the structure. Reopen the notes when a label is ambiguous. A connector is a modelling choice to check; a line on the canvas does not establish a causal claim.

Query the saved connections through MCP

The new native graph tools let an assistant inspect this saved model before editing it. Call get_graph_query_capabilities, find the portlet with list_graph_portlets, then get_graph_portlet_schema and query_graph_portlet with the returned snapshot.

The query below returns the six connector labels and endpoints in the screenshot. For example, Named case owner → proposed ownership → Welcome service remains a proposal, while Exception authority → approval dependency → Eligibility check identifies the unresolved responsibility.

The query projection includes every saved canvas in the portlet. Use model_id to focus a particular canvas when needed. Keep evidence IDs in concept notes and use conceptual_map_get_model to inspect the full native model; later edits still require current clientRevision values.

Example Cypher-style query

MATCH (a:Concept)-[r]->(b:Concept)
RETURN a.label AS from_concept,
       r.properties.metadata.label AS relationship,
       b.label AS to_concept
LIMIT 25

From concept	Relationship	To concept
Welcome service	supports	Confident first week
Eligibility check	enables	Welcome service
Named case owner	proposed ownership	Welcome service
Exception authority	approval dependency	Eligibility check
Pilot review	tests proposal	Named case owner
Pilot review	checks authority	Exception authority

Verified native MCP query results displayed in the demo’s Maintain Markdown portlet. This is a CEP view of the saved result, not a branded assistant transcript.

Use native tools for later revisions

If a reviewer clarifies who can approve an exception, ask the assistant to read the current model and propose the specific note and relationship changes. On a revision conflict, reread and reconcile before trying again.

The downloadable JSON is a native model read-back for inspection. It is not a generic Load Portlet from File package. Use Conceptual Map’s native MCP operations to recreate or change the model.

The native model and the new graph query were both checked against MCP server 1.2.0: six concepts and six connectors. The downloadable native model read-back and existing canvas screenshot remain valid.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Narrative Mapper: turn MCP analysis into an evidence-led argument

Tue, 03 Nov 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Narrative Mapper
Search: Narrative Mapper
Present findings with evidence, objections, responses and open questions.
Maintain Markdown
Search: Maintain Markdown
Keep source notes and evidence IDs available to the assistant and reviewers.

Use an MCP assistant to organise findings, supporting notes, an objection and open questions into a map you can navigate.

Narrative Mapper is useful when you want to review the reasoning behind an assistant’s recommendation. The map can keep the supporting evidence, alternatives and unresolved questions beside the proposed action.

Add Narrative Mapper and prepare the notes

Search Add Portlet for Narrative Mapper. Use Maintain Markdown for a source document if you want the assistant to read the notes from CEP. The sample source uses N01–N05 so each finding can point to a particular note.

The evidence reports repeated eligibility details and an unclear owner for the next reply. A named case owner is proposed. Automation is raised as an alternative, and approval authority remains unresolved.

Ask the assistant for an argument map

In your MCP assistant, use the prompt below after granting access to the source. Let it show you the proposed findings before it creates the new portlet.

The refreshed MCP connection keeps this JSON guide, create and read-back workflow. For a companion Conceptual Map or Gantt analysis, discover its native graph schema and query the saved data before proposing a map revision.

Try this prompt in your MCP assistant

Read the workshop evidence and cite N01–N05. In Narrative Mapper, create a new map centred on “Trial a named case owner”. Add two supporting findings, the automation-first objection, a response about decision rights, the unresolved approval question and the baseline/review condition. Keep the proposal provisional. Read the saved map back.

Discover the supported imports and obtain get_load_portlet_from_file_json_guide for narrative-mapper.
Read the source notes, then check the proposed node titles and evidence references in the assistant.
Use load_portlet_from_json with a top-level map containing nodes, edges and connector types, and conflictAction create.
Use read_portlet_content to verify the saved map. Add it to the relevant workspace if needed.

Review the result in Narrative Mapper

The sample has seven nodes and six links. Use Auto arrange if the imported layout needs tidying, then open Landscape in Full Screen to review the whole argument. Select the pilot proposal and follow its evidence and objection branches; use path-focused navigation when discussing one route.

The “Customers repeat information” node cites N01. “Next reply has no agreed owner” cites N02. “Why not automate first?” is an objection, while “Who can approve an exception?” remains a question. Check those distinctions in the node summaries rather than treating every node as an established finding.

Try a different question

Ask the assistant to show a different option, such as clarifying approval authority before changing case ownership. Have it explain which notes support the alternative and which evidence is still missing.

Download the native Narrative Mapper import example to inspect or load a separate copy. Its ID is cepblog-narrative-copy. The client record lists the successful MCP calls and the read-back counts.

The current-server review read the existing narrative back as seven nodes and six links. Its screenshot still shows that result, so the evidence map has been retained.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Run an interview with the Lemon Slice avatar

Tue, 03 Nov 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Lemon Slice Hosted Avatar Test
Search: Lemon Slice Hosted Avatar Test
Prepare the avatar interviewer, session briefing and transcript processing.

Open the avatar in CEP’s hosted room, guide the interview with a briefing and review the captured discussion afterwards.

The Lemon Slice interviewer puts a talking avatar in the room with the participant. Prepare an interview briefing to guide the conversation, then use the transcript-processing prompt to organise the findings afterwards.

Meet the avatar in the room

Create Hosted Room opens the embedded room beneath the setup controls. This is the interview view: the participant sees and speaks with the avatar while the briefing supplies the purpose, questions and finishing condition.

Use Leave Embedded Room when the session is complete. The Discussion Capture area provides the captured text for review and post-processing. Check the transcript before treating a statement as a finding.

For an interactive interview, enable only the microphone and camera you intend to use when the browser asks for device access. The screenshot demonstration joined with both devices off.

Prepare the briefing document

Use an Interview Briefing heading in the knowledge document. Include why the interview is being conducted, the questions it should explore and the point at which it should finish.

The Harbour Services example asks about a customer’s first week, hand-offs, repeated questions, exception handling and ownership. It closes with a recap and an opportunity for the participant to correct it. Download the briefing below and adapt those sections to your own purpose.

Load the brief and processing prompt

Use a portlet you have permission to configure. The setup image below shows the fictional briefing and processing prompt; the room image above shows the avatar.

Under Configure Avatar Experience, choose Interviewer from Known Agent, or use the agent ID agreed for your environment.
Under Session Knowledge Base, choose the briefing document and select Upload as Knowledge Base.
Check that the status names the document and says it will be sent when the next room is ready.
Enter the Post-processing prompt describing how you want the completed transcript organised.
Save the agent and processing settings. When ready for the intended session, use Create Hosted Room. Send to Active Room is available when adding knowledge to an existing room.

Example: ask for reviewable findings

The example processing prompt requests the onboarding journey, hand-offs, missing information, exceptions, ownership, pilot ideas and open questions. It asks for supporting quotes and separates observations, assumptions and proposals.

Only include an owner if the transcript names one. A suggested action should remain a proposal until it is agreed. This makes the output easier to compare with the service model and Gantt Roadmap during the follow-up review.

Finish the session and review its output

Ask the participant to use the room’s leave control when finished so transcript processing can run. Review the captured discussion and processed output before moving findings into the shared model or plan.

Completed artifacts can include the transcript, processing prompt and output, room status and recording metadata. A recording file depends on provider availability and the configured recording integration. The briefing document is held in the current browser session; after reloading the page, upload it again before a later room.

The downloads provide the fictional brief and processing prompt. The mapping walkthrough uses separately scripted workshop notes; it does not present those notes as a transcript from this avatar.

Prepare the briefing and processing prompt before opening the avatar room.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

MCP: analyse notes and show the findings in CEP modules

Tue, 03 Nov 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Maintain Markdown
Search: Maintain Markdown
Keep source notes and evidence IDs available to the assistant and reviewers.
Narrative Mapper
Search: Narrative Mapper
Present findings with evidence, objections, responses and open questions.
Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.
Common Graph
Search: Common Graph
Review published source contributions and provenance together.

Analyse notes, query saved native graphs and review the findings in Narrative Mapper and Conceptual Map.

An MCP assistant can read your permitted CEP content, analyse it and put the findings into a module you can inspect. The assistant does the analysis; CEP’s MCP tools read and write the working content.

Choose the module for the result

Use Narrative Mapper when the result is an argument: a finding, the evidence for it, an objection and a response. Use Conceptual Map when the result is a model of concepts, responsibilities or dependencies. Maintain Markdown can hold the source notes and evidence IDs.

In the example, the same five scripted workshop notes produce two different views. Narrative Mapper shows the case for a named-owner pilot and the automation-first objection. Conceptual Map shows the service, eligibility capability, proposed case owner, unresolved exception authority and review.

Give your MCP assistant an analysis brief

Use an authorised MCP client. Claude Code can connect through CEP’s HTTP MCP endpoint; Claude Desktop and Cowork use the configured local stdio bridge. The refreshed bridge and HTTP server share the same tool catalogue and native dispatch. Reconnect or refresh the client’s tools to discover the graph-query and Common Graph commands.

Keep the source and destination explicit. Ask the assistant to distinguish observations, proposals and open questions, and to retain evidence references.

Try this prompt in your MCP assistant

Read the Harbour Services workshop evidence. Identify the main findings, alternatives and unresolved questions. Cite the note IDs. Create a new Narrative Mapper portlet showing the argument and objections, then use the existing empty Conceptual Map portlet for dependencies and responsibilities. Read both results back. Do not replace an existing map or turn a proposal into an agreed decision.

Read, analyse, create and check

The accompanying examples were published and read back by a local HTTP MCP client. The analysis was prepared from fictional notes in this chat; the record is not a screenshot or transcript of Claude Code or another branded assistant.

Discover the available tools and read the source with read_portlet_content when supported by the connection.
Review the proposed findings and evidence IDs in the assistant before creating the visual outputs.
For Narrative Mapper, get its JSON guide and use load_portlet_from_json with conflictAction create. The runtime map is a top-level map object.
For Conceptual Map, first add an empty portlet. Use conceptual_map_list_models and the native conceptual_map_create_* tools with current revisions.
Read the saved narrative and conceptual model back, then open them in CEP. Check the evidence, connection direction and unresolved questions.

Query the saved graph before revising it

Start with get_graph_query_capabilities and list_graph_portlets, then use get_graph_portlet_schema for the graph you can access. Pass its snapshot as expectedSnapshot to query_graph_portlet. This reads the saved native graph; browser filters and unsaved edits are not the query’s input.

For the Gantt demo, the query below returns three Phase records, six Work Package records and four Work Stream records, alongside its project and owners. The Conceptual Map query in the download returns all six saved connectors. These reads give the assistant a concrete starting point before it proposes changes.

Queries use a bounded, read-only Cypher-style subset over one permitted graph at a time. Check the advertised syntax and limits. Keep native module tools and their current revisions for edits; query results do not change the graph.

Example Cypher-style query

MATCH (n)
RETURN n.type AS node_type, count(*) AS records
ORDER BY node_type

Saved native graph	Verified result
Conceptual Map	6 concepts and 6 connectors
Gantt Chart	3 phases, 6 work packages and 4 work streams
Common Graph	38 source records from 4 published contributions

Use the two worked examples

The next examples provide a prompt, sample findings and the exact module names to search for. One covers Narrative Mapper and the other Conceptual Map. Both include saved outputs from the same fictional source notes.

A create operation, a model edit and publication to Common Graph have different permission and sharing implications. The example creates private drafts; it does not publish them to a broader audience.

The graph-query download adds the exact queries, scalar results and a Common Graph email-matching preview checked against MCP server 1.2.0. Use it alongside the original map-creation receipt; it records a separate verification run.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Using Gantt’s Roadmap view to review a pilot

Wed, 28 Oct 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Set up phases and work packages in Gantt, then read the same packages across work streams in Roadmap.

Timeline and Roadmap show the same plan in different ways. This fictional pilot has three phases, six work packages and four work streams. Start with the phase hierarchy in Gantt, then use Roadmap to see how the packages run through Delivery, Design, Governance and Research.

Set up phases and work packages in Gantt

A phase groups a stage of the engagement and explains its purpose. A work package is a defined piece of work within that phase. A work stream groups related packages across phases.

In the Gantt table, mark the three parent rows as Phase. Indent the six delivery items beneath the appropriate phase and mark each one as Work package. The screenshot shows those flags alongside the schedule and prerequisite links.

Search Add Portlet for Gantt Chart, then open Timeline on the example plan.
Add a root-level row for each phase and tick Phase. Add or indent its child rows beneath it, then tick Work package for the items you want to show on the Roadmap.
Enter a Work stream for every work package. The example uses Delivery, Design, Governance and Research; use consistent names for packages that belong in the same row.
Check owners, durations, start modes and prerequisites. Use P to anchor the first package to its parent phase, and X where the next package should follow its prerequisite. Zoom or scroll the timeline to review the schedule.

Gantt Timeline: the highlighted parent rows are phases, and all six child rows are marked as work packages. The Work stream column supplies the Roadmap grouping. Select the image to inspect the full-size table and chart.

Switch to Roadmap: phases above, work streams below

Select Roadmap. The phase columns show the engagement flow, dates, owners, descriptions and objectives. Below them, the Work streams section places the same work packages on named rows.

Delivery contains Build the pilot experience in Design & prepare and Launch a controlled pilot in Pilot & learn. Governance contains the service-owner review and the evidence review. Design and Research show the earlier dependency-mapping and interview packages.

A package appears in this section when it is marked as Work package, has a Work stream, and falls within the displayed range. If a box is missing, check those fields in Tasks or Timeline before changing the Roadmap. A work stream is a row across the engagement, not another phase.

Select Roadmap beside Timeline and Tasks.
Review the phase columns, then scroll down to see all four work-stream rows.
Trace a package from the table into its work-stream row. Confirm that its position agrees with the phase and schedule you intended.
Use Scale to switch between Phases fixed and Time fixed. Phases fixed gives phase columns equal width; use Time fixed when comparing elapsed time.

The same plan in Roadmap: three phase columns above four work streams. All six work packages are visible, including two Delivery packages and two Governance reviews. Select the image for the full-size view.

Trace the six work packages between views

Use the package title to follow the same item between Timeline and Roadmap. Its parent phase and its work stream are separate assignments: one places it in the engagement structure, the other places it in a work-stream row.

Phase	Work package	Work stream
Discover & align	Interview service team	Research
Discover & align	Map onboarding dependencies	Design
Design & prepare	Build the pilot experience	Delivery
Design & prepare	Review with service owners	Governance
Pilot & learn	Launch a controlled pilot	Delivery
Pilot & learn	Review evidence & next steps	Governance

Review objectives, assumptions and prerequisites

Design & prepare describes building a small working experience and validating it with service owners. Its objectives are a reviewable prototype, confirmed exception handling and agreed learning measures. Compare those objectives with its two work packages.

The service-owner review depends on building the pilot experience, and launch depends on that review. The phase assumptions include a service owner being available for weekly review and the pilot retaining a small scope. If either changes, review the work and schedule as well as the phase wording.

Use a phase’s Edit control to maintain its description and objectives.
Scroll to Phase assumptions and review the conditions behind the plan.
Switch back to Tasks or Timeline when an owner, duration or prerequisite needs changing.

Try the sample and export the Roadmap

The downloadable JSON uses CEP’s Gantt Load Portlet from File format and the separate copy ID cepblog-delivery-copy. It includes the three phases, all six work-package flags, their work streams and the parent/prerequisite start modes used in these screenshots.

Choose Export in Roadmap to download the SVG phase graphic for a review. The refreshed native export is included below. If shared edits conflict, keep or download your draft before reloading the latest saved plan.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Example: mapping service continuity dependencies

Wed, 14 Oct 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Build a small Conceptual Map linking a service outcome, dependencies and response options, then use it to prepare a tabletop exercise.

The Coastal Futures example is a six-concept map for discussing service continuity. Use it to practise connecting an outcome to the assumptions and dependencies behind a proposed response.

Read the example model

Service continuity is the outcome. Transport disruption threatens it, while a supplier dependency constrains it. A remote service option supports continuity, but depends on partner coordination. A tabletop exercise tests the coordination and examines the supplier dependency.

The screenshot shows these connections in Conceptual Map. Select concepts and inspect their notes when you need the explanation behind a short title.

Build a similar map

Choose a service and keep the first version small enough to review with the people who understand it.

Open a Conceptual Map portlet and create a new model for the discussion.
Use Add concept to record the service outcome, two dependencies, a response option, coordination work and a proposed exercise.
Add notes stating the assumption behind each concept.
Use the relationship controls to connect the concepts. Check the direction of each connector with the group.
Hide the editing panel and choose Fit model to screen for the review.

Use the model to prepare an exercise

For the remote service option, ask what must already be in place. The example points to partner coordination. Add the questions that the exercise needs to test: who participates, what information is required and which dependencies are still uncertain?

Put the agreed preparation work into a Gantt portlet in the same workspace. Use Roadmap for the exercise’s broad phases and Tasks for the individual preparation and review activities.

Update the model after the discussion

Return to the notes and relationships after the exercise. Update assumptions that were contradicted, add missing dependencies and record follow-up work with the appropriate owner.

This fictional map is a workshop example, not an approved continuity or emergency response plan. Its purpose is to make the dependencies and questions available for review by the responsible team.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Example: comparing energy transition scenarios

Wed, 30 Sep 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Factor Future Contingency
Search: Factor Future Contingency
Develop factors and future stories, prepare responses, then review measures and captured signals in The Future Matrix.

Work through four future stories, proposed responses, performance measures and captured signals in the Harbour Energy example.

Harbour Energy is considering a staged clean-energy service pilot. This fictional example uses all six Future Matrix sections to move from uncertainty to reviewable responses, then check those responses against sample signals.

The Future Matrix was created by Julio Graham, who operates Olive Professional Services.

Review the six factor groups

Open Factor Analysis and look at grid connection delays, customer demand, delivery capability, partner readiness, office energy waste and internal reporting habits. The demo ratings are discussion assumptions.

Delivery capability and partner readiness sit in high control/high impact. Connection delays and customer demand sit in low control/high impact. Compare the reasons for those placements before using them to guide the next discussion.

Use the low-control/high-impact factors

The two LH factors provide the dimensions for this example’s Future Stories.

Choose Workshop Factor Analysis to review the notes, groups and matrix positions.
Exit the workshop and select LH in the quadrant filter.
Open Workshop Future Stories and inspect the selected factor groups for the two dimensions.
Review the extremes: fast connection versus extended delays, and steady versus accelerating demand.
Read each story’s name and description, then check that it corresponds to its combination of conditions.

Future Stories: define the two extremes, name each combination and explain what it means for the pilot.

Compare the stories and prepare a response

Open Workshop Planned Actions and compare the responses below. The same two factors define all four stories. A response should make sense for its combination of conditions; it is not an automatically approved delivery task.

Future story	Conditions	Proposed response
Demand takes off (HL)	Accelerating demand + fast connection	Prepare staged expansion after reviewing pilot evidence.
Capacity squeeze (HH)	Accelerating demand + extended delays	Protect delivery capacity and review staged commitments.
Steady transition (LL)	Steady demand + fast connection	Continue a small learning pilot.
Demand waits (LH)	Steady demand + extended delays	Keep commitments reversible and revisit timing.

Planned Actions: the fictional example links two metrics to each story, then records responses and review thresholds.

Turn an assumption into a review rule

In Quadrant Associations, inspect Capacity squeeze. Connection lead time is Going up with a target of 12 months; qualified enquiries are Going up with a target of 150 per month. The individual metric actions below provide prompts to review pilot commitments and check delivery capacity.

For the contrasting fast-connection stories, lead time is Going down towards 6 months. Steady-demand stories use enquiries Going down towards 100. These are invented thresholds for trying the controls, not energy-market benchmarks. Partner capacity review is available as an event but has not been recorded as having occurred.

Keep controllable preparation visible with measures

The Measures of Performance section lists Pilot readiness (%) and Partner preparation (%), entered against the corresponding factor groups. These describe preparation that the team can work on while external conditions remain uncertain.

Open Operational Tracking and select pilot readiness alongside connection lead time and enquiries. Partner preparation is available but not selected. Readiness is tracked in this example without being linked to a story, so it does not contribute to the displayed affinity scores.

Measures of Performance aggregates measures entered against factor groups. No causal-loop portlet is selected in this example.

Capture two sets of sample values

The first demonstration capture uses lead time 9 months, 120 enquiries and 60% pilot readiness. The second uses 14 months, 180 enquiries and 75% readiness. Both were entered during the screenshot session; they do not represent two weeks of observed performance.

In Operational Tracking, enter each set and choose Capture Snapshot. The history shows the timestamp, interval label and values. Weekly records the intended review cadence; values are entered manually. Two captures let the trajectory view compare direction as well as the latest value.

Operational Tracking: two manually entered demonstration captures. Weekly is the selected review cadence; these values are fictional.

Read the trajectory before changing the response

Open Future Tragectory Workshop. Capacity squeeze shows 100% affinity because both linked metrics have evidence, are moving in the specified direction and meet their configured targets. Openly inspect those rules with the workshop participants.

The score is a rule-match summary, not a 100% chance of that future. The other stories retain partial scores because some rule components still match. Use the explanation to decide whether a response needs review, then record any agreed change in Planned Actions.

Download future-matrix.json to inspect the complete fictional state, including stories, rules, group measures and the two captures. It is a state snapshot; check the module’s import workflow and use a separate example portlet before loading it.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Example: tracing an onboarding hand-off in Graph Explorer

Wed, 09 Sep 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Graph Explorer
Search: Graph Explorer
Inspect domain entities, relationships and their properties.
Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Use search, selection and type filters to follow an outcome through its service, capabilities and team ownership.

The Harbour Services onboarding graph has eight nodes and eight relationships. It is a small example for practising graph navigation before using a larger model.

Start with the question

The example question is: which part of onboarding contributes to repeated customer hand-offs? The graph contains Confident first week as an outcome, Welcome & orientation as a service, and capabilities for confirming eligibility and resolving an exception.

Client Services owns the two capabilities. Customer context informs the eligibility check, while the 90-day onboarding pilot is linked to the welcome service. Repeated hand-offs is recorded as a risk to the outcome.

Follow the relationships

Open the example in Graph Explorer, or use a graph you have permission to inspect. The downloadable service.json contains the fictional graph data for reference.

Search for Welcome & orientation using Search labels and properties.
Select the service node and review its properties and relationships in the Inspector.
Clear the search and follow the ENABLES relationships from the capability nodes.
Inspect Client Services and its OWNS relationships, then inspect Customer context and the INFORMS relationship.
Use Fit to screen after navigating. Try a node-type filter, then Clear filters to restore the wider view.

Record what you still need to check

For this example, ask whether Client Services can resolve an exception directly or needs another team. If the relationship is uncertain, record the question in the shared model or context notes before treating it as an agreed dependency.

The graph’s first-contact measure is an illustrative target. Use the Inspector to distinguish a target, an observation and a proposed response. A node’s presence in the graph does not establish that the service has achieved its target.

Carry an agreed change into the pilot

Once the team agrees a change, add the corresponding work to the pilot plan with an owner and prerequisites. Use Gantt Roadmap to discuss the phase in which it belongs, then Timeline or Tasks for scheduling detail.

If a Common Graph already contains a snapshot of the service model, republish when that destination should reflect the revised source. Keep the source model, plan and published snapshot revisions in mind when comparing them.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Publishing portlet data to a Common Graph

Wed, 19 Aug 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Common Graph
Search: Common Graph
Review published source contributions and provenance together.
Graph Explorer
Search: Graph Explorer
Inspect domain entities, relationships and their properties.

Choose a destination, review a source snapshot and inspect the resulting graph. Includes a simple field-comparison example.

Common Graph stores published snapshots from source portlets. Use it when you need to inspect several sources together while retaining their source records and provenance.

Choose the appropriate graph tool

Conceptual Map is for creating and arranging a conceptual model. Graph Explorer and Graph Visualiser help inspect graph data. Portlet Graph shows connections between portlets and their supporting modules or files. A Common Graph portlet holds a destination dataset of published contributions.

You need write access to the source and destination, plus Graph Gateway permission, to publish. An observer can inspect a permitted destination without publishing changes.

Publish a source contribution

The demo destination contains service, directory, contact and delivery-plan snapshots. To publish another supported source, use its Data Graph panel.

Open the source portlet and expand Data Graph.
Choose Semantic Graph when it is available and you want domain entities. Storage Graph describes the module’s stored structure.
Select the intended writable Common Graph destination. Check the destination name and audience.
Review the preview and confirm publication.
Open the destination and check Published Sources, the counts and the source assertions on a selected record.

Example: compare Employee and Person records

In Unification → Types, align the directory’s Employee type and the contacts’ Person type with the Person definition. Open Fields to inspect examples and field coverage. In Compare, select those two source types and choose Load comparison fields.

Compare employee_email with email. Select Trim whitespace and Ignore letter case, then Run exact-match preview. In the demo, shared distinct keys increase from one to two: Alex Morgan already agrees; Priya Shah’s email agrees after normalisation. One contact has a null email. The two directory records called Sam Lee show why a name alone needs review.

This screenshot uses temporary type selections and comparison settings. No model changes were saved. To keep a reviewed model, use Save changes or configure Matching definition at a selected matrix intersection. Saving definitions and field bindings does not approve or apply identity matches.

The native Common Graph exact-match preview agrees with the MCP result: two candidate pairs after trimming and ignoring case. These remain unapproved suggestions.

Ask an MCP assistant to inspect the same evidence

The assistant can call get_common_graph_unification_inventory and get_common_graph_unification_fields to inspect the published source types and their fields. It can then use preview_common_graph_unification_matches with the current snapshot to reproduce the email comparison. The verified demo returns two candidate pairs marked ready to review; both remain unapproved suggestions.

For an existing saved model, read get_common_graph_unification_configuration and compare_common_graph_saved_matching_definitions. To save a revised model through MCP, retain unedited entries, preview the complete payload and review the additions, changes and removals before saving with the returned preview token and current revision. This example performs reads and a temporary match preview only.

Use get_graph_portlet_schema and query_graph_portlet for bounded queries over the published graph itself. The query below filters n.kind to the quoted string 'source' for source-only counts. Saved workspace matching rules and temporary previews do not rewrite those published records.

Example Cypher-style query

MATCH (n) WHERE n.kind = 'source'
RETURN n.type AS node_type, count(*) AS records
ORDER BY node_type

Refresh the right copy

A contribution is a snapshot. Changing the source does not refresh it automatically. Republish when the destination needs the updated source; this replaces that source’s contribution in that destination.

Graph Explorer also offers live Common Graph sources for temporary overlays. Import Snapshot makes a separate copy. Choose between them according to whether you need to inspect a permitted source temporarily or retain a published copy for the destination audience.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Organising a workspace and editing together

Wed, 22 Jul 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Choose Workspaces on the CEP home page to arrange these portlets together.

Use Cards and Canvas views to arrange the work, then use the collaboration controls in supported modules to edit shared content.

A workspace helps people find the portlets they are using together. Shared editing happens inside the modules that support it. This post covers both parts of preparing a working session.

Arrange the workspace

Cards view is useful when you want a straightforward list of tools and notes. Canvas view lets you position cards and group them in named zones, such as Discovery, Design and Delivery.

Switch the home page to Workspaces view and select the workspace.
Use Cards to review the members and their notes. Use Reorder when the sequence needs changing.
Switch to Canvas to arrange the cards spatially and group related work in zones.
Open each portlet you expect to use in the session and check that the participants have the required access.

Example: a shared service model

In the Harbour Services model, Customer need connects to Welcome service, Eligibility check, Client Services, Delivery pilot and Review evidence. Use that model during a discussion about which capability needs changing and who should review the result.

In Conceptual Map, select a concept to review its title and notes. Use the relationship controls to inspect its connections. Hide the editing panel and choose Fit model to screen when you want to discuss the whole model.

Use the module’s editing indicators

Conceptual Map and Gantt support shared editing. Their live-editing indicators show the connection state and editing activity. In Gantt, people can work on different task fields while changes are shared.

For a first session, have two permitted participants open the same portlet. Make a small agreed edit and check that the other participant sees it. The screenshot shows saved model content; it is not a recording of simultaneous edits.

If an edit conflicts

A conflict means the saved state has changed in a way that needs review. In Gantt, autosave pauses and the draft remains in the tab. Read the conflict message before deciding what to keep.

Download the draft if you need a separate copy before choosing Discard draft and reload latest. Keep the tab open until the changes are saved or the draft has been downloaded. Editing behaviour varies by module, so check the controls in the portlet you are using.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Setting up The Future Matrix for a new workshop

Wed, 17 Jun 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Factor Future Contingency
Search: Factor Future Contingency
Develop factors and future stories, prepare responses, then review measures and captured signals in The Future Matrix.

Set up factors, develop future stories, prepare responses and use measures and tracking to revisit the workshop.

A Future Matrix portlet can hold the whole workshop: Factor Analysis, Future Stories, Planned Actions, Measures of Performance, Future trajectory and Operational Tracking. Here is how the six sections fit together in the fictional Harbour Energy example.

The Future Matrix was created by Julio Graham, who operates Olive Professional Services.

Give the workshop its own context

The module behind The Future Matrix is Factor Future Contingency. A new portlet gives you an independent working instance. Name it for the subject of the workshop so participants can distinguish it from other matrices.

An owner or administrator can maintain the portlet’s configuration markdown. Record the purpose, audience and decision being considered there. Quadrant Guidance sections can supply context-specific guidance for the control and impact combinations.

Search Add Portlet for Factor Future Contingency. Give each workshop a separate portlet so its factors, stories, response rules and captures have their own saved state.

Collect and rate the factors

The Factor Analysis workshop is where you add factors and arrange them. Keep the initial titles short enough to discuss and recognise on the matrix.

Open the portlet and choose Workshop Factor Analysis.
Use Add Factor for an individual item, or Bulk Add for a prepared list.
Rate control and impact separately on the seven-point scales. A rating of four sits on the dimension line.
Use Group Factors for related items. Switch to the matrix to position factor groups by control and impact.
Exit the workshop and use the quadrant filter to review the relevant factor groups.

Factor Analysis is the starting point. Group related factors and explain the control and impact ratings before developing stories.

Example: two different responses

In the demo, Pilot delivery capability has high control and high impact. Grid connection delays has low control and high impact. The first can lead to an agreed preparation task; the second needs discussion of alternative conditions and possible responses.

Ask participants to explain the ratings before moving on. A disagreement about control often points to a different assumption about the organisation’s authority or its dependencies.

Develop the four Future Stories

Select LH, the low-control/high-impact filter, then choose Workshop Future Stories. Place relevant factor groups on the two story axes and enter their extremes. These axes describe alternative conditions; the initial control and impact ratings decide which factors are worth exploring.

The demo uses fast connection versus extended delays, and steady versus accelerating customer demand. Name all four combinations and write a short description of what each would mean for the same pilot. This gives the next discussion a shared reference.

Prepare responses in Planned Actions

Open Workshop Planned Actions for the populated planning workspace. Add events, metrics or measures, link them to a story under Quadrant Associations, and specify the relevant direction and optional target. Record a response for each story and, where useful, an action associated with an individual signal.

For example, the demo associates Capacity squeeze with rising connection lead time and enquiries. Its proposed response is to protect delivery capacity and review staged commitments. An individual review rule uses a connection lead time at or above twelve months. These are fictional discussion thresholds; actions remain proposals for the team to review. The compact dashboard preview is still a placeholder, so use the workshop to inspect the actual entries.

Planned Actions: the fictional example links two metrics to each story, then records responses and review thresholds.

Define Measures of Performance

In Factor Analysis, open Group Factors and add measures to the relevant group. Pilot delivery capability has Pilot readiness (%); Partner readiness has Partner preparation (%). The Measures of Performance section brings these together, and they also become available in Planned Actions and Operational Tracking.

The section also offers a Causal Loop Diagrams portlet selector and Send Measures as Nodes. If using that hand-off, choose an appropriate portlet you can edit and check the receiving model. This demo leaves the selector empty and does not demonstrate that transfer.

Measures of Performance aggregates measures entered against factor groups. No causal-loop portlet is selected in this example.

Capture values, then review the future trajectory

Open Operational Tracking, choose the metrics to monitor and set the capture interval. Enter the current values and choose Capture Snapshot. In this example, connection lead time, enquiries and pilot readiness are selected. Captures are manual; choosing Weekly does not connect a data feed or start an automatic capture schedule.

Open Future Tragectory Workshop — the current button uses that spelling — to inspect how the latest captured signals match each story. The two demo captures provide a change in direction as well as current values. Read the explanation behind each affinity score; a high percentage is not a forecast or likelihood.

Revisit the planned response with participants before changing commitments. Export the JSON state for reference when needed.

Operational Tracking: two manually entered demonstration captures. Weekly is the selected review cadence; these values are fictional.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Sharing a portlet: owners, participants and observers

Wed, 20 May 2026 00:00:00 +0000

Built-in CEP controls

Portlet Options → Share Access is a built-in platform control; you do not need to add a module to change sharing.

Choose who can edit, who can inspect and who maintains sharing. Includes an example arrangement for a service-design workshop.

When someone joins an existing piece of work, check what they need to do in each portlet. Viewing a model, editing it and managing its sharing are separate responsibilities.

The participation options

An owner maintains a portlet and its sharing. Full access lets a participant edit the content. Observer access lets someone inspect supported views without changing saved content. Administrators manage platform settings and permissions.

Your organisation may use its own role names. CEP supports access assigned through roles and to individual users, so these participation patterns do not require four fixed organisation-wide roles.

Review sharing on an owned portlet

If you own the portlet, use its management control on the home page. If you do not have that control, ask the owner or administrator to make the change.

Find the portlet and open Manage owned portlet.
Review Share Access, including any role assignments and individual user assignments.
Assign the access needed for the work: full access for editing, or observer access for inspection. Leave public access off unless a public audience is intended.
Save the settings. Ask the participant to open the portlet from their own account and confirm that the available controls match their role.

Example: designers and a sponsor

For the Harbour Services workshop, the service designers need to change the shared model. The sponsor needs to read it and discuss assumptions. Give the designers full access and the sponsor observer access, while the portlet owner maintains sharing.

A workspace can collect the model and pilot plan, but both portlets still have their own access rules. Check both when adding a new participant. The diagram in the screenshot is an explanatory model, not a live access administration screen.

Remember the audience of a graph snapshot

Publishing to a Common Graph shares a snapshot with that graph’s audience. Its readers may not have access to the original source portlet. Review the destination and preview before publishing.

If source access is later removed, an already published contribution remains in the destination until it is removed or updated there. Check the published copies as well as the source when changing the intended audience.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.

Modules, portlets and workspaces: a quick refresher

Wed, 08 Apr 2026 00:00:00 +0000

Try the modules in this post

Home → Add Portlet → Search modules

Maintain Markdown
Search: Maintain Markdown
Keep source notes and evidence IDs available to the assistant and reviewers.
Conceptual Map
Search: Conceptual Map
Review concepts, dependencies, responsibilities and unresolved relationships.
Gantt Chart
Search: Gantt Chart
Plan tasks and review phases in Roadmap.

Workspaces and Add Portlet are built into the CEP home page. The modules below are the tools used in the example.

How the three parts fit together, and how to organise a small piece of work without creating duplicate tools.

If you are deciding where to put a new plan or model, it helps to distinguish the module, the portlet and the workspace. Here is how we use them in the examples on this blog.

The Future Matrix was created by Julio Graham, who operates Olive Professional Services.

Which part are you working with?

A module is a type of tool, such as Gantt, Conceptual Map or The Future Matrix. A portlet is an instance of that tool with its own title, configuration and working content. A workspace is a collection of portlets that you want to use together.

For example, Harbour Services · 90-day pilot is a Gantt portlet. Another team can use a separate Gantt portlet for its own plan. Both use the same module, while keeping their content separate.

Set up a small workspace

Start by checking whether the portlets you need already exist. Reusing the right portlet keeps everyone working on the same saved content. Creating a new portlet is useful when the work needs its own data or audience.

On the CEP home page, switch to Workspaces view and choose New Workspace, or use Add Workspace.
Give the workspace a name that describes the work, such as Onboarding pilot.
Add the relevant portlets to the workspace. Use Add Portlet to create a new tool instance when you have permission.
Add a short note to explain what each portlet is for. Open the cards and check that they contain the intended model or plan.

Example: the onboarding pilot

The demo workspace keeps a context note, a shared service model, an onboarding graph and a Gantt plan together. Use the context note to record the question being investigated. Use the model for the service relationships, and the plan for tasks, owners and dependencies.

Those portlets do different jobs. You can open the shared model during a workshop and return to the plan when agreeing the follow-up tasks. You do not need a new workspace for every meeting.

Check access separately

Adding a portlet to a workspace does not grant access to its content. If someone can see a card but cannot open the portlet, ask its owner to check sharing. The next post explains the participation and access options.

The screenshots use the private CEP Blog · Field Notes workspace. Use the same arrangement with your own permitted portlets, or follow the downloadable examples where provided.

Editorial retrospective; archive dates are not release dates. Screenshots show the November 2026 fictional demo.