Entity Type Taxonomy Specification

Entity Type Taxonomy Specification

Version: 1.0 Date: 01/04/2026 Status: Authoritative reference — source of truth for prompt engineering and eval validation Informs: Classification prompt (docs/reference/classification-prompt.md), TS tool schema (lib/ai/classify.ts), TS skill (lib/ai/skills/classification.md), eval suite fixtures, post-extraction validation rules

---

1. Purpose and Scope

This document defines precise, testable criteria for the 12 entity types used in Knowledge Hub content classification. It exists because the S140 investigation found systematic misclassification across ALL entity types: 79% of framework entities were wrong, capability had contradictory definitions between pipelines, technology was too broad, person included job titles, standard included contracts, and methodology included internal processes.

This spec is the single source of truth. When updating classification prompts, post-extraction validation rules, or eval fixtures, consult this document. If this document and the prompt disagree, this document wins and the prompt must be updated.

1.1 How to Use This Spec

• Prompt engineering: Translate the per-type definitions, tests, and boundary rules into prompt guidance. The “The Test” question for each type should appear verbatim or near-verbatim in the prompt.
• Eval validation: Each inclusion example is a true positive. Each exclusion example is either a true negative (should not be extracted) or a type correction (should be a different type). Boundary cases are the hard test cases that differentiate a good prompt from a bad one.
• Post-extraction validation: The universal exclusion rules (Section 2) should be implemented as deterministic code filters. The per-type exclusion patterns inform blocklists and regex rules.
• Entity registry: The inclusion examples per type form the seed for a canonical entity-to-type mapping registry.

---

2. Universal Inclusion/Exclusion Rules

These five rules apply before any per-type evaluation. If a candidate entity fails any universal rule, it is excluded regardless of type.

Rule 1: The Named Entity Test

Question: “Is this a specific, named thing that exists independently of the document discussing it?”

If no, exclude. Entities must be proper nouns or specific named standards, regulations, products, organisations, or methodologies. Abstract descriptions of activities, concepts, or categories are not entities.

Passes: ISO 27001, GDPR, Agile, Microsoft Azure, NHS, PRINCE2 Fails: information security, business continuity, data protection, encryption, regulatory compliance, security best practice

Rule 2: The External Reference Test

Question: “Could someone outside this organisation look this up and find an independent definition, specification, or registration?”

If no, the candidate is likely an internal document, process, or concept. Exclude it.

Passes: OWASP (published security framework), ITIL (published service management framework), Cyber Essentials (government scheme with public criteria) Fails: Information Security Policy (specific to this organisation), Staff Security Breach Process (internal procedure), Phew Information Management System (company-specific system)

Rule 3: The Policy/Procedure/Plan Rule

Any candidate entity whose name ends in one of these suffixes is almost certainly an internal company document and MUST be excluded:

• Policy
• Procedure
• Plan
• Process
• Register
• Schedule
• Agreement (when referring to a contract type, not a specific named treaty)
• Statement

Exception: Named statutory guidance or government policy that happens to use these words retains its entity status as type regulation. The distinguishing test is whether non-compliance carries legal consequences imposed by a government or regulatory body. Implementers MUST maintain an allowlist of known statutory exceptions — the suffix filter alone will over-exclude.

Known statutory exceptions (retain as regulation):

• Wales Safeguarding Procedure (statutory guidance with legal force)
• Working Together to Safeguard Children (HM Government statutory guidance)
• Keeping Children Safe in Education (DfE statutory guidance)
• Government Security Classification Policy (HMG Security Policy Framework)
• Modern Slavery Statement (statutory requirement under Modern Slavery Act 2015)

Excluded: Information Security Policy, Business Continuity Plan, Acceptable Use Policy, Data Retention Schedule, Clear Desk Policy, Incident Response Plan, Data Processing Agreement, Supplier Security Policy, Social Value Statement, Remote and Flexible Working Policy, Staff Security Breach Process, Patch Management Process

Rule 4: The Role Title Rule

Job titles and role descriptions are NOT person entities. Only extract actual personal names (given name + surname, or a recognised individual name).

Excluded: Managing Director, Client Project Lead, Data Protection Officer, Account Manager, Chief Information Security Officer, Customer Services Manager, Project Manager, IT Director, Senior Developer

Retained (as person): Matthew Burgess, John Smith, Jane Doe

The test: “Is this a name that identifies a specific individual, or a description of a position that many people could hold?” If many people could hold this title, exclude it.

Rule 5: The Generic Concept Rule

Abstract concepts, activities, and broad categories are NOT entities even when they appear as noun phrases in the text. Only extract named, specific things.

Excluded: information security, business continuity, data protection, penetration testing (as a concept), two-factor authentication (as a concept), encryption, firewalls, disaster recovery, regulatory compliance, security best practice, information governance, data wiping, physical destruction

Note on capability vs concept: Some of these terms (penetration testing, disaster recovery) might seem like capabilities. The distinction is whether the text is discussing a named service offering the organisation provides to clients, or a generic security concept. “We offer penetration testing as a service” makes “penetration testing” a candidate for capability only if it is a named, listed service offering — not if the text merely mentions the concept in passing. When in doubt, the generic concept interpretation should win and the term should be excluded. Named service offerings typically have brand names or specific scoping (e.g., “Phew Pen Test Service” would be a product, not a capability).

---

3. Entity Type Definitions

3.1 organisation

Definition: A named legal entity, government body, standards body, professional association, or formal institutional body that exists as a registered or officially recognised entity.

The Test: “Does this entity have a legal registration, government charter, or formal institutional standing? Could I look up its official website, company number, or regulatory registration?”

Inclusion Criteria:

• Named companies (Phew Design Limited, Acme Corp, Deloitte)
• Government bodies (NHS, HMRC, ICO, Companies House)
• Standards bodies (BSI, ISO — the organisations, not the standards they publish)
• Regulatory bodies (FCA, OFSTED, CQC)
• Professional associations (CREST, ISACA, BCS)

Exclusion Criteria:

• Generic references to “the organisation” or “the company” — these are pronouns, not named entities. Exclude.
• Departments within an organisation (“IT Department”, “HR Team”) — these are internal divisions, not independent organisations. Exclude.
• Informal groupings (“the project team”, “senior management”) — not named entities. Exclude.
• Sectors or industries (“public sector”, “financial services”) — use type sector if extracted.
• Data centre or building names (“Bedford Technology Park”) — these are locations, not organisations. Exclude.

Boundary Cases:

• CREST as organisation vs certification: CREST is an organisation that issues certifications. When the text says “CREST-accredited”, the entity is the CREST certification (type certification). When it says “a member of CREST” or “CREST requires…”, the entity is the CREST organisation (type organisation). Context determines type.
• BSI as organisation vs standard prefix: BSI is the British Standards Institution (an organisation). “BS 5839” is a standard published by BSI. Do not confuse the organisation with its publications.
• Local Safeguarding Partnership: Despite sounding like a concept, this is a statutory body type with specific legal standing. Type as organisation.
• Crown Commercial Service as organisation vs framework: CCS is an organisation. G-Cloud (which CCS operates) is a framework. Do not type CCS as a framework.

---

3.2 certification

Definition: A formal credential, accreditation, or compliance mark that an organisation or individual holds, seeks, or maintains, issued by an independent certifying body after assessment against defined criteria.

The Test: “Is this something an organisation or person obtains by being assessed against criteria, and that can be displayed as a credential? Does it have an issuing body, a validity period, and a renewal cycle?”

Inclusion Criteria:

• ISO certifications when held or sought (ISO 27001, ISO 9001, ISO 14001, ISO 22301)
• Government schemes (Cyber Essentials, Cyber Essentials Plus)
• Industry certifications (PCI DSS, SOC 2)
• Professional accreditations (CREST accreditation)
• Competency certifications (CompTIA Security+, CISSP)

Exclusion Criteria:

• The published standard document itself when discussed as a specification rather than a credential held — use type standard. See boundary case below.
• Management system acronyms (ISMS, QMS, EMS, IMS) — these are the internal systems that implement certifiable standards, not certifications themselves. Typically exclude, or type as certification only when explicitly discussed in a certification context (e.g., “our ISMS is certified to ISO 27001”). Prefer extracting the actual certification (ISO 27001) rather than the management system (ISMS).
• Training completion (“completed GDPR awareness training”) — training is an activity, not a certification. Exclude.
• Self-declared compliance (“GDPR compliant”) — compliance is a status, not a held certification. The regulation (GDPR) should be typed as regulation.

Boundary Cases:

• ISO 27001 as certification vs standard: When the text discusses holding the certification, undergoing audits, or maintaining certified status, type as certification. When the text discusses the requirements, clauses, or content of the published standard document, type as standard. If ambiguous, prefer certification because in UK SMB bid documents, ISO standards are overwhelmingly discussed as credentials held.
• ISMS/QMS/EMS/IMS: These management system acronyms sit between the certification and the organisation’s internal processes. They are the operational system that delivers compliance. Prefer to extract the underlying certification (ISO 27001, ISO 9001, ISO 14001) rather than the management system itself. If the management system is mentioned without its associated certification, exclude it.
• Cyber Essentials vs Cyber Essentials Plus: These are distinct certifications. Extract whichever is mentioned. Do not collapse “Cyber Essentials Plus” into “Cyber Essentials”.

---

3.3 regulation

Definition: A law, statutory instrument, government regulation, or piece of statutory guidance that carries legal force — meaning non-compliance has legal consequences imposed by a government or regulatory body.

The Test: “Does non-compliance with this carry legal penalties, enforcement action, or statutory consequences? Was it enacted by a legislature or issued as binding guidance by a government body?”

Inclusion Criteria:

• Acts of Parliament (Data Protection Act 2018, Equality Act 2010, Health and Safety at Work Act 1974)
• EU/UK regulations with direct effect (GDPR, PECR, NIS Regulations)
• Statutory instruments and orders (RIDDOR, CDM Regulations)
• Statutory guidance with legal force (Working Together to Safeguard Children, Keeping Children Safe in Education, Wales Safeguarding Procedure)
• Government procurement notices with compliance requirements (PPN 06/20, PPN 02/23)

Exclusion Criteria:

• Generic concepts (“data protection”, “health and safety”, “regulatory compliance”) — these describe areas of law, not specific regulations. Exclude.
• GDPR sub-concepts (lawful bases like “consent”, “legitimate interest”, “contractual necessity”; concepts like “records of processing activity”, “data protection by design and default”, “technical and organisational measures”) — these are legal concepts within GDPR, not standalone regulations. Exclude.
• Rights within a regulation (“data subject access request”, “right to erasure”) — these are mechanisms within GDPR, not separate regulations. Exclude.
• Conditions or topics (“female genital mutilation”, “county lines criminal exploitation”) — these are safeguarding topics, not regulations. Exclude.
• Industry codes of practice that lack statutory backing — use framework or standard depending on structure.

Boundary Cases:

• Statutory guidance vs framework: Some government guidance documents have legal force (non-compliance triggers enforcement action) while others are advisory. The test is legal consequence. “Working Together to Safeguard Children” is regulation because local authorities are legally required to follow it. “NCSC 10 Steps to Cyber Security” is a framework because non-compliance carries no legal penalty.
• PPN (Procurement Policy Notes): These are binding on government buyers and carry contractual consequences for suppliers. Type as regulation.
• Data Protection Act 2018 vs GDPR: Both are valid as separate regulations. DPA 2018 is the UK domestic legislation; GDPR is the EU regulation retained in UK law. Extract whichever is mentioned.

---

3.4 framework

Definition: A published, externally maintained, structured set of principles, practices, or assessment criteria that organisations can voluntarily adopt, implement, or be assessed against — but that does not carry legal force and is not a certifiable standard.

The Test: “Is this a structured body of guidance, published by an external organisation, that another organisation could independently choose to adopt? AND does it lack legal force AND is it not a certifiable standard?”

Inclusion Criteria:

• Security assessment frameworks (OWASP, OWASP Top 10, NIST Cybersecurity Framework)
• Service management frameworks (ITIL, COBIT, TOGAF)
• Government procurement frameworks (G-Cloud, G-Cloud 14, Digital Outcomes and Specialists)
• Government assessment/evaluation frameworks (Education Inspection Framework, Social Value Model)
• Cyber security guidance frameworks (NCSC 10 Steps to Cyber Security, NCSC 12 Principles for Supply Chain Security, NCSC 14 Cloud Security Principles)

Exclusion Criteria:

• Internal policies, procedures, plans, or processes. Apply Rule 3. These are NEVER frameworks. Information Security Policy, Business Continuity Plan, Acceptable Use Policy, Data Protection Policy, Secure Disposal Policy, Data Retention Policy — all excluded.
• Management systems (ISMS, QMS, EMS, IMS, Integrated Management System) — these are not published external frameworks; they are internal implementations of certifiable standards. See certification boundary cases. Exclude or type as certification context.
• Generic concepts (information governance, regulatory compliance, security best practice, information security) — these describe domains of activity, not named frameworks. Exclude.
• GDPR artefacts (Records of Processing Activity, Data Processing Agreement, Technical and Organisational Measures) — these are GDPR-mandated document types or concepts, not frameworks. Exclude.
• Lawful bases under GDPR (consent, contractual necessity, legal obligation) — these are legal concepts within a regulation, not frameworks. Exclude.
• Regulations with legal force — use type regulation.
• Published certifiable standards — use type standard or certification.
• Principles or concepts (CIA Triad, Segregation of Duty, Defence in Depth) — these are security principles or concepts, not structured frameworks. Exclude.

Boundary Cases:

• OWASP as framework vs organisation: OWASP is both an organisation and a framework publisher. When the text says “OWASP Top 10 vulnerabilities” or “assessed against OWASP”, the entity is the framework. When the text says “OWASP publishes…” or “a member of OWASP”, the entity is the organisation.
• PRINCE2 as framework vs methodology: PRINCE2 has elements of both (structured framework with a certification path, and a project management methodology). Type as methodology because its primary identity is as a project management approach, not an assessment/governance framework.
• Statutory guidance that looks like a framework: If non-compliance carries legal consequences, it is regulation, not framework. “Working Together to Safeguard Children” has legal force — type as regulation. “NCSC 10 Steps to Cyber Security” does not — type as framework.
• G-Cloud as framework vs product: G-Cloud is a procurement framework (the mechanism), not a product. Type as framework. Specific lots or contracts within G-Cloud are not separate entities.

---

3.5 capability

Definition: A named, distinct service offering, professional competency, or operational function that the organisation provides to external clients or maintains as a core differentiating skill.

The Test: “Is this a specific, named service or competency that the organisation would list on its website or in a capabilities statement as something it offers to clients?”

Inclusion Criteria:

• Named service offerings (penetration testing — when offered as a named service, 24/7 managed SOC, incident response services, security consultancy)
• Professional competencies that are client-facing (ISO 27001 implementation support, GDPR compliance auditing, vulnerability assessment)
• Operational capabilities with client impact (multi-site delivery, round-the- clock monitoring)

Exclusion Criteria:

• Internal policies or procedures. Internal policies are NOT capabilities. Information Security Policy, Acceptable Use Policy, Data Protection Policy — all excluded (Rule 3). The TS pipeline’s previous definition of capability as “includes internal policies” was wrong and is superseded by this spec.
• Generic security concepts (encryption, firewalls, two-factor authentication, access control) — these are technologies or techniques, not capabilities. Exclude.
• Job titles or roles (Data Protection Officer, Project Manager) — these are role descriptions, not capabilities. Exclude (Rule 4).
• Activities described in passing (“data wiping”, “physical destruction”, “staff vetting”) — these are activities mentioned in content, not named service offerings. Exclude unless explicitly presented as a named service.
• Abstract domains (information security, business continuity, data protection) — these are fields of practice, not specific capabilities. Exclude (Rule 5).
• Management systems (ISMS, QMS) — these are internal systems, not capabilities. See certification.

Boundary Cases:

• “Penetration testing” as capability vs generic concept: When the text says “we provide penetration testing services” or lists it as a service offering, it is a capability. When the text merely mentions “penetration testing should be conducted annually”, it is a generic concept. The test is whether the entity is being described as something the organisation sells or delivers. When in doubt, exclude — the generic interpretation is more common in bid documents.
• Capability vs methodology: A capability is WHAT the organisation does. A methodology is HOW they do it. “Agile delivery” is a methodology. “Software development” is a capability (if offered as a named service). “Project management” is a capability. “PRINCE2” is a methodology used to deliver that capability.
• Capability vs product: If the capability has a branded name and is sold as a distinct product, it is a product. “Phew Audit System” is a product. “Security auditing” is a capability.
• Training as capability vs internal activity: When text describes training the organisation offers to clients as a service, the named training programme may be typed as product (if branded, e.g., “Phew Knowledge Academy”) or its delivery as a capability (e.g., “safeguarding training delivery”). When text describes internal staff training (“all staff complete annual GDPR refresher training”), this is an internal activity — exclude. Generic training descriptions (“online training”, “onsite training”) are not named service offerings — exclude.

---

3.6 person

Definition: A named individual human being, identified by personal name (given name, surname, or both).

The Test: “Is this the actual name of a specific, identifiable individual person? NOT a job title, role description, or generic reference?”

Inclusion Criteria:

• Full names (Matthew Burgess, Jane Smith, John Doe)
• Single names when clearly referring to an individual (Matthew, if context makes the referent clear)
• Historical/public figures mentioned by name (Alan Turing, Tim Berners-Lee)

Exclusion Criteria:

• Job titles (Managing Director, Chief Information Security Officer, Client Project Lead, Account Manager, IT Director) — these are roles, not people. Apply Rule 4. Exclude.
• Name + title combinations that are really title references (“the Managing Director”) — exclude.
• Descriptive strings that embed a name with context (“Matthew (MD, Phew Design Limited)”) — extract just the name (“Matthew Burgess” if identity is known) and discard the descriptive wrapper.
• Generic role references (“the DPO”, “the project lead”, “the auditor”) — these are roles, not named individuals. Exclude.
• Team names or group references (“the IT team”, “senior management”) — not individuals. Exclude.

Boundary Cases:

• Name with title embedded: “Matthew Burgess, Managing Director” should extract “Matthew Burgess” as type person. Do not extract “Managing Director” as a separate entity.
• Canonical name consistency: The same individual must always resolve to the same canonical name. “Matthew Burgess”, “Matt Burgess”, “Matthew (MD, Phew Design Limited)” should all resolve to canonical name “Matthew Burgess”. This is a canonicalisation concern, not a typing concern.
• “Phew Director” — not a person: This is a role title, not a name. Exclude.

---

3.7 technology

Definition: A named commercial software platform, cloud service, infrastructure product, or specific technical tool that an organisation deploys, operates, or integrates with.

The Test: “Is this a specific, named software product, cloud service, or technical platform that can be purchased, subscribed to, or downloaded? Does it have a vendor, a version, and a product page?”

Inclusion Criteria:

• Cloud platforms (Microsoft Azure, AWS, Google Cloud Platform)
• Software products used as infrastructure (Active Directory, SharePoint, Microsoft 365, Salesforce, ServiceNow, Jira)
• Security tools (SIEM — as a named product category with specific commercial implementations)
• Development platforms (GitHub, GitLab, Docker, Kubernetes)
• Database systems (PostgreSQL, MongoDB, SQL Server)

Exclusion Criteria:

• Protocols (HTTPS, SSH, SSL, TLS, SMTP, FTP, TCP/IP, DNS) — these are communication specifications, not technologies you deploy. Exclude. If the protocol is a published specification, it might qualify as a standard, but most protocol mentions in bid documents should be excluded entirely.
• File formats (PDF, CSV, HTML, XML, JSON) — these are data encoding conventions, not technologies. Exclude.
• Cryptographic algorithms and primitives (AES-256, RSA, SHA-256, PBKDF2-HMAC-SHA256, TLS 1.2) — these are mathematical specifications, not deployable technologies. Exclude.
• Programming languages (JavaScript, Python, Java) — these are languages, not specific products or platforms. Exclude.
• Generic technology categories (“cloud computing”, “artificial intelligence”, “blockchain”, “machine learning”) — these are fields, not specific technologies. Exclude. The TS pipeline’s previous definition of technology as “general technology categories” was wrong and is superseded by this spec.
• Security concepts expressed as technology (“encryption”, “firewalls”, “multi-factor authentication”, “intrusion detection”) — these are categories of technology, not specific named products. Exclude unless a specific product name is given (e.g., “CrowdStrike” is a product, “endpoint detection” is a concept).

Boundary Cases:

• Azure vs “cloud computing”: “Azure” is a specific named platform — type as technology. “Cloud computing” is a generic category — exclude.
• SIEM as technology vs concept: “SIEM” as a general concept is borderline. When a specific SIEM product is named (Splunk, QRadar, Sentinel), prefer to extract the product name. When only “SIEM” is mentioned, it may be included as technology if it clearly refers to a deployed tool, but prefer to exclude when it is used generically.
• Active Directory vs “directory services”: “Active Directory” is a specific named product — type as technology. “Directory services” is a generic category — exclude.
• Technology vs product: Both refer to named commercial things. The distinction is: technology is infrastructure and tools that the organisation uses internally. product is something the organisation sells or offers to clients. When the organisation uses Azure, Azure is a technology. When the organisation sells “Phew Audit System”, that is a product. Most technology mentions in bid documents are infrastructure the bidder uses, so technology is typically correct.

---

3.8 project

Definition: A named project, programme, contract, or initiative with a defined scope, timeline, and identity — something that was initiated, executed, and (usually) completed.

The Test: “Is this a named piece of work with a start, middle, and (planned) end? Does it have a project name, a client, and a scope?”

Inclusion Criteria:

• Named client projects (“NHS Wales Digital Transformation Programme”)
• Named internal initiatives (“Project Phoenix”, “Cloud Migration Programme”)
• Named contracts when discussed as a body of work (“G-Cloud 14 Call-Off Contract for NHS Trust”)

Exclusion Criteria:

• Generic descriptions of work (“cloud migration”, “security improvement”) — these describe activities, not named projects. Exclude.
• Physical locations (“Bedford Technology Park”) — these are locations, not projects. Exclude.
• Products (“Phew Audit System”) — even if developed as a project, once operational it is a product.
• Framework lots or categories (“G-Cloud Lot 2”) — these are categories within a procurement framework, not projects. Exclude.

Boundary Cases:

• Named project vs generic activity: “Our ISO 27001 implementation project” is borderline. If the project has a specific name, extract it. If it is just described generically, exclude it.
• Contract as project: A named contract can be a project when the text discusses the delivery of that contract. The contract itself (as a legal document type, e.g., “service level agreement”) is not an entity.

---

3.9 sector

Definition: A named industry vertical, market segment, or client sector that the organisation operates in, delivers to, or has experience with.

The Test: “Is this a recognised industry classification or market segment? Could it appear as a category in a government procurement classification or SIC code grouping?”

Inclusion Criteria:

• Industry verticals (public sector, healthcare, education, financial services, defence)
• Government classifications (central government, local government)
• Market segments (housing, retail, manufacturing, energy)

Exclusion Criteria:

• Geographic regions (“England”, “European Economic Area”, “Wales”) — these are locations, not sectors. Exclude.
• Demographic descriptions (“vulnerable adults”, “children and young people”) — these describe service users, not sectors. Exclude.
• Social issues or topics (“county lines criminal exploitation”, “female genital mutilation”) — these are safeguarding concerns, not sectors. Exclude.
• Overly broad categories (“private sector”, if used as a catch-all rather than a meaningful classification) — still valid as a sector entity, but low value. Include with low priority.

Boundary Cases:

• “NHS” as sector vs organisation: NHS is an organisation. “Healthcare” is a sector. When the text says “we deliver to the NHS”, extract “NHS” as organisation. When it says “we work in the healthcare sector”, extract “healthcare” as sector.
• “Education” as sector vs generic word: In a sentence like “we provide education sector services”, “education” is a sector. In “staff education and training programmes”, it is a generic word. Context determines whether it is an entity.
• “Safeguarding” as sector vs capability vs concept: “Safeguarding” is a core domain in the Knowledge Hub. As a market segment (“we specialise in the safeguarding sector”), type as sector. As a specific named service offering (“we deliver safeguarding consultancy”), the specific service may be a capability. “Safeguarding” as a bare standalone concept should be excluded under Rule 5. “Designated Safeguarding Lead” is a role title — exclude under Rule 4, even though it is a statutory requirement (it describes a position, not a named entity).

---

3.10 product

Definition: A named commercial software product, platform, service package, or branded offering that the organisation (the document’s author or subject) creates, sells, or offers to clients.

The Test: “Is this a named thing that the organisation sells, licenses, or provides to its clients as a branded offering? Does it have a product name, a feature set, and a target customer?”

Inclusion Criteria:

• Named software products (Phew Audit System, Phew LMS, WordPress, SharePoint — when offered as a product to clients)
• Named platforms (Phew Cloud Platform, if such a thing existed)
• Named service packages with a distinct brand identity

Exclusion Criteria:

• Insurance product categories (“professional indemnity insurance”, “cyber liability insurance”, “public and products liability insurance”) — these are categories of insurance, not named products. Exclude.
• Service tiers or pricing elements (“standard support”, “premium support”, “set-up fee”) — these are pricing components, not products. Exclude.
• Generic software categories (“content management system”, “learning management system”) — these are categories, not named products. Exclude. Only extract the named product (WordPress, Moodle).
• Features of a product (“single sign-on”, “two-factor authentication”) — these are features, not products. Exclude.
• Internal tools used by the organisation but not sold to clients — type as technology if they are named commercial platforms, or exclude if they are custom internal tools.

Boundary Cases:

• Product vs technology: Products are things the organisation sells or offers. Technologies are things the organisation uses. Azure is a technology (infrastructure the org uses). Phew Audit System is a product (something the org sells). SharePoint can be either: technology when the org uses it internally, product when the org deploys it for clients.
• Phew LMS as product vs capability: “Phew LMS” is a named product. “Learning management” is a capability. Always prefer the specific named entity.

---

3.11 standard

Definition: A published, voluntary technical specification, code of practice, or normative document issued by a recognised standards body (ISO, BSI, W3C, IEEE, HL7) that defines requirements, guidelines, or characteristics for materials, products, processes, or services.

The Test: “Is this a specific, numbered document published by a standards body? Can I find it in a standards catalogue with a document number?”

Inclusion Criteria:

• British Standards (BS 5839, BS 5306, BS 5445, BS 5588, BS 6266, BS 3115)
• International standards referenced as documents (ISO 27001 — when discussing the standard’s content, not the certification held)
• Web standards (WCAG 2.1, WCAG 2.2)
• Healthcare data standards (HL7, FHIR)
• IEEE standards (IEEE 802.11)

Exclusion Criteria:

• Internal policies, even if they reference standards. “Clear Desk Policy” is not a standard. “Secure Development Policy” is not a standard. Apply Rule 3. Exclude.
• Contracts and agreement types (“non-disclosure agreement”, “service level agreement”, “data sharing agreement”, “confidentiality agreement”) — these are contract types, not published standards. Exclude.
• Cryptographic specifications (“AES-256”, “HMAC-SHA256”, “RSA-2048”) — these are algorithm specifications, not standards in the entity-extraction sense. Exclude.
• Protocols (“HTTPS”, “TLS 1.2”, “SSH”) — while some protocols are defined by standards bodies (TLS is defined in RFCs), protocol names in bid documents are not meaningful entities to extract. Exclude.
• Regulations with legal force (GDPR, Data Protection Act 2018) — these are regulations, not voluntary standards. Use type regulation.
• Frameworks (ITIL, COBIT) — these are management frameworks, not standards documents. Use type framework.

Boundary Cases:

• ISO 27001 as standard vs certification: See certification boundary cases. When discussing the document’s requirements, type as standard. When discussing holding the certification, type as certification. In bid documents, prefer certification.
• WCAG as standard vs regulation: WCAG is a published standard (by W3C). When a regulation mandates WCAG compliance (e.g., UK public sector accessibility regulations), WCAG remains a standard and the regulation is a separate entity.
• BS vs ISO numbering: “BS EN ISO 27001” and “ISO 27001” are the same standard. Canonicalise to the most commonly used form (usually the ISO number).
• “Industry best practice” is not a standard: Vague references to best practice are not extractable entities. Only extract specific, named, numbered standards.

---

3.12 methodology

Definition: A named, recognised approach, method, or delivery discipline for how work is planned, executed, or managed — a “way of doing things” that has an independent identity, a body of literature, and often a certification path.

The Test: “Is this a named approach to delivering work that has its own body of knowledge, published literature, or professional community? Could someone take a course in it?”

Inclusion Criteria:

• Project management methodologies (Agile, Scrum, Kanban, Waterfall, PRINCE2, Lean, Six Sigma)
• Development approaches (DevOps, DevSecOps, CI/CD — when discussed as methodological approaches, not as specific tools)
• Design approaches (Design Thinking, User-Centred Design)
• Security testing methodologies (OWASP Testing Guide — when used as a testing methodology rather than a framework reference)

Exclusion Criteria:

• Internal processes and procedures. “Staff Security Breach Process”, “Incident Response Process”, “Change Management Process” — these are internal procedures, not named methodologies. Apply Rule 3. Exclude.
• Internal policies mistyped as methodologies. “Clear Desk Policy”, “Rolling 30-Day Backup Policy”, “Secure Development Policy” — policies are not methodologies. Apply Rule 3. Exclude.
• Activities described as nouns (“data wiping”, “physical destruction”, “staff vetting”, “background checking”) — these are activities, not methodologies. Exclude.
• Security principles (“Principle of Least Privilege”, “Defence in Depth”, “Zero Trust”) — these are security design principles, not delivery methodologies. Exclude. (Previous prompt incorrectly listed “Principle of Least Privilege” as a methodology example.)
• Generic ways of working (“continuous improvement”, “risk-based approach”, “iterative development”) — these are descriptions of an approach, not named methodologies. Exclude unless they refer to a specific named methodology.
• Frameworks (ITIL, COBIT, NIST) — these are structured governance/assessment frameworks, not methodologies. Use type framework.

Boundary Cases:

• Agile as methodology vs generic adjective: When the text says “we use Agile methodology” or “our Agile delivery”, “Agile” is a methodology. When it says “we take an agile approach to…” (lowercase, generic), it is not a named methodology. Look for capitalisation and context.
• PRINCE2 as methodology vs framework: PRINCE2 is primarily a project management methodology (it tells you how to manage projects). It has a certification path, but its primary identity is as a methodology. Type as methodology.
• CIA Triad — not a methodology: The CIA Triad (Confidentiality, Integrity, Availability) is a security model/concept, not a delivery methodology. It was previously misclassified as methodology. Exclude — it fails the Named Entity Test (it is a concept, not a named methodology with a body of literature and certification path).
• DevOps as methodology vs culture: DevOps is borderline between a methodology and a cultural movement. When the text treats it as a named approach to delivery (“our DevOps methodology”), type as methodology. When it uses it generically (“a DevOps culture”), consider excluding.

---

4. Boundary Disambiguation Matrix

This matrix resolves the most common type confusions found in the S140 investigation. For each pair of confused types, it provides the decision rule.

4.1 framework vs capability

Signal	Decision
Published externally with independent identity	framework
Something the organisation does or offers to clients	capability
Internal policy, procedure, or process	EXCLUDE (not an entity)
Generic concept (information security, business continuity)	EXCLUDE (not an entity)

Rule: If it ends in “Policy”, “Plan”, “Procedure”, “Statement”, or “Register”, it is an internal document. Exclude it. Do not type it as either framework or capability. If it describes a generic field of practice rather than a named external framework or a specific named service, exclude it.

4.2 framework vs certification

Signal	Decision
An assessment scheme the organisation was assessed against and holds	certification
The management system implementing a certifiable standard (ISMS, QMS, EMS)	Prefer to extract the certification (ISO 27001), not the system
A set of published guidance principles for voluntary adoption	framework
A procurement framework (G-Cloud, DOS)	framework

Rule: If the entity has an issuing body that grants/revokes it after assessment, it is a certification. If it is a body of guidance that organisations choose to adopt, it is a framework.

4.3 framework vs regulation

Signal	Decision
Non-compliance carries legal penalties or enforcement action	regulation
Statutory guidance with legal force	regulation
Voluntary adoption with no legal consequences for non-compliance	framework

Rule: Legal force is the deciding factor. If a government or regulator can penalise non-compliance, it is a regulation. Everything else is a framework (if it meets the framework inclusion criteria) or should be excluded.

4.4 standard vs certification

Signal	Decision
Discussing the published document’s requirements or content	standard
Discussing holding, achieving, or maintaining the credential	certification
Ambiguous in a bid document context	Prefer certification

Rule: In UK SMB bid documents, ISO references are overwhelmingly about credentials held. When the context is ambiguous, default to certification.

4.5 standard vs regulation

Signal	Decision
Voluntary compliance, published by a standards body (ISO, BSI, W3C, IEEE)	standard
Mandatory compliance, enacted by a legislature or government body	regulation

Rule: Standards are voluntary. Regulations are mandatory. If compliance is legally required, it is a regulation regardless of who published it.

4.6 technology vs product

Signal	Decision
Infrastructure/tools the organisation USES internally	technology
Something the organisation SELLS or offers to clients	product
A named commercial platform either way (Azure, SharePoint)	Determine by context

Rule: Who benefits? If the organisation’s own staff use it, it is technology. If the organisation’s clients use it, it is product. The same platform (e.g., SharePoint) can be either depending on context.

4.7 technology vs standard

Signal	Decision
A named commercial platform, tool, or service	technology
A protocol, file format, or encoding convention	EXCLUDE (neither)
A published specification document from a standards body	standard

Rule: Protocols (HTTPS, SSH, TLS), file formats (PDF, CSV), and algorithms (AES-256) are typically not meaningful entities in bid documents. Exclude them. Only extract as standard if the text specifically discusses compliance with the published specification document.

4.8 capability vs methodology

Signal	Decision
WHAT the organisation does (a service or competency)	capability
HOW the organisation does it (an approach or method)	methodology
A generic concept or activity	EXCLUDE (not an entity)

Rule: Capabilities are services; methodologies are approaches. “Penetration testing” (as a named service) is a capability. “Agile” (as an approach to delivery) is a methodology. “Data wiping” (as a generic activity) is neither — exclude it.

4.9 person vs (exclude)

Signal	Decision
Actual personal name (given name + surname)	person
Job title or role description	EXCLUDE
Name embedded in a descriptive string	Extract only the name as person

Rule: If it is a name, it is a person. If it is a title, exclude it. If it is a name with a title attached, extract just the name.

4.10 product vs (exclude)

Signal	Decision
Named software, platform, or branded offering	product
Insurance product category (professional indemnity, cyber liability)	EXCLUDE
Service tier or pricing element (standard support, set-up fee)	EXCLUDE
Generic software category (CMS, LMS)	EXCLUDE

Rule: Products must be named, branded things that can be looked up. Generic categories, insurance types, and pricing tiers are not products.

4.11 standard vs (exclude)

Signal	Decision
Numbered document from a standards body (BS 5839, WCAG 2.1)	standard
Contract type (NDA, SLA, DPA)	EXCLUDE
Internal policy (clear desk policy, secure development policy)	EXCLUDE
Cryptographic algorithm (AES-256, HMAC-SHA256)	EXCLUDE

Rule: Standards must be published, numbered specifications from recognised standards bodies. Contracts, policies, and algorithm names are not standards.

4.12 methodology vs (exclude)

Signal	Decision
Named approach with its own literature and community (Agile, Scrum, Lean)	methodology
Internal process or procedure	EXCLUDE
Security principle (Least Privilege, Defence in Depth)	EXCLUDE
Generic activity (data wiping, background checking)	EXCLUDE

Rule: Methodologies must be named approaches that someone could study, train in, or certify against. Internal processes, security principles, and generic activities are not methodologies.

---

5. Quick Reference Table

Type	One-line definition	The Test (key question)	Most common confusion
organisation	Named legal entity, government body, or institution	Does it have a legal registration or official standing?	Confused with sector (NHS vs healthcare)
certification	Credential held after independent assessment	Can it be granted, revoked, and renewed by an issuing body?	Confused with standard (ISO 27001)
regulation	Law or statutory guidance with legal force	Does non-compliance carry legal penalties?	Confused with framework (statutory guidance)
framework	Published external guidance for voluntary adoption	Is it externally published and voluntarily adopted?	Confused with internal policies (EXCLUDE)
capability	Named service offering or client-facing competency	Would the org list this on its website as a service?	Confused with internal policies (EXCLUDE) and generic concepts (EXCLUDE)
person	Named individual identified by personal name	Is this a person’s actual name, not a job title?	Confused with role titles (EXCLUDE)
technology	Named commercial platform, cloud service, or tool	Can it be purchased, subscribed to, or downloaded?	Confused with protocols/formats (EXCLUDE)
project	Named piece of work with defined scope and timeline	Does it have a project name and a start/end?	Confused with locations and generic activities
sector	Named industry vertical or market segment	Is it a recognised industry classification?	Confused with geographic regions (EXCLUDE)
product	Named branded offering sold to clients	Is it a named thing the organisation sells?	Confused with insurance categories (EXCLUDE)
standard	Published numbered specification from a standards body	Can I find it in a standards catalogue with a document number?	Confused with contracts (EXCLUDE) and policies (EXCLUDE)
methodology	Named approach with its own literature and community	Could someone take a course in this approach?	Confused with internal processes (EXCLUDE) and security principles (EXCLUDE)

---

6. Entity Type Decision Flowchart

Apply these checks in order for any candidate entity:

1. Is it a specific, named thing? (Rule 1)
   NO  -> EXCLUDE
   YES -> continue

2. Could someone outside this organisation look it up? (Rule 2)
   NO  -> EXCLUDE (likely internal document/process)
   YES -> continue

3. Does the name end in Policy/Procedure/Plan/Process/Register/Schedule/Agreement/Statement? (Rule 3)
   YES -> Is it statutory guidance with legal force?
          YES -> regulation
          NO  -> EXCLUDE
   NO  -> continue

4. Is it a job title or role description? (Rule 4)
   YES -> EXCLUDE
   NO  -> continue

5. Is it an abstract concept or generic activity? (Rule 5)
   YES -> EXCLUDE
   NO  -> continue

6. Apply per-type tests (first match wins — ordering is intentional and
   reflects bid-document context where certifications are more relevant than
   standards, and regulations take precedence over frameworks):
   - Legal force? -> regulation
   - Credential from assessment? -> certification
   - Published standards body document? -> standard
   - External guidance for voluntary adoption? -> framework
   - Named commercial platform/tool the org uses? -> technology
   - Named branded offering the org sells? -> product
   - Named approach with literature/community? -> methodology
   - Named service the org offers to clients? -> capability
   - Named legal entity or institution? -> organisation
   - Named industry vertical? -> sector
   - Named project with scope/timeline? -> project
   - Named individual by personal name? -> person

---

7. Eval Anchors

These are specific entities from the S140 investigation data that represent ground truth. Any eval suite or prompt change must correctly handle these.

Must be EXCLUDED (true negatives)

Entity name	Wrong type assigned	Reason for exclusion
Information Security Policy	framework, capability	Internal policy (Rule 3)
Acceptable Use Policy	framework, capability	Internal policy (Rule 3)
Business Continuity Plan	framework	Internal policy (Rule 3)
Data Protection Policy	framework	Internal policy (Rule 3)
Clear Desk Policy	methodology, standard	Internal policy (Rule 3)
Secure Development Policy	methodology, standard	Internal policy (Rule 3)
Incident Response Plan	framework	Internal policy (Rule 3)
Data Retention Schedule	framework	Internal policy (Rule 3)
Data Processing Agreement	framework	Contract type (Rule 3)
Records of Processing Activity	framework	GDPR document type (Rule 2)
Managing Director	person, capability	Role title (Rule 4)
Client Project Lead	person	Role title (Rule 4)
Data Protection Officer	capability	Role title (Rule 4)
information security	framework, capability	Generic concept (Rule 5)
business continuity	capability	Generic concept (Rule 5)
regulatory compliance	framework	Generic concept (Rule 5)
data protection	regulation, capability	Generic concept (Rule 5)
encryption	capability	Generic concept (Rule 5)
HTTPS	technology, standard	Protocol (Section 3.7 exclusion)
SSH	technology	Protocol (Section 3.7 exclusion)
PDF	technology	File format (Section 3.7 exclusion)
AES-256	technology, standard	Cryptographic algorithm (Section 3.7 exclusion)
professional indemnity insurance	product	Insurance category (Section 3.10 exclusion)
non-disclosure agreement	standard	Contract type (Section 3.11 exclusion)
consent (lawful basis)	framework	GDPR legal concept (Section 3.3 exclusion)
Designated Safeguarding Lead	capability	Role title (Rule 4) — statutory requirement but not an entity
data protection impact assessment	methodology	GDPR artefact (Rule 2)
privacy by design	methodology	GDPR concept (Rule 5)
principle of least privilege	methodology	Security principle (Rule 5)
user acceptance testing	methodology	Generic activity (Rule 5)
Staff Security Breach Process	methodology	Internal process (Rule 3)
online training	capability	Generic description, not named service (Rule 5)
cyber security awareness training	capability	Internal activity, not client service (context-dependent)

Must be CORRECTLY TYPED (true positives)

Entity name	Correct type	Disambiguation note
ISO 27001	certification (in bid context)	standard when discussing requirements
Cyber Essentials Plus	certification	Distinct from Cyber Essentials
GDPR	regulation	Not a generic concept
Data Protection Act 2018	regulation	UK domestic legislation
Working Together to Safeguard Children	regulation	Statutory guidance with legal force
OWASP	framework	Organisation when discussing OWASP-the-body
G-Cloud 14	framework	Procurement framework
ITIL	framework	Service management framework
NCSC 10 Steps to Cyber Security	framework	NCSC guidance framework
Agile	methodology	Named approach with literature
PRINCE2	methodology	Project management methodology
Scrum	methodology	Delivery methodology
Microsoft Azure	technology	Cloud platform
Active Directory	technology	Named software product
SharePoint	technology	Named software product
BS 5839	standard	British Standard document
WCAG 2.1	standard	W3C published standard
NHS	organisation	Government body
ICO	organisation	Regulatory body
BSI	organisation	Standards body
Phew Audit System	product	Named software product sold to clients
Matthew Burgess	person	Named individual
public sector	sector	Industry classification
healthcare	sector	Industry classification
PRINCE2	methodology	Project management methodology
Education Inspection Framework	framework	Ofsted’s EIF
Prevent Duty	regulation	Counter-terrorism statutory duty
PPN 06/20	regulation	Procurement Policy Note with legal force

---

Appendix A: Change Log

Version	Date	Changes
1.0	01/04/2026	Initial version. All 12 types defined with inclusion/exclusion criteria, boundary cases, and disambiguation rules. Based on S140 investigation covering 1,076 entity mentions across 586 distinct names.
1.1	01/04/2026	Adversarial verification fixes: Added “Process” to Rule 3 suffixes. Added statutory allowlist with 5 named exceptions. Added safeguarding boundary case to sector. Added training boundary case to capability. Added “first match wins” to flowchart. Extended eval anchors (+9 true negatives, +4 true positives). Removed “Statement” qualifier. Added “Designated Safeguarding Lead” as true negative.

Appendix B: Related Documents

Document	Relationship
docs/audits/classification/classification-investigation-report.md	Root cause analysis that informed this spec
docs/audits/classification/classification-framework-analysis.md	Framework entity deep dive (52 entities assessed)
docs/reference/classification-prompt.md	Python pipeline prompt (must be updated to match this spec)
lib/ai/classify.ts	TS pipeline (tool schema must be updated to match this spec)
lib/ai/skills/classification.md	TS skill file (must be updated to match this spec)
.planning/.archive/.specs/classification-entity-cleanup-spec.md	Existing data cleanup tasks (archived S151 — superseded by ai-eval-phase2-classification-skill-spec.md)
lib/validation/schemas.ts	VALID_ENTITY_TYPES constant (12 types)

Appendix C: Superseded Definitions

This spec supersedes the following entity type definitions:

1. TS tool schema type.description in lib/ai/classify.ts line 251 — the single string containing all 12 type descriptions. Key corrections:

   • “capability: includes internal policies” is WRONG. Internal policies are not entities.
   • “technology: general technology categories (cloud computing, AI, blockchain)” is WRONG. Generic categories are not technologies.

2. TS inline prompt in lib/ai/classify.ts lines 388-397 — duplicates the tool schema guidance with the same errors.

3. TS skill file lib/ai/skills/classification.md lines 30-38 — brief type distinctions that lack exclusion criteria.

4. Python prompt docs/reference/classification-prompt.md lines 545-610 — closest to correct but still missing exclusion guidance for most types beyond framework. The Entity Type Exclusions and Framework vs Policy Distinction sections are good but incomplete.