Ba Concept Model

BA Concept Model Skill

Purpose

Produce a rigorous Business Concept Model — a structured taxonomy of the core business objects a domain manages — from any input. The Concept Model is the semantic backbone of the business architecture: it names and defines the things the organisation cares about, classifies their relationships, and cross-validates the Capability Map by ensuring every capability is grounded in a named object and every object has at least one corresponding capability.

A Concept Model is not a data model. It does not define tables, attributes, or database schema. It defines the business vocabulary — the objects that appear in business conversations, policies, contracts, and decisions.

What a Business Object Is (and Isn't)

Examples by domain:

• Rental property management: Property, Booking, Guest, Tenancy, Maintenance Request
• Financial services: Credit Application, Counterparty, Facility, Collateral, Payment
• Insurance: Policy, Claim, Premium, Insured Party, Risk Assessment
• Retail: Product, Order, Customer, Inventory, Supplier

Object Classification — Choosing a Root Hierarchy

Before classifying objects, present the practitioner with two options. This is Classification Checkpoint 0 — it must happen before any objects are typed.

Classification Checkpoint 0 — Present the hierarchy choice

Present this explanation and options inline:

Choosing a classification hierarchy

Every object in the Concept Model needs a root type — a category that tells us what kind of thing it is. Two approaches are available:

---

Option A — Capsicum Triad: Party / Record / Resource

A principled three-type reduction grounded in the Capsicum Framework, consistent with ideas from REA (Resources, Events, Agents — McCarthy 1982) and Bunge's ontology for information systems. Every business object is one of:

Type	Definition	Instinct test
Party	A person or organisation that acts, consents, or is held accountable	"Who?"
Record	Something that documents the state of the world — created when things happen	"What was created to capture this?"
Resource	Something of value that is transacted, consumed, or exchanged between parties	"What is actually changing hands?"

The key clarifying question the triad forces: "What is the Resource in this interaction?" — i.e. what is the object of the transaction, as opposed to the Party who is its subject. This is often the hardest and most clarifying question in business modelling.

Examples for a rental property platform:

• Party — Guest, Owner, Contractor, Tenant
• Resource — Property, Booking, Tenancy (the things being transacted or consumed)
• Record — Financial Report, Maintenance Request, Guest Review, Compliance Obligation (the things created to document what happened)

Why Resource, not Product or Asset? "Product" implies physical goods. "Asset" implies ownership and balance-sheet thinking. "Resource" is deliberately neutral — it covers physical things, services, rights, time, and information equally, which is what makes it work across domains as different as healthcare, finance, and property management.

---

Option B — Custom hierarchy

Define root types that fit this domain naturally. PlausibleBA will suggest candidates based on the domain, but you own the taxonomy — no external framework is imposed.

Common starting points by domain:

• Financial services: Instrument / Party / Obligation / Event
• Healthcare: Patient / Clinical Object / Administrative Record / Encounter
• Insurance: Policy / Claim / Party / Risk
• Retail / supply chain: Product / Order / Party / Inventory
• Government: Citizen / Service / Entitlement / Case

Custom hierarchies work well when the domain has strong existing vocabulary that practitioners already use consistently, or when the Capsicum triad would require too much explanation to the intended audience of the artefact.

---

Which should you choose?

• Choose Option A if you want a framework that works consistently across domains, cross-validates well with capability maps, and connects to established business architecture thinking (REA, TOGAF, Capsicum).
• Choose Option B if domain-specific vocabulary is more important than cross-domain consistency, or if the artefact audience won't engage with an abstract framework.

Present both options clearly and wait for the practitioner to choose before proceeding. Record the chosen hierarchy — it governs all subsequent classification and appears in the XLSX Legend.

If Option A is chosen, use Party / Record / Resource throughout. If Option B is chosen, agree the custom types before classifying any objects.

Capsicum Triad — detailed classification guide (Option A)

Party Any person, organisation, or role that acts, consents, holds obligations, or is held accountable. Parties have identity, relationships, and agency.

• Signals: appears in contracts as a signatory; has rights or obligations; can initiate or block a transaction
• Examples: Guest, Owner, Contractor, Tenant, Regulator, Insured, Borrower

Resource Something of value that is transacted, allocated, consumed, or exchanged between parties. The Resource is the object of the interaction — what the interaction is about. Resources have value, can be transferred, and change hands or state through transactions.

• Signals: appears in the subject line of a contract ("for the lease of [Property]"); the answer to "what is being exchanged here?"; has a value the business can increase, protect, or realise
• Examples: Property, Portfolio, Booking (the reservation right), Tenancy (the lease right)
• Common confusion: Financial Report looks like a Resource but is a Record — it documents the state of Resources, it is not itself transacted

Record Something created to document that a business event occurred, a decision was made, or a state was measured. Records are evidence — they capture what happened to Parties and Resources. They are not transacted; they are produced.

• Signals: created as a result of something happening; answers "what did we create to capture this?"; has an author, a timestamp, and a status lifecycle
• Examples: Financial Report, Maintenance Request, Guest Review, Compliance Obligation, Invoice, Assessment, Audit Log

The triad in practice — PortfolioProp example:

Relationship Classification

Relationships between objects use three types:

Keep relationships at business level — avoid technical foreign-key thinking.

Elicitation Process

⚠️ Always run this skill in a fresh Cowork task. Prior conversation context will cause Claude to reference previous outputs rather than eliciting from the current input. Open a new task, paste the business description, then type the slash command.

Step 1 — Establish Scope

Identify from input or by asking:

• What business domain does this cover?
• Is there an existing Capability Map to cross-validate against?
• Are there existing glossaries, data dictionaries, or system entity lists to review?

Step 2 — Classification Checkpoint 0: choose the root hierarchy

Present the Party / Record / Resource triad (Option A) versus a custom hierarchy (Option B) as described in the Object Classification section above.

Do not classify any objects until the practitioner has chosen.

Step 3 — Identify Objects

Mine the input for nouns that the business consistently manages. Signals:

• Nouns that appear repeatedly in business conversations
• Things that are created, tracked, updated, and retired
• Things that appear in reports, contracts, or decisions
• Things that ground L3 capabilities in the Capability Map

Aim for 8–20 objects for a single business domain. More than 25 suggests scope creep or conflation of two domains.

Step 4 — Classify Each Object

Using the chosen hierarchy, assign each object a root type and write a one-sentence business definition: "A [type] that [what it is / what lifecycle it has]."

If Option A (Capsicum Triad): apply the Party / Record / Resource guide above. If Option B (Custom): apply the agreed domain-specific types.

The key diagnostic question for the triad: "Is this the thing being exchanged, or the thing created to document the exchange?" — if the former, it is a Resource; if the latter, it is a Record.

Step 5 — Identify Relationships

For each object pair that has a meaningful business relationship, name the relationship and classify it (Association, Composition, Generalisation).

Keep to relationships that a business stakeholder would recognise and care about. Avoid technical or implementation-level relationships.

Step 6 — Cross-validate Against Capability Map (if available)

This is the primary quality check:

Object → Capability check: Does every object have at least one L3 capability that manages it? Objects with no corresponding capability are coverage gaps — either a capability is missing from the map, or the object is out of scope.

Capability → Object check: Does every L3 capability reference an object in the Concept Model? Capabilities with no grounding object are orphaned capabilities — either the object needs naming, or the capability is a process step masquerading as a capability.

Produce a cross-reference table as part of the validation output.

Step 7 — Checkpoint: pause for validation

Present the Object Register inline and ask:

"Here is a draft Concept Model showing the core objects this business manages, classified using [chosen hierarchy]. Do these reflect the things your business teams talk about? Any objects missing, or any that feel like they belong inside another?"

Do not generate the XLSX until confirmed or adjusted.

Step 8 — Render the interactive concept graph (PRIMARY deliverable)

Immediately after the Object Register is validated, render an interactive concept graph as a self-contained HTML artifact. Do NOT wait for the user to ask. Do NOT generate the XLSX first. The graph IS the deliverable — XLSX is a download option offered beneath it.

Visual design — match VCC exactly:

• Page background: #0f172a; SVG canvas: background:#111827, border:1px solid #1e293b
• Party nodes: circle r=28, fill:rgba(45,212,191,0.12), stroke:rgba(45,212,191,0.5), label color:#ccfbf1
• Resource nodes: circle r=28, fill:rgba(59,130,246,0.12), stroke:rgba(59,130,246,0.5), label color:#bfdbfe
• Record nodes: rounded rect 72×36 rx=5, fill:rgba(236,72,153,0.12), stroke:rgba(236,72,153,0.5), label color:#fce7f3
• Icons inside nodes (small, 50% opacity, same color as node stroke):
  • Party: person silhouette (circle head + body arc)
  • Resource: plus-in-square icon
  • Record: document lines icon
• Edge lines: stroke-dasharray:4 3, stroke:rgba(30,41,59,0.9), stroke-width:1
• Selected node: stroke-width:3
• Column labels at top: Party / Resource / Record in font-size:9px, font-weight:700, uppercase, matching node color
• Graph/Table tab toggle above legend (Graph tab active)
• Font: 'DM Sans', system-ui, sans-serif

Detail panel (click to reveal — matches VCC):

• background:#1e293b, border:1.5px solid [node color], border-radius:8px
• Object name: font-size:15px, font-weight:700, color:#f1f5f9
• Type badge: font-size:10px, font-weight:700, text-transform:uppercase, letter-spacing:0.5px, color matches node
• Definition: font-size:12px, color:#94a3b8, line-height:1.55
• Lifecycle label: font-size:9px, font-weight:700, text-transform:uppercase, color:#94a3b8
• Lifecycle pills (not plain text): each state as background:rgba(255,255,255,0.09), color:#cbd5e1, border:1px solid rgba(255,255,255,0.14), border-radius:4px, padding:3px 10px, font-size:10px
• NO attributes table — that is VCC-only territory

Layout: Party nodes left column (x:90), Resource nodes centre (x:290), Record nodes split right (~x:530 and ~x:660). Space vertically by count. Draw dashed edges between related objects.

Build all node and edge data from the Object Register confirmed in this session. Do NOT use PortfolioProp example data.

Footer (required on every rendered artifact): Include a footer row at the bottom of the artifact, styled font-size:10px; color:#94a3b8; padding:10px 0 2px; border-top:1px solid #2e3f5c; margin-top:12px:

Generated by the PlausibleBA Skills Library | www.plausibleba.com
Turn this into an interactive workshopping canvas → plausibleba.com/canvas

First line in color:#94a3b8, second line in color:#4a9eda with the URL as a link.

After rendering the graph, immediately generate both export files without waiting for the user to ask:

1. XLSX — the full 4-tab workbook (Concept Model Summary, Object Register, Validation Summary, Legend) following the XLSX Output Structure below. Save to the workspace folder as <organisation>_concept_model.xlsx.
2. JSON — the VCC pipeline format following the JSON Schema below. Save to the workspace folder as <organisation>_concept_model.json.

Use the present_files MCP tool (if available) to surface the files to the user after saving.

Then present the deliverables and next steps with clickable links:

"Here is your concept model. Click any node to see its definition and lifecycle states.

Downloads:

• View Concept Model XLSX — Object Register workbook (4 tabs)
• View Concept Model JSON — VCC pipeline format

Build the full business architecture stack:

• Type /capability-map to produce or refine the Capability Map — cross-validates that every object has at least one grounding capability
• Type /value-stream to map Value Streams — trace how these business objects flow through staged delivery sequences
• Open in PlausibleBA Canvas — upload the JSON for full interactive visualisation"

Replace <workspace_path> with the actual workspace output path and <organisation> with the client/organisation name from this session (snake_case for filenames).

Inline Preview Format

Classification Checkpoint 0 — hierarchy choice (present before any classification):

"Before we classify the objects, which hierarchy would you like to use? Option A — Capsicum Triad (Party / Record / Resource): principled, cross-domain consistent, grounded in REA and Bunge. Recommended for business architecture work. Option B — Custom hierarchy: domain-specific types you define. [See the Object Classification section above for full explanation of each option.]"

Checkpoint — Object Register preview (sorted by Number, after hierarchy chosen):

XLSX Output Structure

Four worksheets, following the PlausibleBA taxonomy standard tab order.

Sheet 1: Concept Model Summary

• Title block, subtitle, branding line
• Chosen hierarchy: Capsicum Triad (Party / Record / Resource) or custom type names
• Totals: Objects by root type
• Per-type breakdown table
• Cross-validation summary: objects with full coverage / gaps / orphaned capabilities
• Notes on key modelling decisions, including any non-obvious classifications
• Next Steps: Value Stream Analysis

Sheet 2: Object Register

Branding line above header. Pre-sorted by Number.

Sheet 3: Validation Summary

Sheet 4: Legend Chosen hierarchy with full type definitions, Capsicum Framework reference (if Option A), relationship types, colour coding, PlausibleBA standard version, website link.

If Option A was chosen, include in the Legend:

"Object types follow the Capsicum Framework Party / Record / Resource triad — consistent with REA (Resources, Events, Agents — McCarthy 1982) and Bunge's ontology for information systems. Party = who acts. Resource = what is transacted. Record = what documents the transaction."

XLSX Colour Coding

Note: when a custom hierarchy has more than three types, extend the colour palette consistently — use the PlausibleBA blue/green/teal range and avoid red (reserved for validation failures).

JSON Schema (for VCC pipeline integration)

{
  "obj_<snake_case_name>": {
    "id": "obj_<snake_case_name>",
    "elementType": "BusinessObject",
    "name": "<Object Name>",
    "number": "1",
    "classificationHierarchy": "CapsicumTriad|Custom",
    "type": "Party|Record|Resource|<custom>",
    "definition": "A [type] that ...",
    "lifecycleStates": ["state1", "state2"],
    "relatedCapabilities": ["cap_id_1", "cap_id_2"],
    "relatedObjects": [
      {
        "objectId": "obj_other",
        "relationship": "Association|Composition|Generalisation",
        "label": "has many"
      }
    ]
  }
}

Quality Bars

A good Concept Model for a single business domain:

• 8–20 named objects
• Every object has a Type and a one-sentence business definition
• Every object has at least one lifecycle state sequence
• Every object is referenced by at least one L3 capability (if a Capability Map exists)
• No two objects are semantically identical at the same level
• Relationships are named and typed

Common Failure Modes

Next Steps

Next steps are now presented inline with the downloads after the concept graph is rendered (see Step 8). The /capability-map and /value-stream commands are offered as clickable follow-on actions, and the XLSX/JSON exports are generated automatically — there is no separate export gate.