# Get Output Review Grounded in the Standard An engineer approved agent output. The engineer did not check it against the standard. The code looked correct, but it violated an organizational convention that only the standard data showed. If you read every line, you lose the productivity gain that agents give. This guide shows how to verify agent work against your organization's engineering standard. You then review by exception. Two products work together. **Pathway** makes the role's expected skills, behaviours, and conventions visible so you know what to look for. **Guide** reviews specific deliverables against those expectations. For the career-guidance half of this job, see [Get Career Guidance Grounded in the Standard](/docs/products/growth-areas/). ## Prerequisites This guide assumes you completed the setup for both products: - [Getting Started: Pathway for Engineers](/docs/getting-started/engineers/pathway/): install Pathway and initialize a `data/pathway/` directory with your organization's standard data or the starter content. - [Getting Started: Guide for Engineers](/docs/getting-started/engineers/guide/): install Guide, run codegen, authenticate with Anthropic, process your standard data, and start the service stack. Also know the role coordinates for the agent that produced the work. The coordinates are the discipline, the level, and the track. If you do not know them yet, work through [See What's Expected at Your Level](/docs/products/career-paths/) first. That guide covers how to find role coordinates and what each level expects. ## See what the standard expects for this role Before you review agent output, make the quality bar explicit. Pathway derives the full expectation profile for any role from your organization's standard data. The profile does not come from a generic checklist. Generate the role definition for the discipline and level you configured the agent to work at. For example, the agent may operate as a Software Engineer (J060) on a platform track: ```sh npx fit-pathway job software-engineering J060 --track=platform ``` The output has four sections: 1. **Expectations**: the level's impact scope, autonomy, influence, and complexity. 2. **Behaviour Profile**: each behaviour the organization values and the maturity expected at this level. 3. **Skill Matrix**: every skill relevant to the discipline and track, with the expected proficiency level. 4. **Driver Coverage**: how the skill and behaviour profile maps to engineering effectiveness drivers. Here is what the Expectations section looks like: ```text ## Expectations - **Impact Scope**: Features and small projects - **Autonomy Expectation**: Work independently on familiar problems - **Influence Scope**: Mentor junior team members - **Complexity Handled**: Moderate complexity with some ambiguity ``` The Skill Matrix is the most useful section for output review. It lists every skill the role requires and the expected proficiency level for each one. An agent configured for this role should produce output consistent with `working`-level Architecture Design, `working`-level Code Quality, and so on. When a skill shows `foundational` or `awareness`, the standard expects less depth in that area. Calibrate your review accordingly. ### Inspect specific skills the output touches The agent's deliverable may involve architecture decisions. Inspect the skill definition to see the expected proficiency level in practice: ```sh npx fit-pathway skill architecture-design ``` ```text # Architecture Design Scale Designs system structures that meet functional, scalability, and regulatory requirements. Balances modularity, integration, and validated computer system constraints typical of pharmaceutical environments. ## Level Descriptions | Level | Description | | --- | --- | | Awareness | You recognize common architectural styles... | | Foundational | You implement components inside a defined architecture... | | Working | You design services and module boundaries for a bounded domain... | | Practitioner | You lead architecture for a product or platform area... | | Expert | You define architectural strategy and reference patterns... | ``` Each proficiency level describes concrete, observable actions. Compare the level description for the agent's expected proficiency against what the agent produced. If the role expects `working`-level Architecture Design, look for evidence in the output. The agent should have designed services and module boundaries for a bounded domain. An agent that only implements components inside someone else's architecture works at `foundational` level. Repeat for each skill the deliverable touches. The Skill Matrix tells you which skills are relevant. The skill detail tells you what the expected proficiency looks like. ### Check behaviour expectations Agent output can be technically correct and still violate how the organization expects people to approach work. Behaviours describe those expectations. If the agent's design must demonstrate systems thinking, check what the standard expects: ```sh npx fit-pathway behaviour systems-thinking ``` ```text # Think in Systems ## Maturity Levels | Maturity | Description | | --- | --- | | Emerging | You recognise that your work connects to broader processes... | | Developing | You actively trace dependencies beyond your immediate scope... | | Practicing | You consistently reason about systems end-to-end... | | Role Modeling | You shape how teams approach problems... | | Exemplifying | You set the standard for systems thinking... | ``` If the role expects `developing`-level systems thinking, the output should actively trace dependencies beyond the immediate scope. An agent may solve the problem in isolation and ignore upstream or downstream effects. That output violates the behaviour expectation even if the code itself works. ## Review the deliverable with Guide You now know what the standard expects. Guide applies that knowledge to a specific deliverable. Do not read every line yourself. Describe the output to Guide. Ask Guide to evaluate it against the standard. Start Guide. Describe what the agent produced. Lines that start with `>` are prompts you type inside the Guide session: ```sh npx fit-guide ``` ```text > I'm reviewing a PR from an agent configured as a J060 Software Engineer on > the platform track. The PR introduces a new service for processing webhook > events. Does this align with what our standard expects at working-level > architecture design? ``` Guide responds with an evaluation grounded in your organization's skill definitions: ```text At working-level Architecture Design, your standard expects the engineer to design services and module boundaries for a bounded domain. For a webhook processing service, I'd look for: 1. **Clear service boundary** — The service should have a well-defined API contract. Check whether the PR documents what events it handles and what it delegates to other services. 2. **Module boundaries within the service** — Internal structure should separate concerns (event parsing, validation, routing, handlers). If everything lives in a single file or handler, that's below working level. 3. **Integration points documented** — Working-level architecture means the engineer considers how this service connects to the broader system. Look for documentation of dependencies, data flow, and failure modes. Your standard does not expect a J060 to lead architecture for the platform area (that's practitioner level) — so the scope should be bounded to this service, not a platform-wide webhook strategy. ``` Guide tells you what to check and what is out of scope for this level. You review only the specific areas Guide identifies. ### Ask about specific concerns When something in the output looks wrong, ask Guide whether it violates the standard: ```text > The PR doesn't handle retry logic for failed webhook deliveries. Is that > expected at J060 on the platform track? ``` ```text > The agent used a synchronous request pattern instead of an event queue. > Does our standard say anything about that at working level? ``` Guide checks each question against the skill definitions, behaviour expectations, and conventions in your standard. Two engineers who ask the same question get the same foundational answer. They share one source of truth. ### Pipe a focused question For a quick check outside the interactive session, pipe a question directly: ```sh echo "Does our standard expect working-level code review to catch cross-cutting concerns?" | npx fit-guide ``` Guide references the specific markers from your capability YAML and returns a grounded answer. ## Build a review checklist from the standard You may review the same kind of work many times, for example all agent PRs for one service. Use Pathway to build a reusable checklist grounded in the standard. Generate the skill IDs relevant to the agent's role: ```sh npx fit-pathway job software-engineering J060 --track=platform --skills ``` ```text architecture-design code-quality full-stack-development cloud-platforms sre-practices change-management incident-management observability performance-optimization data-modeling stakeholder-management ``` Each skill ID maps to a set of concrete expectations in your standard. Look up the proficiency descriptions for the skills most relevant to the deliverable type. For a new service PR, these are `architecture-design` and `code-quality`: ```sh npx fit-pathway skill code-quality ``` The proficiency description at the expected level becomes a checklist item. For example, `working`-level Code Quality may say "writes clean, well-structured code with consistent style and meaningful naming." That is what you verify in the agent's output. You can skip the other areas. ## Verify You reach the outcome of this guide when you can answer these questions: - **What does the standard expect for this role?** You generated the role definition with `npx fit-pathway job`. You can name the skills, proficiency levels, and behaviour maturities relevant to the deliverable. - **What does each expected proficiency look like in practice?** You inspected at least one skill with `npx fit-pathway skill`. You can describe the concrete actions the expected proficiency level involves. - **Can you articulate what to check and what to skip?** You asked Guide to evaluate the deliverable. You received specific areas to review, grounded in the standard. - **Do you review by exception?** You do not read every line. You check the areas Guide identified as relevant to the role's expectations. You skip areas where the output meets or exceeds the standard. If any of these are unclear, revisit the relevant step. You shift to review by exception when you trust the standard to define the quality bar and trust Guide to apply it. ## What's next

Get a Second Opinion on a Deliverable

Know what meets the bar and what falls short before you approve. Your engineering standard grounds the assessment. Intuition does not.

See What the Standard Expects Before Reviewing

Know what to check before you start a review: the skill proficiencies, behaviour maturities, and expectations your standard defines for the role.

Get Career Guidance Grounded in the Standard

A promotion conversation ended with 'not yet' and no specifics. Use Guide and Landmark to find what is missing and show concrete evidence of growth.