Portfolio project: workflow and rules engine, reference implementation
Enterprise PM Automation System
Governed Jira Epic intake and lifecycle automation, with modeled impact
A reference implementation that turns stakeholder intake into a structured Jira workflow: a Google Form and Apps Script create the Epic, Jira Automation rules and fixed webhook rules in a FastAPI middleware handle the lifecycle. It is not an agent: an event-driven rules engine with optional OpenAI assist that is off by default. The impact figures are a modeled scenario, not measurements.
See what is measuredView the repoWhat is not built
- Impact figures are modeled, not measured
- Status: reference implementation
- No automated tests (no tests/ directory)
- No CI workflow
- Capacity limits: design only, not in app/
- BRD gate advises; a Jira rule does the block
01
The problem
Epic intake is slow and error-prone when it is manual: requests arrive in different shapes, required data goes missing, and stakeholders chase status by email.
The repo practises designing governed Jira Epic intake, lifecycle automation and capacity-planning logic end to end. The workflow, validation gates and integration patterns are the evidence. The business-impact section is a modeled scenario demonstrating the design's reasoning, not a claim that this replaces an established tool.
Evidence posture
The workflow, configuration, API integration patterns and project artifacts are implemented in the repo. Business-impact figures are modeled scenario estimates, not production telemetry, audited savings or measured user outcomes.
Rules, not planning
"Intelligent workflow orchestration" means hard-coded rules. There is no planning, loop or autonomous decision-making.
A gate that only advises
The Python side comments and labels on a violation. The block itself is a Jira Automation rule that reverts the transition after it has happened.
02
How it works
An intake form creates a Jira Epic through Apps Script; Jira Automation rules move it through an 8-status lifecycle; a FastAPI middleware receives Jira webhooks and runs fixed rule functions. The timings below are the README's modeled figures, not measurements.
Stages, one at a time
Stage 1 Stakeholder submits the form
A Google Form with 12 required fields, validated, saves each submission to a Google Sheet that serves as the audit trail.
Stage 2 Apps Script creates the Epic
onFormSubmit posts to Jira REST API v3 and writes the Jira link back to the sheet. The README models this path at about 30 seconds.
The 30 seconds is modeled, not measured.
Stage 3 Welcome rule
Rule 1 adds a welcome comment and sends an email when an Epic is created in INTAKE.
Stage 4 TPM review (manual)
INTAKE to UNDER_REVIEW to BACKLOG or REJECTED is a manual decision; approval and rejection emails are sent by rules.
Stage 5 Roadmap scheduling
When a Committed Quarter is set, Rule 2 moves the Epic to IN_ROADMAP and sends a schedule email.
Stage 6 Activation and completion
A child Story starting moves the parent to IN_EXECUTION (Rule 3). A daily 9 AM rule completes Epics whose Stories are all done (Rule 4).
Whether these rules are enabled in a live Jira site cannot be verified from the code; the YAML in the repo is the specification.
03
What is measured
Nothing on this page is a measurement. The two tables below are the README's modeled scenario (not measured, not simulated: a model on stated baseline assumptions), shown so the assumptions are visible. The repo has no tests and no result files.
Copied from the README's Modeled Business Impact section.
| Metric | Before | After | Improvement |
|---|---|---|---|
| Intake processing time | 2-3 days | 30 seconds | 99.7% faster |
| Epic creation duration | 30 minutes | 30 seconds | 98% faster |
| Manual status updates | 15 emails/week | 0 (automated) | 100% fewer |
| Data entry accuracy | 75% (typos, missing fields) | 100% (validated) | +25% |
| Roadmap visibility | Quarterly meetings | Real-time dashboard | Continuous |
| Stakeholder satisfaction | 65% | 92% | +27% |
| On-time delivery rate | 60% | 85% | +25% |
Caveat Modeled scenario estimates based on stated baseline assumptions; they are not production telemetry, audited savings or measured user outcomes. The README's own headline lists the satisfaction and validation figures as targets. A production deployment would need to establish baselines, instrument cycle time and error rates and validate adoption.
Source: README, Modeled Business Impact
Copied from the README's Time Savings Analysis.
| Role | Task automated | Weekly savings | Annual |
|---|---|---|---|
| Technical Program Manager | Epic creation and data entry | 5 hours | 260 hours |
| Technical Program Manager | Status update emails | 8 hours | 416 hours |
| Technical Program Manager | Roadmap meeting preparation | 2 hours | 104 hours |
| Leadership | Roadmap review meetings | 1 hour | 52 hours |
| Stakeholders | Follow-up inquiries | 10 hours | 520 hours |
| Total | 26 hours/week | 1,352 hours/year |
Caveat About $135,000 a year only if the 1,352 hours are actually released and valued at the illustrative $100/hour assumption. Reclaimed time is capacity, not automatically cashable savings, and Finance would need to confirm any cashable benefit.
Source: README, Time Savings Analysis
04
Architecture pattern
Pattern Not an agent: an event-driven workflow and rules engine (webhook-triggered), with optional LLM assist that is off by default.
app/webhooks.py receives Jira events and schedules fixed rule functions in app/rules/ (brd_gate.py, stale_cleanup.py, auto_classify.py, duplicate_detection.py). Only the classifier and duplicate detector can call OpenAI, and only when ENABLE_AI_CLASSIFICATION is on and OPENAI_API_KEY is set; both fall back to keyword and text matching. Human gate: the BRD and Definition-of-Ready gates comment and label, and a Jira Automation rule (S4) reverts the transition afterwards.
- Google Form12 required fields, validated
- Google Sheet and Apps Scriptaudit trail; onFormSubmit
- Jira CloudEpic created in INTAKE via REST API v3
- Jira Automation ruleswelcome, roadmap, activate, complete, rejection, on hold, approval
- Roadmap boardKanban over the 8 workflow statuses
- FastAPI middleware on RailwayBRD gate advises; capacity limits design only; Slack module present, not wired
Mermaid diagrams (architecture, state machine, sequence) in the repo README
05
Competencies demonstrated
Program operating-model design
Structured intake, lifecycle states, approvals, roadmap visibility and notifications.
Systems integration
Google Forms and Sheets, Apps Script, Jira REST, FastAPI, PostgreSQL and Slack patterns.
Governance by design
Validation gates, audit records and explicit workflow transitions; capacity limits are specified but not implemented.
Automation architecture
Event-driven rules reduce manual reconstruction across the Epic lifecycle.
Value framing
Time, quality, capacity and modeled economics are kept separate from implementation evidence.
06
What is not built or not verified yet
Taken from the repository's README (Evidence posture, Architecture pattern, Validation Rules), which was corrected to state these gaps.
- not built
Capacity enforcement
Capacity limits are not implemented in
app/. The 80% alert is specified in the Jira Automation YAML, which expects the middleware to set acapacity-warninglabel, but no capacity code exists. Blocking scheduling at 100% capacity is a design target. - not verified
No automated tests
There is no
tests/directory, so none of the rules, gates or the optional OpenAI paths have unit coverage. There is no CI workflow. - limit
The BRD gate only advises
brd_gate.pycomments and labels on a violation. The block is a Jira Automation rule (S4 inconfig/jira-story-automation-rules.yaml) that reverts the transition after it has happened, when it sees thedor-gate-blockedlabel. - not verified
Live Jira rules
The YAML is the specification in this repo; whether the rules are enabled in a live Jira site cannot be verified from the code.
- not built
Slack integration is not wired
app/integrations/slack.pyis not called by any webhook handler. - limit
Only fixed rules
It reacts to events with fixed rules and cannot handle a case no rule covers.
- not verified
Impact figures
Business-impact figures are modeled scenario estimates, not production telemetry, audited savings or measured user outcomes.
07
Roadmap
- DonePhase 1, intake automation (README: complete): Google Form with 12 fields, Apps Script, Epic auto-creation, sync back to the sheet
- DonePhase 2, Epic workflow (README: complete): 11 custom fields, 8-status workflow, 8 automation rules in the Epic rules YAML, roadmap board
- Not donePhase 3, BRD workflow (README: in progress): story templates, BRD gate validation, Tech Lead approval, ready-for-dev status
- Not donePhase 4, sprint analytics (README: planned): sprint automation, Slack daily standup, metrics dashboard, velocity tracking
- Not doneOpen gap: implement capacity limits in
app/and add tests