Before you author a job description, evaluate a role, or set a pay range, the taxonomy has to exist. Job Architecture in CompBldr gives every title a governed family, grade, code, and structural address, so every downstream decision starts from the same foundation.

of HR leaders report inconsistent job titles and levels across departments or regions
of compensation decisions are influenced by informal leveling rather than a governed framework
higher internal pay equity risk when job families and grades are not formally defined
Job Architecture is the setup layer that sits before job authoring, evaluation, and compensation planning. It defines the taxonomy, grading logic, and mapping rules that make every downstream workflow consistent, searchable, and audit-ready.
Define the top-level structure of your organization's roles: job families like Engineering or Human Resources, broken into sub-families like DevOps or Software Engineering. Every title has a precise taxonomy address before it is authored.
Build grade bands with minimum and maximum JESAP score ranges. Every role falls into a grade determined by its evaluation score, not manager judgment. The grading framework supports up to 12 levels with structured score boundaries between each.
Assign every role a structured code: family prefix, grade indicator, and sequence number. Job codes make titles uniquely identifiable across JobBldr, Job Evaluation, and Compensation Planning without manual cross-referencing.
The Grade Title Matrix is the synthesis view that maps every title across families, sub-families, and grade levels in one place. Three display modes, Detailed, Compact, and Grid, give administrators, HR, and Finance the right level of detail for their use case.
CompBldr's Compensation Planner gives HR and Finance a single system to run the entire compensation cycle from building the cycle and allocating budgets to manager proposals, approvals, and employee reward statements.
Job Family is the highest-level classification in the architecture model. Each family represents a broad capability domain: Engineering, Product Management, Human Resources, and Finance. Sub-job families add precision within each domain, DevOps and Software Engineering under Engineering, for example, and track how many positions are already mapped to each branch.

Job Groups provide an operational organizing layer that sits alongside the family taxonomy. Where families classify by broad capability, groups cluster titles by practical work domain: API Engineering, Backend Development, Full Stack Development, and HR Administration. Groups help teams find, filter, and report on related roles without relying solely on family structure.

Job Grades define the evaluation bands that roles fall into after scoring through the JESAP framework. Each grade has a minimum and maximum job score, creating a structured scale that removes ambiguity from leveling decisions. The grading framework in CompBldr supports up to 12 grades with configurable score boundaries between each level.

Job Codes uniquely identify each role across the entire architecture. A structured code like ENG-FSD-G1-001 encodes the family (ENG), sub-family (FSD), grade (G1), and sequence number (001) into a single identifier. This makes every title machine-readable, searchable, and reusable across JobBldr, Job Evaluation, and Compensation Planning without manual lookup.

The Grade Title Matrix is the synthesis layer of Job Architecture. It combines job families, sub-families, grade levels, and all mapped titles into a single grid, so administrators can see exactly how the organizational role structure is assembled, where gaps exist, and which titles are unassigned. It is the view that makes the architecture operational rather than theoretical.

Job Architecture is not a collection of admin settings. It is a structured setup workflow where each component builds on the last, and the Grade Title Matrix ties them all together into one governed role taxonomy that powers everything downstream.
Define the broad capability domains that organize your organization's roles at the top level: Engineering, Product Management, Human Resources, and Finance. Every title belongs to one.
Break each family into more precise capability areas: Software Engineering and DevOps under Engineering; HRBP and Talent Acquisition under Human Resources. Sub-families track position count and link directly to job codes.
Create operational clusters that group related roles by work domain: API Engineering, Backend Development, and Full Stack Development. Groups give teams a practical filter layer for searching and reporting on related titles.
Build the score-based grading framework. Set minimum and maximum JESAP score ranges for each level. Roles are placed into grades by evaluation score, not manager judgment. The framework versions on every save.
Assign every role a structured identifier that encodes its family, sub-family, grade, and sequence. Job codes make every title uniquely referenceable across JobBldr, Job Evaluation, and Compensation Planning.
The Grade Title Matrix combines all five components into one governed architecture view. Every title is visible across its family, sub-family, and grade. Gaps are surfaced. JobBldr consumes this structure the moment a user begins authoring a job description.
These are the outcomes teams see when they replace ad-hoc title creation and informal grading with a structured, governed architecture that connects every role to a taxonomy, a grade, and a code.
Most organizations let job titles accumulate without a governed taxonomy. Families are invented ad hoc, grades are assigned by feel, and no single view shows how the full role structure fits together. Here is what that costs, and what governed job architecture delivers instead.
Job architecture software is a platform that defines and governs the structural taxonomy behind an organization's roles: job families, sub-families, grades, groups, and codes. In CompBldr, Job Architecture is the setup layer that ensures every job description, evaluation, and pay decision starts from a governed foundation.

A job family is the top-level classification grouping roles by broad capability domain, Engineering, Product Management, and Human Resources. It matters because every downstream decision, from job description authoring to compensation benchmarking, depends on roles being organized into a consistent, searchable taxonomy rather than created in isolation.

A job grade is a level band with a minimum and maximum JESAP evaluation score range. Roles are placed into grades based on their JESAP score, not manager judgment. CompBldr supports up to 12 grades with configurable score boundaries. Every grade configuration is versioned and timestamped.

The Grade Title Matrix is the synthesis view of Job Architecture. It maps every job title across families, sub-families, and grade levels in one grid. Administrators use it to see the full role taxonomy, identify structural gaps, and confirm that every title has a governed family, grade, and code assignment before authoring begins.

A job code is a unique structured identifier for each role: family prefix, sub-family code, grade indicator, and sequence number, for example, ENG-FSD-G1-001. Job codes make titles uniquely identifiable and reusable across JobBldr, Job Evaluation, and Compensation Planning without manual cross-referencing or duplicate title management.

Job families classify roles by broad capability domain and form the foundation of the taxonomy. Job groups cluster titles by practical operational work domain, API Engineering and Backend Development—and sit alongside the family structure as an additional filter layer for searching, reporting, and organizing related roles.

JobBldr draws family, sub-family, grade, and code values directly from Job Architecture when a user authors a job description. Job Evaluation references grade ranges to validate JESAP scores. Compensation Planning uses family and grade data to apply merit matrix guidelines and pay range assignments. All modules read from the same governed architecture.

Yes. Job grades can be edited and the framework can be versioned. Each version is saved with the editor's name, timestamp, and a review step before publishing. Titles already assigned to a grade are not automatically regraded. Changes to grade boundaries are reviewed and applied deliberately, not automatically pushed downstream.

CompBldr Job Architecture supports an unlimited number of job families and sub-families. The grading framework supports up to 12 grade levels with configurable score ranges between each. The Grade Title Matrix scales to show all families and grades in a single view with search, filter, and jump-to-family navigation for large taxonomies.

Job Architecture gives every title in your organization a governed family, grade, code, and structural address before any job description is authored, any role is evaluated, or any pay decision is made. When the foundation is right, everything built on top of it is more defensible.