Industry Function Graph
Industry Function Graph
The Industry Function Graph separates three questions that are often mixed together: where a use case belongs, what it requires and provides, and how it is realised in a real ecosystem.
Sector, business function and value-stream stage classify the work. Machine-readable interfaces define what can connect to what. Real implementation flows record the participants, credentials, trust roles and implementation context through which the work is performed.
Classification tells us where a use case belongs. Interfaces tell us what it can connect to. Realisation tells us how that use case is implemented in practice.
The graph therefore separates reusable business patterns from the credentials and implementations that happen to realise them today. It currently holds 15 patterns, 16 flows, 25 conditions and 10 credential types, classified across 10 ISIC classes and 5 whole sections, and 3 value streams.
Classification locates a reusable use case by economic sector, primary business function and, where applicable, value-stream stage. Classification supports discovery. It does not determine which use cases compose.
Interface defines the conditions a use case requires before it can run and the conditions it provides afterwards. These conditions form the machine-readable contract from which composition is derived.
Realisation records how a canonical use case is implemented in a concrete sector and jurisdiction: the flow, participants, credentials, trust roles, maturity and implementation evidence.
A UseCasePattern is the reusable definition. A Flow
is a concrete implementation of one or more patterns. A flow is never the
use case itself.
A credential is not the interface.
A use case provides a condition. A credential may substantiate that condition. Another use case requires the condition, not the credential. Conditions connect use cases; credentials can provide evidence for particular conditions. This is what allows a new credential, issuer or evidence mechanism to satisfy an existing business requirement without redefining every downstream use case.
A more specific condition can satisfy a broader requirement, but not the reverse. An upper-secondary qualification credential substantiates the narrower condition Upper-secondary qualification held. Because that condition is a specialisation of Education qualification evidence available, it satisfies a downstream use case that asks only for education-qualification evidence. Composition therefore does not depend on exact condition-name equality.
The reasoning performed is exactly this: a provision satisfies a requirement
when the provided condition is the required condition, or is reachable from
it by following skos:broader upwards. No other inference is
applied.
Conditions distinguish four kinds of state. Holding evidence is not the same
as having established the corresponding fact: eid-held is
evidence, identity-verified is a fact.
Condition compatibility is the core composition rule. Where specified,
additional interface constraints — subject role, a named evidence type,
and key=value context such as jurisdiction or assurance level
— narrow compatibility further. The model supports all three. The
current dataset records subject role and evidence type and populates no
context constraints, and as the values stand none of the three currently
excludes a pairing that the condition rule allows.
Credential-to-condition mappings are many-to-many. A new credential type is introduced by declaring which evidence condition it substantiates; existing use cases requiring that condition do not need to be rewritten. It becomes a candidate evidence mechanism for those use cases, subject to their additional context, trust and policy constraints.
Every edge below is derived, not drawn. Each arrow follows one path: a provided condition → condition compatibility or subsumption → a required condition, with any stated role, evidence-type and context constraints applied on top. No file in this repository records which use case enables which.
Requirements with no provider here: accreditation-evidence-available. Each marks
an upstream step outside this repository or not yet modelled.
Because interfaces are machine-readable, these relationships are computed
from the model rather than maintained as a second set of hand-drawn links.
build/queries.py runs them against the dataset and CI checks
that each still returns an answer.
Answers are derived from the use cases and conditions currently represented in the dataset, not from the ecosystem at large.
Describe an activity, a high-level use case or a process. The page matches your wording against the vocabularies in the graph, then answers from the model: which existing pattern it most resembles, which primary function and value-stream stage it looks like, which conditions it appears to touch, and what would supply or consume those conditions.
What this is. The text step is lexical: it compares your words with concept labels and definitions. It does not understand your description, and it matches words rather than meaning — an age check described without the word age will not be found. Everything after that step is exact: the condition subsumption, and the suppliers and consumers of each condition, are resolved in the build by the same model the validator uses, and the page only looks them up. Those answers are for a bare condition; a real interface point may narrow further by subject role, evidence type or context. Read the result as a shortlist to check, not a classification.
The canonical unit: one primary business function, a defined set of required conditions and one principal business outcome, shown in bold. A pattern may expose additional outputs, but it represents one coherent transformation. Where a proposed use case contains independently reusable transformations with different principal outcomes, it is split into smaller patterns and a real flow composes them.
Two use cases under the same primary function may still be distinct, because their required conditions or principal outcomes differ. Conversely, two implementations in different sectors realise the same canonical use case when the underlying business transformation and interface are equivalent.
An issuing authority identifies a person and issues a state electronic identity into their wallet.
Requires— nothing
ProvidesElectronic identity held (as Electronic identity credential)
A relying party evaluates presented identity evidence and establishes the subject's identity to the level of assurance the interaction requires.
RequiresIdentity evidence available
ProvidesIdentity verified
A relying party checks presented evidence of an education or training qualification and establishes that the subject holds it.
RequiresEducation qualification evidence available
ProvidesQualification verified
A relying party evaluates an organisation's presented accreditation evidence and establishes, under the policy that applies to the interaction, that the required accreditation is present and current.
RequiresAccreditation evidence available (organisation)
ProvidesAccreditation verified (organisation)
A relying party establishes that the subject satisfies a stated age threshold, without requiring disclosure of the date of birth or of the subject's identity.
RequiresIdentity evidence available
ProvidesAge threshold established
A regulated organisation opens a relationship with a customer whose identity is already established, performs the due diligence its supervisor requires, and issues a reusable attestation that it did so.
RequiresIdentity verified
ProvidesCustomer relationship open, KYC attestation held (as KYC attestation)
An organisation re-runs customer due diligence on an existing relationship at the interval its supervisor requires.
RequiresCustomer relationship open, Due diligence evidence available
ProvidesKYC attestation current (as KYC currency attestation)
A customer who has lost their access credentials is re-identified before access is restored.
RequiresCustomer relationship open, Identity verified
ProvidesAccess granted
A relationship entered at limited legal capacity is re-established at full capacity, typically on reaching majority.
RequiresCustomer relationship open, Identity verified
ProvidesLegal capacity established
An awarding institution issues a completed education or training qualification to the graduate as a verifiable credential.
RequiresIdentity verified
ProvidesUpper-secondary qualification held
A higher education institution admits a student on established identity and qualification.
RequiresIdentity verified, Qualification verified
ProvidesTertiary enrolment established, Tertiary enrolment evidence held (as Tertiary enrolment attestation)
An employer engages a candidate whose identity and qualifications are already established, and issues evidence of the employment relationship.
RequiresIdentity verified, Qualification verified
ProvidesEmployment relationship open, Employment evidence held (as Employment attestation)
A care provider binds an identified person to the correct medical record.
RequiresIdentity verified
ProvidesPatient record linked
A public administration grants a resident access to an online service and establishes the entitlement that service rests on.
RequiresIdentity verified
ProvidesAccess granted, Service entitlement established, Service entitlement evidence held (as Service entitlement attestation)
A buying organisation decides that a supplier with verified accreditations is eligible to be contracted, and records the decision.
RequiresAccreditation verified (organisation)
ProvidesSupplier qualified (organisation), Supplier qualification evidence held (organisation, as Supplier qualification record)
A flow records how a pattern is realised in a concrete sector and jurisdiction. A flow can record its sector, jurisdiction, participants and their trust roles, the credentials issued, presented or verified, its maturity, documentation and deployment evidence, and which participants bear cost without direct value. Not every flow populates every field.
Realisation is many-to-many in both directions. Several flows may realise the same canonical use case — the retail and hospitality age checks both realise Age threshold verification. One flow may realise several canonical use cases in sequence — employee onboarding composes identity verification, qualification verification and employment engagement. The reusable patterns stay stable while implementations, credentials and sectors evolve independently.
Maturity is stated on each card. In this dataset every flow is
Modelled or Exploratory: none is recorded as
deployed, and no flow yet carries deployment evidence. All
10 credential types are marked
ifm:codeStatus "provisional" — none has been checked
against a published schema registry.
The federal issuer identifies a resident and issues the EID into their wallet.
Realises
A relying party requests a presentation from the wallet and verifies it against the federal trust infrastructure.
Realises
A prospective customer opens an account remotely. The bank verifies the e-ID, completes due diligence and issues a reusable KYC attestation.
The bank re-runs due diligence on an existing relationship at the supervisory interval.
Realises
An e-banking customer who has lost their credentials is re-identified before access is restored.
A customer onboarded as a minor turns 18 and the relationship is re-established at full legal capacity, with a qualified electronic signature.
An upper-secondary school issues the gymnasiale Maturitätszeugnis to the graduate as a verifiable credential.
A vocational school issues the eidgenössisches Fähigkeitszeugnis to the apprentice as a verifiable credential. The same pattern as the Maturität flow, a different credential.
A university admits a student on the e-ID and an upper-secondary qualification, without re-collecting paper documents.
A merchant checks that a customer is over the legal age for a restricted product.
Realises
A restaurant checks that a guest is over the legal age for a restricted product. The same pattern as the retail flow, a different sector.
Realises
An employer identifies a new hire, checks the qualifications the role requires and engages them.
A hospital identifies a patient at admission and links them to the right record.
A resident authenticates to a public-administration service portal and discloses the attributes that service requires.
A pharmaceutical manufacturer qualifies a supplier against GMP certification.
An aerospace manufacturer qualifies a supplier against quality accreditations. The same pattern as the pharmaceutical flow, a different sector.
The matrix shows where canonical use cases recur across economic sectors and business functions. It is a classification and discovery view of the graph, not the definition of it: sector and function aid discovery, and do not determine whether two use cases are the same use case. Repetition across sectors identifies candidates for reusable cross-sector patterns; the interfaces determine whether the use cases are actually equivalent or composable.
| ISIC Rev. 5 section | Identity proofing | Relationship onboarding | Identity lifecycle management | Eligibility verification | Access management | Certification and attestation | Regulatory compliance | Sourcing and procurement | Supply chain traceability | Human capital management | Request and complaint handling | Service delivery | Records management | Contracting and signing | Quality assurance | Audit and assurance | Product compliance | Entitlement administration |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| C Manufacturing | ● | ○ | ● | ○ | ● | ○ | ○ | ● | ○ | |||||||||
| G Wholesale and retail trade | ● | ● | ○ | |||||||||||||||
| I Accommodation and food service activities | ● | ● | ○ | |||||||||||||||
| K Telecommunications, computer programming, consultancy, computing infrastructure, and other information service activities | ● | ○ | ||||||||||||||||
| L Financial and insurance activities | ● | ● | ●●○ | ○ | ●○○ | ● | ○ | ○ | ||||||||||
| P Public administration and defence; compulsory social security | ●○ | ● | ● | ○ | ○ | ○ | ○ | |||||||||||
| Q Education | ● | ● | ● | ● | ● | ○○ | ○ | |||||||||||
| R Human health and social work activities | ● | ● | ● | ○ | ○ |
● primary function of a use case · ○ supporting function. Follow a marker to the use case.
Value-stream stages provide an additional end-to-end structure. A stage can declare its own required and provided conditions, and a canonical use case realises that stage when its business transformation and interface fit. The graph can then identify which stages are currently realised by use cases and which remain unmodelled.
The concept follows ArchiMate's Value Stream element. The catalogue and stage decomposition below are an IFM modelling layer rather than extracts from a standard, since no openly licensed catalogue exists: each is one modelled sequence, not an authoritative industry taxonomy. Stage numbers are a reading order, not an execution order.
The same model that finds connections also exposes gaps. A reported gap may represent missing ecosystem capability, work outside the current scope, or a use case that has not yet been modelled. None of these is presented as a defect.
A use case here asks for a condition that no use case here produces. The upstream step is outside this repository, or not yet modelled.
Nothing here requires what these patterns produce. Either a genuine end of a chain, or a downstream pattern nobody has written down.
A reusable pattern that no flow in this dataset realises.
The dataset covers a slice of each stream. These stages mark where a pattern could be added without inventing a new classification.
A flow issues the credential; no flow in this dataset presents or verifies it.
Patterns with the same primary function and related interfaces are surfaced as potential overlaps. The graph does not merge them. Similar interfaces may represent duplicate, narrower, broader, partially overlapping or genuinely distinct work, and the relation below states which of those the comparison found.
| Relation | Pattern | Pattern | Shared primary function |
|---|---|---|---|
| overlap | Re-identification for credential recovery | Re-identification at a change of legal capacity | Identity lifecycle management |
| overlap | Onboarding with regulatory due diligence | Tertiary admission | Relationship onboarding |
| overlap | Electronic identity issuance | Education qualification issuance | Certification and attestation |
Secondary by design. None of this takes part in classification or in composition; it is here to help prioritise work, and both vocabularies are this repository's editorial classifications rather than external standards.
This website is one view of the graph.
The same model is generated as RDF and JSON-LD and validated through SHACL
shapes and repository checks. Queries and derived reports use the same
underlying data as this page. The HTML is a projection: the composition
edges, gaps and overlap candidates shown above are derived at build time from
the interfaces in data/, and the RDF graph is not a second model
maintained by hand.
The graph carries SKOS concept schemes for the sector, function, condition,
subject-role, trust-role and credential vocabularies;
ifm:UseCasePattern nodes carrying a classification and an
interface of ifm:requires and ifm:provides; and
ifm:Flow nodes recording what realises them. Provenance is
explicit: ifm:codeStatus separates concepts taken from an
external classification from this repository's own modelling, and
ifm:mappingStatus records how an alignment onto an external
scheme was arrived at.