Structural request review

Structural Request Review turns a request to open new organizational units into a scored governance decision. An HR administrator uploads a file describing the proposed unit(s), and Jadiroon's AI evaluates the whole proposal against a customizable rubric — the same idea as the internal-mobility fit score, applied to org design. The result is a single verdict: Returned for rework, Approved with conditions, or Approved, with a per-factor breakdown, a confidence range, and concrete reasons.

Request types: Create, Merge, Abolish

Every request is one operation, chosen first, before you pick how you'll submit it: Create (إنشاء), Merge (دمج), or Abolish (إلغاء). Each operation has its own guided form, its own downloadable Word template, and its own AI assessment framing — but all three share the same scoring engine, persistence, and report shell described in the rest of this page.

• Create — open one or more brand-new units. See Creating new units below; this is the flow the rest of this page documents in detail.
• Merge — fold two or more existing units into one. The intake captures the source units (picked from your live org tree, at least two), the resulting unit — either an existing unit that absorbs the sources or a brand-new merged unit — an overlap map pairing each duplicated task with the source units that currently own it, the roles retained in the resulting unit plus how many vacant and occupied posts are removed, and a saving breakdown (supervisory posts removed, duplicate posts removed, recurring annual saving, one-time transition cost).
• Abolish — retire one or more existing units. The intake captures the target unit(s), the abolish type — full (the mandate is obsolete) or transfer (the mandate moves elsewhere) — a residual-mandate plan mapping every responsibility, KPI, and obligation to a named receiving unit (required for transfer), a no-orphan attestation confirming nothing is left unaccounted for, and the cost reduction the abolition produces.

A baseline before the verdict

For Merge and Abolish, the AI first reads the current state of the affected units — using the same live-tree tools it uses for scoring — across the five factors, and reports that baseline before presenting its verdict. The report then argues the change against that baseline rather than in the abstract, honoring the framework's principle that a structural decision is defended by a score, not asserted.

How the five factors read differently per operation

The same weighted rubric applies to all three operations, but Merge and Abolish read each of the five factors — and the two impact lenses — differently than Create:

Beyond the five weighted factors, the report narrates two further impact lenses for Merge and Abolish, same as it does for Create:

• Structural lens — for Merge, generally positive (fewer levels, clearer reporting lines, duplication removed), flagged if the resulting unit now spans previously separate work streams and adds coordination complexity. For Abolish, removing a box or level simplifies reporting, flagged if any relationship or coordination is left without an owner.
• Financial lens — for Merge, reads as a saving: supervisory and duplicate posts removed, minus one-time transition cost; vacant-post removal counts as clean saving, occupied-post removal is conditional on redeployment. For Abolish, reads as a cost reduction net of the receiving unit's absorption cost — the abolished unit's full cost is never booked as pure saving; occupied-position and pay effects route to HR, legal-basis questions route to legal affairs.

A Word template per operation

The Use template file path generates a different .docx layout for each operation — Create, Merge, and Abolish templates each mirror their own guided form field-for-field, so a request drafted in Word scores exactly like the same request typed into the matching manual form. The template you download is the one for the operation you picked in step one.

Two ways to start a request

From Plan → Structural requests → New request, the administrator picks one of two entry paths. Both converge on the same scoring and report — pick whichever fits how the request originated.

• Use template file — download the generated Word form, fill it offline (or hand it to whoever drafted the request), and upload it back. Best when the request already exists as a document, or was drafted by someone without platform access.
• Manual entry — fill a guided in-platform form directly, with live pickers instead of typed references and two AI-assist buttons. Best when you're originating the request yourself and want the fastest path to a score, with no file to produce or exchange.

How it works

The flow has four stages:

1. Start the request — choose Use template file or Manual entry.
   • Template file: the administrator downloads the Word request form (.docx) generated for this workspace. Its dropdowns are pre-filled with your current org units (for parent and reparenting), the organizational tiers, your existing job descriptions, and your pay grades — so the form always reflects your live structure. There is one form per language.
   • Manual entry: the administrator fills the same governance questionnaire directly in the app — see Manual entry below.
2. Provide the request — Template file: describe the proposed unit(s) — organizationally and functionally — in the form, then upload it. One form may propose several units (copy the "Unit" block to add more). You can also upload a free-form document (.pdf / .txt / .xlsx / a non-template .docx) and the AI will read its text directly. Manual entry: fill the guided form. Either way, scoring starts immediately — there is no separate review-and-edit step; the request goes straight from upload (or form submission) to the assessment. If the file carries no assessable content, or the AI judges it isn't a valid structural request, you get a plain-language message explaining why, so you can fix it and try again.
3. Score — the whole proposal is scored as one governance decision. The AI uses live tools to navigate your current structure on demand — reading the whole tree, a unit's subtree or ancestors, and job descriptions with their attached salaries — then assesses each factor across all the units together. A deterministic weighted calculation turns those into the 0–100 score, so the number is reproducible and the AI never emits it.
4. Report — a saved, shareable organizational study: the verdict band, the score with its confidence range, the per-factor breakdown, a placement-in-structure chain, an overlap-with-existing-units table, separate structural and financial impact narration (with a span before/after readout), a pros / reservations / risks breakdown, follow-up initiatives, the issues found in the request, and routing flags for the next approving authority. The report is viewable in-app and downloadable as a PDF.

If you leave the request title blank on either path, the platform generates one automatically once the request is scored, from the units and the verdict — you never have to name the request yourself before you know what's in it.

The report carries a dedicated Financial impact panel, computed deterministically from the confirmed units (never AI-derived): the total added annual cost, the net new positions the request would add, and the cost-data coverage — complete, partial, or not provided — with the units missing a cost estimate named explicitly. This makes financial impact a first-class dimension of the review, in line with the framework's structural-and-financial impact model, rather than a single line buried in one factor's rationale.

The report is written entirely in the language you are using the app in at the moment you score the request, in plain business wording — no technical jargon. Switch the app to Arabic or English before scoring (or re-scoring) to get the verdict in that language.

Creating new units

A request is always about opening one or more brand-new units. A single request may describe several units at once — for example a new sector together with its departments — and the review scores them as one governance decision: headcount evidence, strategic justification, non-duplication, and the structural and financial cost of insertion.

When a new unit is inserted mid-tree, it can adopt existing units — the request form captures the existing units to move under it and a short reparenting rationale. This is a detail of the creation, not a separate kind of request; the moved units and the rationale feed the AI's judgment and are shown on the report.

The request form (Word, generated on demand)

The recommended way to submit a request is the Word request form you download from the Upload step. It is generated on demand for your workspace, so its dropdowns are always seeded from your live data — you never edit a stale template.

Each Unit block mirrors the on-screen Manual entry form field-for-field, in the same four sections:

1. Define the unit — the unit name (Arabic, and English if available), its tier (a dropdown of Entity → Sector → Agency → Branch → General Administration → Administration → Section → Unit), its function / specialization, the job title of the unit head, and the total headcount required.
2. Placement in the org structure — the parent unit it reports to (a dropdown of your current org units); to insert the unit mid-tree, the existing units to move under it (reparent dropdowns) and a short reparenting rationale.
3. Jobs & their job descriptions — a set of repeatable job rows. For each job you need: the job title, its openings, its grade (a dropdown of your pay grades), and a JD source dropdown — pick an approved JD (a dropdown of your workspace JDs) or write a new JD (describe its purpose and core tasks). Fill only the rows you need.
4. Purpose & rationale — the goal of creating the unit, its main role and responsibilities, the current problem or gap it addresses, and the new value it adds for the entity.

Because the two paths capture the same fields, a request drafted in Word scores exactly like the same request typed into Manual entry. To propose more than one unit, select the whole Unit block, copy it below, and fill it again. If the form's fields can't be read (an older form, or a heavily edited one), the upload doesn't fail — the AI falls back to assessing the document's text directly and extracts the proposed units from it. Only a file with no assessable content at all is turned away, with a plain-language message.

Manual entry (guided form with live pickers)

Manual entry captures the unit definition directly as an in-platform form instead of a file — with live pickers sourced from your real workspace data instead of typed or dropdown references you fill from memory, and AI assistance. The form has been redesigned to capture only what's needed to define a new organizational unit, in four sections:

1. Define the unit — the unit's name (Arabic, and English if available), its organizational tier (dropdown: Entity → Sector → Agency → Branch → General admin → Administration → Section → Unit), its function / specialization (Finance, HR, IT…), the job title of the unit head, and the total headcount required.
2. Placement in the org structure — the parent unit the new unit will report to, picked from a live tree of your current org units (required; no free-text parent), with a soft warning if it isn't exactly one tier above. When the unit is inserted mid-tree, pick the existing units to move under it from a multi-select of your current units, plus the reason for the move, which appears once any are selected.
3. Jobs & their job descriptions — a jobs grid: job title · openings · grade (picked live from your workspace's grades) · JD source. For each job, pick the source from two buttons: pick an approved JD — a live search across your workspace's JDs — or write a new JD, where you describe the job's purpose and core tasks.
4. Purpose & rationale — four text fields: the goal of creating the unit, its main role and responsibilities, the current problem or gap it addresses, and the new value it adds for the entity.

You can describe more than one unit in the same request: the "Add another unit to this request" button duplicates the whole unit card, so each added unit becomes another entry in the same proposal — the same way "copy the Unit block" works in the Word template.

Inline validation catches required fields before you submit: unit name, tier, parent unit, headcount, each job's title, the goal, and the role and responsibilities. The parent/tier relationship is a soft warning only — it never blocks submission; like the file path, it softens the relevant score factor and widens the confidence range instead.

AI assist, two places:

• Role and responsibilities — in the purpose section, a CTA drafts the unit's role-and-responsibilities text from what you've entered so far (name, tier, parent, function). Preview it, then insert or discard.
• New-JD purpose — for any job set to write a new JD, a CTA drafts a purpose statement for the JD you're about to create, grounded in the job title and the unit's function. Preview-then-insert, same as above.

Both AI assists are optional starting points, not required fields — edit or discard whatever they draft.

Whichever path you use — template or manual — proposals are scored by the same rubric and produce the same report described below.

What to put in the file (or the form)

The more of this the request carries — whether typed into the Word file or the manual-entry form — the more defensible the score. Fields fall into three tiers.

Required — the request cannot be scored without these:

• Unit name (Arabic, and English if available)
• Unit type (Entity / Sector / Agency / Branch / General admin / Administration / Section / Unit)
• Parent unit — where it hangs in the existing structure
• Mandate — two to four sentences on what the unit does and why it must be a separate unit
• Requested headcount — total, ideally split by role
• Roles requested — a list of { job family, level, count }

Strongly recommended — these turn a stated request into a justified one:

• Business justification / driver (new mandate, a Vision 2030 initiative, a regulatory requirement, workload growth)
• Workload evidence — demand or volume numbers that make the headcount defensible
• Manager-to-staff split (span of control)
• Estimated annual cost (otherwise derived from roles × salary bands)
• Target start date

Optional signal: sponsor, alternatives considered, risks of not approving, and KPIs the unit will own.

Missing recommended data never blocks a request — it lowers the relevant factor and widens the confidence range, so the report is honest about how much the score could move.

The rubric (customizable)

The score is a weighted blend of five criteria descended from the WTW (Willis Towers Watson) organizational-review methodology, adapted for Saudi public-sector governance. An administrator can reweight or disable any factor, and tune the verdict thresholds and hard rules, from the rubric settings on the Structural requests page. The enabled weights must total 100.

The review is context-aware: the scorer compares the request against your workspace's existing org units, taxonomy, and salary bands, so it can flag a duplicate unit, an invalid parent, or an out-of-norm span of control.

The governance gate overrides

Alongside the AI's judgment, a deterministic server-side calculation — never left to the model's judgment — enforces a few hard, configurable rules from the rubric settings:

1. A minimum unit size (minUnitSize) — if any proposed unit that yields a live unit is below the minimum, the Sizing & span-of-control soundness factor (sizingSpan) is hard-capped at 0.3, regardless of what the AI scored it.
2. No unit provides an estimated annual cost — if not one unit in the request carries a positive estimated annual cost, the Structural & financial impact of insertion factor (insertionImpact) is hard-capped at 0.3. When only some units are missing a cost, the request is not capped — instead the report adds a plain-language note naming the units without a cost, and the missing data widens the confidence range. (The framework wants the gap named, not the whole request blocked.)

These gates are deterministic: they run as plain arithmetic over the units' data (no AI call), and they apply after the model's assessment and before the final score is computed — a gate can only lower a factor's score, never raise one that's already below the cap. When a factor is capped this way, a "Governance gate" badge appears next to its row in the report's factor breakdown, and a plain-language reason is added to the reasons list.

Two checks are advisory, not hard gates. A span of control wider than the configured maximum (maxSpanOfControl) is no longer an automatic cap — real charts have wide-but-simple spans and narrow-but-complex ones, so it becomes a note the sizingSpan factor reasons around. And tier-adjacency — an inverted reporting line (a parent no higher than its child) or a downward level-skip (reporting more than one level up) — is surfaced as a report issue for the classificationPlacement factor to weigh, never a block, because KSA charts legitimately skip levels (a general administration reporting to a deputy minister, an amanah to the minister).

Adding your own factors

Beyond the five built-ins, an administrator can add up to eight custom factors from the same rubric settings — for a governance concern your organization weighs that the defaults don't name (for example cost-to-value, Saudization impact, or sponsorship authority). For each custom factor you provide:

• a title — shown in the report's factor breakdown, and
• a description — the instruction the AI scores the request against, and
• a weight in points.

The title and description are written once, in whichever language you prefer, and appear as-is in both the Arabic and English reports.

Because the scorer is AI-driven, a custom factor works exactly like a built-in: the AI reads your description, returns a 0–1 score with a rationale and evidence, and the deterministic calculation folds it in. Custom factors count toward the same 100-point budget, so adding one means lowering the others until the enabled weights total 100 again. Disable or delete a custom factor at any time; the built-in five are always there to fall back on. (The governance gates above apply only to sizingSpan, insertionImpact, and mandateGovernance — they never extend to custom factors.)

The verdict

The 0–100 score maps to one of three bands, using admin-editable thresholds (defaults shown). The enum keys and thresholds are unchanged — only each band's label changed:

• Below 85 → Returned for rework (WTW analog: below 85% — comprehensive review), with the concrete reasons it fell short.
• 85–98 → Approved with conditions (WTW analog: 85% and above — improvement review), listing the watch-items to fix.
• Above 98 → Approved (WTW analog: 100% — no change needed).

Alongside the best-estimate score, the report shows a confidence range (for example, "89, range 83–94"). The range widens when the proposal omitted justification, workload evidence, or budget — an honest signal to the committee that the number rests on thin data. When a factor is capped by a governance gate, that is also called out in the factor's rationale.

The report also carries, for the approving authority:

• Placement in structure — a chain showing where each proposed unit sits, from the entity down through the resolved parent to the new unit, so the reporting line reads at a glance. Deterministic: resolved against the live tree, never AI-guessed. When the parent name doesn't resolve to a live unit, a partial chain is shown with a note.
• Overlap with existing units (المهام المتشابهة) — a table pairing each task the proposed unit would own against the nearest existing unit, with the degree of overlap (partial / minor / none) and a boundary recommendation. Grounded in the request's own overlap-check field plus the AI's duplication check against the live tree — the evidence behind the non-duplication factor, made concrete.
• Structural impact and Financial impact narrated as two separate sections — structure (span before/after, chain-of-command depth, reporting-line clarity, duplication) never mixed with money (headcount, salaries by grade, net operating-cost effect). The structural section shows a span before → after readout for the parent, badged when it stays within the approved maximum.
• Pros, reservations & risks — the case for approval, the reservations to resolve (the rejection reasons and watch-notes folded together), and the risks of not creating the unit, in three columns for the committee to weigh.
• Follow-up initiatives — concrete actions to de-risk or complete the creation (delimit scope with an overlapping unit before approval, issue a procedures manual, launch a KPI), each with its timing.
• Issues in the request — parse gaps, unresolved references, a missing reason-to-create, and any tier-adjacency or span flags.
• Next approving authorities (🚏) — deterministic routing flags: a grade/pay change routes to MHRSD job-classification, a statutory-authority mandate to legal affairs, and an entity/sector-level change to the Minister.
• A scope disclaimer — the report is advisory only, based on the data provided, and does not replace the formal organizational study; duplication is checked within this entity's structure only.

Every section is available in the in-app report, in the downloadable PDF, and in a MOMRAH-branded PowerPoint deck — from a scored request's header, next to Download PDF, click Export PPTX to download the verdict as a deck (a skyline cover, one slide per section — verdict, factor breakdown, placement chain, overlap, structural & financial impact, the operation-specific merge/abolish detail, pros/reservations/risks, initiatives, and routing flags), right-to-left Arabic in the ministry's Sakkal Majalla font and teal/green palette, matching the reference study deck. The export is read-only — like the report itself, it never writes to your live org units, positions, or taxonomy.

Editing the AI's tone

The scorer's persona and governance policy — how strict it is, what it emphasizes — is an editable prompt in Settings → AI prompts ("Structural request review — scoring"). The output shape (the JSON contract) stays fixed; only the voice and policy are yours to tune. See AI prompts for how editable prompt cores work.