How to adopt the taxonomy in practice: data governance, data structures and fields, classification process and software design, migration from existing systems, and organisational factors.
Knowing what the noslegal taxonomy contains is one thing; implementing it successfully is another. This chapter addresses the practical and organisational considerations involved. Sections 5.1 to 5.4 cover the technical foundations. Sections 5.5 to 5.8 address the human and organisational factors that determine whether an implementation succeeds or stalls. Chapter 6 then addresses how to apply the taxonomy across the four areas of need.
Data governance is the framework of decisions, policies, accountabilities and practices that determine how data is created, classified, maintained and trusted over time. It is the organisational infrastructure that makes the difference between a taxonomy that is applied consistently and supports decision-making, and one that exists only as a conceptual model alongside day-to-day practice.
A major reason legal organisations struggle with data quality is not that they lack the right software. It is that accountability for data has never been clearly defined. This lack of clarity creates a risk of the data falling between functions and individuals. Challenges with data management or data quality are then addressed reactively when something goes wrong (often by those with least authority to stop the problem happening again) rather than proactively as a matter of organisational design. For noslegal purposes, the following governance issues deserve particular attention.
Data should be treated as an organisational asset, not the property of a particular team. But within that, clarity is needed on who is accountable for the quality of specific data sets (data owners) and who has day-to-day responsibility for maintaining that accuracy (data stewards). This distinction matters. Data Owners are accountable for outcomes: where the data is trusted and used, and for cross-team collaboration. Data Stewards are responsible for day-to-day mechanics: how classifications are applied, reviewed, and corrected.
In a legal services provider, data ownership should sit with senior leaders who have the authority to ensure sufficient priority and appropriate resources are devoted to the topic (for example, partners managing each practice group and senior managers within knowledge, business development and human resources). Depending on the organisation, stewardship for matter data might sit with someone in practice management or a specialist business services role.
In an in-house team, ownership should sit with the general counsel or a sufficiently senior director of legal operations. Stewardship will likely sit with someone else in a legal operations role.
In a technology company building on noslegal, ownership and stewardship should be designed into the product team from the outset (for example, with the head of product or head of legal content as owner).
Start by identifying which data points matter most: those that flow between systems, appear in reporting, or are shared with clients or other organisations. For noslegal purposes, the critical data points are the taxonomy classifications themselves (work type, area of law, sector, place and role).
Standards do not need to be complex; they should define what "good enough" looks like for the decisions the data supports, which combinations are implausible, and how errors are detected and corrected. Precision is more valuable than exhaustiveness.
A recurring failure mode is treating data governance as a set of operational tasks (fixing individual errors, running periodic clean-up exercises) without any strategic framework to prevent those errors recurring. Effective governance requires decisions at multiple levels: what data do we need and why; how should it be structured and governed; and who does what, when and how. A taxonomy implementation is an opportunity to establish this kind of explicit decision making structure about what data the organisation needs, how it should be structured and governed, and who is responsible at each stage of its lifecycle, not just to classify data.
The instinct to begin a data governance initiative by drafting a policy document is common but rarely sufficient. Building a community of people who understand and care about data quality across the functions that generate and use it tends to produce more durable results (often called "bottom-up data governance"). This is particularly true in legal organisations, where the individuals with the most influence over data quality are often hard to reach through formal policy alone. Documentation still matters, but it is most effective when it codifies practices people already understand and support, rather than attempting to impose behaviour in isolation.
A taxonomy provides a structured vocabulary for describing legal work but does not by itself determine how it is used in practice. That is the role of data structures: the design of the fields, records and schemas that capture information about the things your organisation works with and wants to understand. Important examples in a noslegal context include matters, clients (for legal services providers) and providers (for in-house teams), documents and other knowledge assets, credentials and individual experience records.
Each of these needs a defined set of fields that together describe it adequately. Some fields will draw directly on the noslegal taxonomy (a matter record should include fields for work type, areas of law and roles, for example). Others will have nothing to do with taxonomy (client name, matter number, responsible individuals, fee arrangements, opening and closing dates, financial data). Both are equally important parts of the data structure.
This distinction matters because treating taxonomy adoption as synonymous with data structure design risks overloading the taxonomy with too much detail, while under-designing the data structure by focusing only on classification fields.
Before defining fields, be clear about what questions the data structure needs to answer. Fields and their constraints (mandatory or optional, single or multiple values, taxonomy-based or free text) should follow from those purposes rather than from a general instinct to capture as much as possible. A smaller number of accurately populated fields is almost always more valuable than a larger number applied inconsistently.
One of the principal benefits of a shared taxonomy is that the same concepts appear in multiple data structures: matter, knowledge and people records can all reference the same work type and area of law concepts, making it possible to connect experience, knowledge and work without extensive manual mapping. This benefit is only realised if the fields drawing on the taxonomy are designed consistently across structures. What matters most is avoiding ambiguity in what is being captured. A field called "jurisdiction", for example, used to mean governing law in one context, dispute resolution forum in another and asset location in a third, will produce data that is unreliable for any purpose.
Well-designed taxonomy and data structures achieve little if the process and software by which classifications are captured and maintained are ineffective.
Classifying a matter upon opening, and rarely revisiting it, creates several compounding problems. At the moment of opening, relatively little may be known about the matter's nature. The person completing the opening form is frequently not the person with the best knowledge of the matter, and their primary motivation is to open the file quickly so that work can begin. Classifications made in these circumstances are often inaccurate, incomplete or defaulted to whatever has been used before. If classification data is then buried in a finance or matter management system that fee earners cannot easily see, there is no natural prompt to correct it.
Deliberate process redesign is needed rather than hoping people will classify more carefully. Practical approaches include the following.
Process design and software design are closely linked. Points worth bearing in mind include the following.
The benefits just described will not arrive automatically from having a well-classified corpus. The taxonomy has to be deliberately incorporated into system design: used as a filter in retrieval pipelines, referenced in the prompts that instruct the model and applied as a framework for evaluating and correcting AI outputs. Treat this as an explicit design requirement.
Most organisations implementing noslegal will not be starting from scratch. They will have existing systems containing classification data of some kind, and existing taxonomies or controlled lists that have been in use for years.
The systems themselves can remain in place. One of the things noslegal provides is a semantic layer: a common reference point that allows existing systems to be interpreted against each other, even if they were built and configured independently. That said, organisations implementing new software will find that transition the lowest-friction opportunity to embed noslegal, typically easier than retrofitting it later.
The most effective starting point is to adopt noslegal as the foundation and extend it, adding further levels of detail and additional fields to meet specific needs, rather than designing a private taxonomy from scratch and then attempting to map it to noslegal retrospectively. This approach reduces initial effort significantly, makes it easier and less costly to exchange data with other organisations that have also adopted noslegal, and simplifies the incorporation of future updates as the taxonomy evolves.
Some organisations will have factors (existing contractual commitments, legacy systems that cannot easily be reconfigured, or internal constraints) that make rapid full adoption impractical. Partial adoption combined with deliberate mapping is a productive alternative. Mapping documents the relationship between your existing concepts and the corresponding noslegal concepts. It is usually an approximation, but even an imperfect mapping consistently applied allows data created under a private taxonomy to be interpreted against noslegal-classified data. As noted in section 3.5, the most important level to map to is the second level of the Work types and Areas of law facets.
If your existing concepts lack explicit definitions, this is an opportunity to adopt the noslegal definitions where possible. If you have existing definitions, consider honestly how well they are applied in practice and whether they offer any material advantage over the noslegal equivalents. If not, the benefits of alignment suggest adopting the noslegal definitions even if internal labels remain different.
A full retrospective reclassification of large volumes of historical data is rarely a productive use of time. A mapping approach that translates data, even imperfectly, is typically a better choice. Simple find-and-replace approaches can help in some contexts, and language model tools can assist with reclassification where there is sufficient data to make this meaningful, subject to appropriate human supervision. Bear in mind that older matter data becomes progressively less relevant for most reporting and knowledge purposes: the value of reclassification should be assessed accordingly.
Adopting a shared taxonomy creates conditions for inter-organisation interoperability. Where clients, law firms and technology providers describe legal work using a common vocabulary, it becomes easier to exchange information and integrate workflows across organisational boundaries. The benefits are likely to compound over time, and an organisation that invests in alignment now, even partially, will be better positioned to realise them.
Before taking significant decisions, it is important to understand how data currently works across your organisation: how it flows (or should flow) across the four areas of need, what software applications and databases support those areas, and how they can feasibly be joined up. In a large organisation, relevant data is unlikely to be owned or managed by a single team, making a clear picture of the current state essential.
The following questions provide a framework for that diagnostic exercise. The answers will shape both the approach taken and the order in which things are tackled.
There tend to be three main barriers to implementation. Each is real but manageable with the right approach.
This is usually the hardest barrier and deserves the most attention.
Building a business case. Successful change projects in this area need enthusiastic top management support: to make the necessary resources available, to communicate the importance of the work, and to address resistance. The business case is strongest when it connects to problems your organisation has already encountered (time wasted searching for information, pricing decisions made without relevant data, missed opportunities to demonstrate credentials) and expresses these in financial terms with concrete examples.
Framing the initiative effectively. Anchoring the taxonomy initiative to goals that already have visible support tends to attract broader backing. Knowledge reuse, financial performance and AI readiness are three areas where the connection is direct and easy to articulate. Framing the initiative in these terms, rather than as a data or classification project in its own right, resonates more widely than leading with the technical case.
Winning hearts and minds across the organisation. Helping individuals understand how better data will benefit them personally is often harder than making the case at senior level, but matters just as much. This means holding workshops, circulating clear messaging, and ensuring senior leaders are visibly on board. Having a short, repeatable summary that members of the implementation team can deploy whenever the opportunity arises is practically valuable. Involving enthusiastic stakeholders directly in conversations with senior management tends to be more persuasive than a single specialist function making the case alone.
Converting sceptics. Do not underestimate the value of bringing doubters close to early successes. Someone who was initially resistant and came to see the benefits, particularly if respected within the organisation, can be a more compelling advocate than someone who was supportive from the start. In legal organisations, where people engage seriously with abstract concepts, resistance sometimes reflects a deep commitment to an existing way of conceptualising things, or unstated concerns that a taxonomy change signals some unwanted organisational shift. Senior management commitment provides the authority to work through this constructively. Use concrete data to address demands that would increase the risk of bad data through conceptual redundancy or unnecessary complexity.
Starting in a focused way. It is rarely necessary or advisable to attempt a full implementation at once. After a reasonable period (say, a year), review classification data and seek permission to remove concepts that are barely used, whether measured in financial terms (for matter classification) or knowledge terms (number of documents classified). Demonstrating the problem objectively in this way tends to be more persuasive than arguing about it in the abstract at the outset. This process can usefully be repeated on a regular cadence, for example every year or two.
Most organisations are not starting from scratch on technology, and constraints arising from existing systems can be real. noslegal has been designed with this in mind: its modest size, clear faceting, limited levels and modularity are intended to make it implementable across a wide range of software environments without requiring specialist infrastructure.
Practical constraints (limitations on field numbers, character limits, restrictions on hierarchy levels) will still arise. Address these by making realistic decisions about how much can be accurately captured within the tools available. Process, communication and training can often compensate for software limitations more than people expect. There is practical experience of navigating these constraints within the noslegal community.
Understanding how to get to grips with your data, and then actually doing it, takes imagination, focus and sustained effort. Smaller organisations are unlikely to have a specialist taxonomist or data officer and will typically need to identify someone who can take on this responsibility alongside other work, or bring in external help. Larger organisations face a different version: additional organisational complexity, entrenched silos and difficulty coordinating across functions that have historically operated independently.
In either case, meaningful investment is required, whether by redirecting existing people, creating a new role or engaging a consultant with relevant experience. The skills most relevant to this work combine legal domain knowledge, an understanding of data structures and the organisational credibility to bring different functions along. These are not always found in the same person, which is worth bearing in mind when assembling a team.
Waiting for perfect conditions (the ideal software, full stakeholder buy-in, a clean data set, no competing initiatives) means not getting started at all. Some practical guidance on moving forward and sustaining progress:
Test and iterate. When rolling out a new taxonomy, pay close attention to the ways it can go wrong: in the concepts themselves, in training, in process or in software. Test data quality regularly, find out how people are feeling about it, and identify weaknesses so they can be addressed. Better process can improve data quality even where the available software is not ideal.
Investigate informally first. Exploring relevant topics across different functions informally before committing to major decisions builds a strong foundation and surfaces inconsistencies that are often accidental, resulting from a simple absence of communication rather than any deep disagreement. This may take many months but is time well spent.
Manage expectations carefully. Be realistic about what is achievable in the short term. Deliver some fairly quick wins while being clear about what will not be possible immediately and how genuine needs will be addressed in future. People are more willing to invest in a process they see delivering incremental benefits, provided it has a clear plan and direction.
Implementing a taxonomy successfully is not something most organisations need to do entirely on their own. The noslegal community includes lawyers, knowledge and data professionals, technologists and legal business specialists from a range of organisations, many of whom have direct experience of the challenges described in this chapter and are open to sharing it.
If you are working through implementation questions (whether about taxonomy design, software constraints, change management or mapping from an existing system) engaging with the community is likely to be worthwhile. Community members can be reached via the noslegal website and LinkedIn presence.