Processes & Agent Opportunities

Process steps

1. 1. Identify need — Employee realizes they need access to a system, role, or project.
2. 2. Submit request — Employee files an access request.
3. 3. Route to approver — Request is directed to whoever owns that access.
4. 4. Approve or reject — Approver reviews and decides.
5. 5. Provision access — Approved access is actually granted in the target system.
6. 6. Recertify — Periodically confirm the access is still needed; revoke if not.

Pain points

• Submit requestThree different request types/forms exist for overlapping needs (Request / Role Bundle / Access Function) — the user doesn't know which one applies.
• Route to approverCorrect approver is looked up manually; requests frequently land in the wrong queue.
• Provision accessProvisioning is a separate manual step after approval — delay between 'approved' and 'actually has access.'
• RecertifyRecertification rarely happens in practice — stale, unused access accumulates silently.

Agent opportunities

• agentConversational intent mapping: describe the work in plain language, agent picks the right request type (same mechanism as the onboarding app-picker).
• agentAgent resolves the correct approver from org data automatically and nudges if the request stalls.
• agentAgent triggers provisioning immediately on approval wherever an API exists, closing the approve-to-access gap.
• agentAgent proactively flags stale access on a schedule and drafts the revoke request for a human to sign off — turns recertification from 'never happens' into 'just confirm.'

Process steps

1. 1. Nonconformance found — Engineer finds a part or process doesn't meet a requirement during design or build. Example: ISSUE-02041 — oxygen pump shaft seal waiver on STR-HARN-PAD.
2. 2. Draft exception — Engineer drafts a Waiver (after the fact) or Deviation (before the fact) with justification.
3. 3. Route to review board — Quality, design, and safety stakeholders are looped in.
4. 4. Board deliberation — Reviewers ask clarifying questions, often across multiple async rounds.
5. 5. Disposition recorded — Approved or rejected; the affected Configuration Item is updated.
6. 6. Downstream sync — Drawings, specs, and other linked documents are updated to reflect the exception.

Pain points

• Board deliberationSlow async back-and-forth — each reviewer re-reads the same context every round.
• Downstream syncManual cross-referencing to find every affected document/Configuration Item — easy to miss one. This is the exact mechanism behind a defective part shipping undetected.

Agent opportunities

• agentAgent pre-fills the Waiver/Deviation draft from the engineer's description plus the Configuration Item's prior history, and summarizes precedent for the board before they ask.
• agentAgent automatically finds and flags every downstream reference to the affected Configuration Item — directly closes the cascading-error gap.

Process steps

1. 1. Field report received — Dealer or field test reports a failure (warranty claim, field observation). Example: ISSUE-02043 — hydrogen pump low pressure during field hot-fire.
2. 2. Triage — Determine: known issue, new issue, safety-critical?
3. 3. Root cause investigation — Investigate; may loop back into the Development lane if it's a design issue.
4. 4. Corrective action — Decide: recall, service bulletin, or no action.
5. 5. Close the loop — Communicate resolution back to the field/dealer.

Pain points

• TriageTriage is manual — slow to notice that this report is the 12th similar one this week.
• Root cause investigationInformation silo: investigators here can't see the Development lane's Waiver/Deviation history for the same part.
• Close the loopFeedback to the field is slow and inconsistent.

Agent opportunities

• agentAgent clusters incoming reports automatically and flags emerging patterns before a human would notice the trend.
• agentAgent bridges the two lanes — surfaces relevant Development-lane history for the same Configuration Item automatically, no manual cross-search.
• agentAgent drafts the field communication as soon as a resolution is recorded.

Process steps

1. 1. Requirement intake — A new or modified part is needed — from a new vehicle program or a corrective action raised in Issues. Example: DWG-001 bracket is upstream of Product Data registration.
2. 2. Draft drawing — Engineer creates the technical drawing/spec (CAD work).
3. 3. Internal design review — Peers/seniors review the draft before formal submission.
4. 4. Compliance check — Drawing is validated against the GSFC X-673-64-1F drafting standard via BluePrint.
5. 5. Release — Approved drawing is released and handed to Product Data as a new Configuration Item.

Pain points

• Draft drawingDrafting from a plain-language requirement to a first compliant draft is entirely manual — no assistance translating intent into a structured drawing.
• Internal design reviewCompliance issues are often caught late, after significant drafting effort is already invested — rework instead of prevention.

Agent opportunities

• agentConversational drafting assistant: describe the part in plain language, agent produces a first-pass drawing/spec scaffold already structured against the same GSFC X-673-64-1F rules BluePrint checks for — the rule set guides creation, not just validation after the fact.
• agentAlready real, not just drafted: BluePrint (blueprint-validator) is the one piece of this whole pipeline that's actually built today, not a placeholder — it runs this exact compliance check.

Process steps

1. 1. Receive from Design — A BluePrint-validated drawing is handed off from Engineering Design as a new part.
2. 2. Register — Part is registered in Product Data with spec, material, supplier metadata.
3. 3. Record usage context — Which vehicle programs use this part (the 'Application').
4. 4. Revise over time — Revision history is tracked as the part changes.
5. 5. Cross-system reference — Other systems (Quality & Testing test results, Issues records, Shared Documents shared documents) reference this part. Example: STR-HARN-PAD is referenced by ISSUE-02041, ECO-2026-001, and QTS-00002.

Pain points

• Record usage context'Application' here means vehicle-program usage, but the same word means 'software app' everywhere else in the toolkit — a documented terminology collision.
• Revise over timeRevision history is often incomplete or inconsistent across the systems that reference this part.
• Cross-system referencePart/Component/Item naming collisions across Product Data/Quality & Testing/Shared Documents/Issues mean cross-system references aren't reliably the same physical object — the central safety scenario for the whole toolkit.

Agent opportunities

• agentAgent maintains a canonical revision timeline and flags when a Quality & Testing/Issues/Shared Documents reference has gone stale relative to the latest revision.
• agentAgent validates cross-system references at write-time — when Quality & Testing logs a result against 'Component X,' the agent confirms it resolves to the correct canonical Configuration Item, catching exactly the kind of mismatch a person would miss.

Process steps

1. 1. Plan test run — Engineer identifies the required test type, target Configuration Item, and success criteria from the qualification plan.
2. 2. Schedule facility and personnel — Test facility, conductor, and witness are booked against a calendar shared across campaigns.
3. 3. Execute test — Test is conducted at the facility; raw data is recorded on paper logs or proprietary data acquisition systems.
4. 4. Record result — Result (Pass / Conditional Pass / Fail / Waived) is manually transcribed from logs into Quality & Testing.
5. 5. Link to Issues on failure — If the result is Fail, a Discrepancy Report is opened in Issues and linked to the test run. Example: QTS-00003 failure auto-links ISSUE-02042.
6. 6. Close or block — Completed campaigns are closed; campaigns blocked by an open Issue stay flagged until the Issue is resolved.

Pain points

• Schedule facility and personnelFacility scheduling is a manual calendar lookup — conflicts with concurrent campaigns at the same facility are caught late, after resources are already committed.
• Record resultManual transcription from paper logs to Quality & Testing is error-prone and slow; the raw test data and the Quality & Testing record can diverge silently.
• Link to Issues on failureOpening a Discrepancy Report in Issues and linking it to the failing test run is a separate manual step — easy to defer or forget under schedule pressure, which breaks the traceability chain.

Agent opportunities

• agentAgent monitors facility schedules across all active campaigns and flags booking conflicts before they're committed — surfaces the next available window automatically.
• agentAgent ingests structured results from test equipment APIs or OCR'd field logs and pre-populates the Quality & Testing record for the conductor to confirm rather than transcribe — reduces lag and eliminates copy errors.
• agentAgent auto-creates a linked Discrepancy Report in Issues the moment a Fail result is recorded, pre-filled with test category, CI, facility, and the anomaly notes from the run — the traceability chain closes automatically, not manually.

Process steps

1. 1. Document originates — A technical document is released from its source — a drawing from Drawings, a spec from Product Data, a test report from Quality & Testing.
2. 2. Register in Shared Documents — The document is registered in Shared Documents with CI linkage, access classification, and a share target (program, partner, supplier).
3. 3. Request sharing — Owner or recipient requests that the document be shared cross-program or with an external party.
4. 4. Approve sharing — Program stakeholders review and approve or reject the sharing request based on export control and data rights.
5. 5. Distribute and track — Approved document is distributed; access and downloads are logged against the sharing event.
6. 6. Handle access requests — Recipients who lose access (e.g. licence expiry, program closure) submit access requests to the owning program.

Pain points

• Distribute and trackNo proactive notification when a shared document's upstream CI is revised in Product Data — recipients continue referencing a stale version without knowing a newer one exists.
• Approve sharingApproval chains for cross-program sharing are tracked in email threads outside Shared Documents — no visibility on who has approved, who hasn't, or how long the request has been waiting.
• Handle access requestsAccess requests sit unreviewed because the owning program gets no structured reminder — the requesting program is left with no status update.

Agent opportunities

• agentAgent watches Product Data for CI version bumps and notifies all active Shared Documents recipients of the affected document automatically — closes the currency gap without requiring recipients to monitor Product Data themselves.
• agentAgent resolves the correct approval chain for a given program and classification automatically (same mechanism as Access & Permissions's approver routing), tracks outstanding approvals, and escalates if the request stalls past a configurable threshold.
• agentAgent tracks access request age, sends structured reminders to the owning program on a schedule, drafts a provisional decision for the owner to confirm, and surfaces the request status to the requester — turns an invisible queue into a tracked workflow.