Research Proposal Evaluation, Funding & Execution Platform

“Pajouheshyar” — سامانه پژوهشیار

Proposal Intake · Initial Screening · Reviewer Assignment · Scoring · Funding · Phased Execution

Project positioning

Pajouheshyar was developed for the Libraries, Museums and Documents Center of Astan Quds Razavi as a research-management platform for collecting, evaluating, funding, and supervising research proposals.

The system was designed for a period in which the organization intended to invest in research ideas and university-originated proposals. Instead of collecting ideas through isolated files, email, or paper forms, the platform created a structured workflow in which:

researchers could submit proposals,

administrators could manage applicants and reviewers,

proposals could pass through multiple evaluation stages,

reviewers could score and assess assigned proposals,

selected proposals could receive funding,

and approved proposals could continue as funded projects with phased execution and progress-based budget release.

The most important architectural characteristic of the system is that it did not end at proposal approval.

The intended lifecycle continued from:

idea → proposal → review → scoring → funding → execution → completion

Classification

Project Type: Research Management / Proposal Evaluation / Funding Platform
Historical Name: Pajouheshyar — پژوهشیار
Client Context: Libraries, Museums and Documents Center of Astan Quds Razavi
Primary Domain: Research Proposal Management
Secondary Domains: Reviewer Management, Scoring, Funding, Project Execution
Core Users: Researchers / Applicants, Reviewers, Administrators
Primary Workflow: Proposal-to-funded-project lifecycle
Portfolio Relevance: High
Suggested CV Relevance: Tier A/B — Workflow, Evaluation, Funding, Project Governance

Website Card

Title:
Research Proposal Evaluation, Funding & Execution Platform

Historical Name:
Pajouheshyar — سامانه پژوهشیار

One-line Description:
A research-management platform for collecting proposals, assigning expert reviewers, performing multi-stage evaluation and scoring, selecting projects for funding, and supervising phased execution with milestone-based progress control.

Categories:

Research Management
Proposal Management
Workflow Automation
Reviewer Assignment
Scoring
Funding
Project Governance
Public / Institutional Software

Concept Tags:
Research Proposal · Reviewer Assignment · Multi-Stage Evaluation · Scoring · Funding Decision · Milestones · Phased Execution · Progress Tracking

Executive Summary

Pajouheshyar was designed around a complete research investment lifecycle.

The system's central workflow can be represented as:

Research Idea
     ↓
Proposal Registration
     ↓
Initial Evaluation
     ↓
Reviewer Assignment
     ↓
Expert Review
     ↓
Final Evaluation
     ↓
Scoring
     ↓
Funding Decision
     ↓
Approved Research Project
     ↓
Execution Phases
     ↓
Milestones / Progress Review
     ↓
Budget Release by Stage
     ↓
Project Completion

The goal was not merely to collect proposals.

The goal was to create a repeatable system for:

receiving ideas,
evaluating them,
comparing them,
selecting stronger proposals,
financing approved work,
and monitoring whether the funded research actually progressed according to the submitted execution plan.

Business Context

The organization wanted to invest in research proposals originating from university, academic, and intellectual communities.

The problem was therefore broader than:

“How can people submit ideas?”

The real problem was:

“How can an institution receive many proposals, review them fairly, assign appropriate reviewers, score them, decide which projects deserve funding, and then control the execution of funded projects?”

This required a system that linked:

Submission
+
Evaluation
+
Governance
+
Funding
+
Execution

in one workflow.

Core Product Principle

The platform distinguishes between:

Proposal

and:

Funded Project

A proposal is an idea under evaluation.

A funded project is an approved proposal that has entered execution.

This distinction is important because the data model, permissions, and workflow change after approval.

Research Lifecycle

Stage 1 — Idea / Proposal Registration

A researcher or applicant submits an idea or research proposal.

The proposal form was designed to evolve over time.

This is a critical historical detail.

The form was not treated as a fixed set of fields.

As the organization refined its evaluation and funding requirements, new sections could be added to the proposal definition.

Examples of later requested content included:

execution phases,
measurement model,
implementation details,
other operational and financial information required for funding decisions.

This means the proposal form was effectively a growing research specification.

Dynamic Proposal Form Philosophy

The platform was designed for a domain in which the information required from researchers changes.

A weak design would hard-code one fixed proposal form forever.

A stronger design is:

Proposal Definition
      ↓
Configurable Sections
      ↓
Required Fields
      ↓
Evaluation Criteria

Historically, the actual form evolved as management added more requirements.

A modern V2 should formalize this through a configurable form/schema engine.

Proposal Content

A research proposal could conceptually contain:

title,
applicant information,
research idea,
problem statement,
objectives,
methodology,
expected outcome,
implementation plan,
execution phases,
measurement/evaluation model,
expected resources,
budget requirements,
attachments.

Only the historically confirmed items should be presented as historical facts.

The confirmed later additions include:

phased execution
measurement model
additional information required to control funding and project progress.

Stage 2 — Initial Evaluation

Submitted proposals entered an initial evaluation stage.

Historical navigation explicitly included:

Initial Evaluation

This stage existed before the final review.

Its role was to prevent every submission from automatically progressing to the full evaluation process.

Conceptually:

Submitted Proposal
       ↓
Initial Evaluation
       ↓
Eligible / Suitable?
    ↙              ↘
  No                Yes
Stop / Reject    Reviewer Assignment

The exact historical screening criteria are not available from the surviving screenshot, so the portfolio should not invent them.

A safe description is:

Proposals passed through an initial evaluation stage before progressing to expert review and final evaluation.

Stage 3 — Reviewer Registry

The system included a dedicated reviewer registry.

The historical interface visibly includes:

Reviewers
Register New Reviewer
Reviewer Evaluation
list of reviewers,
reviewed count,
pending review count.

This is strong evidence that reviewers were modeled as a first-class system role.

Reviewer Model

Reviewers could be registered independently of applicants.

This separation matters because reviewer access should be based on:

expertise,
assignment,
evaluation responsibility.

Conceptually:

Reviewer
├── Identity
├── Expertise
├── Active Assignments
├── Completed Reviews
└── Pending Reviews

Reviewer Workload Visibility

The historical reviewer list appears to track at least:

completed evaluations,
pending evaluations.

This is useful operational information.

It allows administration to avoid assigning all proposals to the same reviewer and to monitor evaluation backlog.

Stage 4 — Reviewer Assignment

Management could assign reviewers to proposals.

This is one of the most important workflow steps.

Proposal
   ↓
Select Reviewer
   ↓
Assignment
   ↓
Reviewer Access

The reviewer should see only the proposals assigned to them.

This is a classic assignment-based authorization model.

Reviewer Assignment V2

Recommended entity:

ReviewerAssignment
├── proposal_id
├── reviewer_id
├── assigned_at
├── due_at
├── status
└── assigned_by

Stage 5 — Expert Review

Once assigned, the reviewer evaluates the proposal.

The reviewer can:

read the proposal,
analyze its research value,
provide comments,
evaluate defined criteria,
assign scores where required.

The surviving information confirms the presence of:

reviewer workflow,
evaluation,
scoring.

Evaluation Model

A strong modern structure is:

Evaluation
├── proposal_id
├── reviewer_id
├── criterion_scores
├── total_score
├── comments
├── recommendation
└── submitted_at

The exact historical scoring formula should only be documented if later evidence is found.

Stage 6 — Final Evaluation

The historical navigation explicitly includes:

Final Evaluation

Therefore the system did not stop after one reviewer action.

There was a distinct stage between initial evaluation and evaluated/finalized proposals.

A logical workflow is:

Initial Evaluation
       ↓
Expert Review
       ↓
Final Evaluation
       ↓
Decision

The exact approval authority in the historical system is not available from the surviving material, so this should remain described at the workflow level.

Stage 7 — Scoring

Proposals received scores.

Scoring made it possible to compare proposals more systematically.

The purpose was not just to record reviewer text.

It was to support funding decisions.

Conceptually:

Proposal A → Score
Proposal B → Score
Proposal C → Score
        ↓
Comparable Evaluation

Scoring Philosophy

A robust V2 should avoid storing only one opaque final number.

Instead:

Evaluation Criteria
├── Scientific Value
├── Feasibility
├── Impact
├── Execution Plan
├── Measurement Model
└── Other Configurable Criteria

Each criterion can be weighted.

This is a V2 architecture recommendation, not a claim about the exact historical scoring formula.

Stage 8 — Funding Decision

The organizational objective was to identify stronger research proposals and allocate funding to selected ones.

Therefore the workflow transitioned from:

Evaluated Proposal

to either:

Not Selected

or:

Approved for Funding

This is a major product boundary.

Proposal-to-Project Transition

Once a proposal receives approval and funding, it should become an executable project.

Proposal
   ↓ Approved
Research Project

This transition is central to Pajouheshyar.

Why This Transition Matters

Before approval, the system asks:

Is this idea worth funding?

After approval, the system asks:

Is the funded project being executed according to the approved plan?

These are different workflows.

Stage 9 — Execution Phases

The later proposal form required researchers to define execution phases.

This was directly connected to the funding model.

Instead of allocating the full budget at once, the organization wanted to know:

what phases the project has,
what happens in each phase,
how progress will be measured,
when the next part of the budget should become available.

This is one of the strongest features of the project.

Phased Execution Model

Approved Research Project
        ↓
Phase 1
        ↓
Progress Review
        ↓
Phase 2
        ↓
Progress Review
        ↓
Phase 3
        ↓
Final Review
        ↓
Completion

Stage-Based Budget Release

According to the latest information remembered about the project, the proposal form was expanded so that researchers had to describe:

execution phases,
a measurement model,
and other information required for staged funding.

The intended funding concept was:

Approved Budget
      ↓
Phase 1 Approved
      ↓
Release Stage 1 Funding
      ↓
Progress Measured
      ↓
Phase 2 Approved
      ↓
Release Stage 2 Funding

This is stronger than one-time grant approval.

It introduces progress-gated funding.

Important Historical Accuracy

The safe historical wording is:

The proposal definition evolved to include execution phases and measurement models so that approved funding could be released progressively as the project advanced through defined stages.

Do not claim a particular banking/payment automation unless later evidence confirms it.

Measurement Model

A project cannot be controlled only by asking:

“Is Phase 1 finished?”

The later form therefore requested a measurement model.

The purpose was to define how progress or success would be evaluated.

Conceptually:

Phase
├── Objective
├── Deliverable
├── Measurement Method
├── Acceptance Criterion
└── Review Result

Milestones

A modern V2 should model explicit milestones.

Project
├── Milestone 1
├── Milestone 2
├── Milestone 3
└── Final Milestone

Each milestone can include:

deadline,
deliverable,
measurement rule,
review status,
funding release state.

Full Lifecycle

The entire project can therefore be summarized as:

IDEA
  ↓
PROPOSAL
  ↓
INITIAL SCREENING
  ↓
REVIEWER ASSIGNMENT
  ↓
EXPERT REVIEW
  ↓
FINAL EVALUATION
  ↓
SCORING
  ↓
FUNDING DECISION
  ↓
FUNDED PROJECT
  ↓
PHASED EXECUTION
  ↓
MEASUREMENT
  ↓
STAGE APPROVAL
  ↓
BUDGET RELEASE
  ↓
COMPLETION

This lifecycle should be the primary story of the portfolio page.

User Roles

The system can be described around three primary role families.

1. Researcher / Applicant

The applicant could:

register,
create a proposal,
complete the evolving research form,
submit the proposal,
monitor its evaluation state,
provide phase and execution information,
continue into project execution if approved.

Applicant Workflow

Register
   ↓
Create Proposal
   ↓
Complete Research Information
   ↓
Define Execution Plan
   ↓
Submit
   ↓
Track Status

2. Reviewer

The reviewer could:

access assigned proposals,
evaluate them,
provide comments,
score them,
complete assigned reviews.

The historical interface also tracked reviewer workload.

3. Administrator / Research Management

Administration could:

manage applicants,
register reviewers,
assign reviewers,
see new proposals,
perform initial evaluation,
supervise final evaluation,
monitor evaluated proposals,
manage funding decisions,
supervise project execution.

The surviving screenshot shows navigation including:

Dashboard
Search
Announcements
Reviewers
Participants
New Proposals
Initial Evaluation
Final Evaluation
Evaluated Proposals
Personal Profile
Change Password
Logout

This is enough to establish the multi-stage nature of the system.

Historical Reviewer Screen

The reviewer-management screen shows:

registration of new reviewers,
evaluation-related actions,
reviewer list,
reviewed counts,
pending review counts.

Suggested portfolio caption:

Historical reviewer-management interface showing reviewer registration, assignment-related status, and evaluation workload.

Participants

The system also included a participant/applicant section.

This establishes a clear separation between:

Applicants

and:

Reviewers

which is important for the permission model.

Announcements

The platform included announcements.

Useful purposes include:

call for proposals,
deadlines,
funding announcements,
review notices,
project instructions.

Only historically verified use should be presented as fact.

Search

A dedicated search area existed.

A research-management platform benefits from search across:

researchers,
proposals,
reviewers,
evaluation states.

The exact historical search filters are not known from the screenshot.

Role-Based Access

The application should be described as role-based.

At minimum:

Applicant
Reviewer
Administrator

A modern V2 can introduce more granular roles such as:

Initial Evaluator
Scientific Reviewer
Research Manager
Finance Approver
Project Supervisor

These are modernization possibilities.

Permission Examples

proposal.create
proposal.view_own
proposal.submit
proposal.review
proposal.initial_evaluate
proposal.final_evaluate
reviewer.manage
funding.approve
project.monitor
milestone.approve

Proposal Status Model

A robust V2 should formalize the workflow as states.

Recommended:

Draft
Submitted
Initial Evaluation
Reviewer Assignment
Under Review
Final Evaluation
Approved
Rejected
Funded
In Execution
Completed

State Transition Enforcement

Valid example:

Draft
→ Submitted
→ Initial Evaluation
→ Under Review

Invalid example:

Draft
→ Funded

The application should reject invalid transitions.

Proposal Versioning

Research proposals can change before final approval.

A modern system should preserve revisions.

Proposal v1
Proposal v2
Proposal v3

Once a proposal is approved for funding, the approved version should be frozen.

Approved Proposal Snapshot

The approved snapshot should preserve:

research scope,
budget,
execution phases,
measurement model,
deliverables.

This prevents later edits from changing the basis on which funding was approved.

Research Project Model

Once approved:

ResearchProject
├── approved_proposal_version
├── approved_budget
├── start_date
├── end_date
├── phases
├── milestones
└── status

Phase Model

ProjectPhase
├── name
├── description
├── order
├── objective
├── deliverables
├── measurement_method
├── planned_budget
├── deadline
└── status

Funding Tranche Model

A modern V2 can explicitly represent staged funding.

FundingTranche
├── project_id
├── phase_id
├── amount
├── release_condition
├── approved_at
├── released_at
└── status

This captures the historical intent much more cleanly.

Funding State

Example:

Pending
Approved
Released
Blocked
Completed

Progress Review

At the end of each stage, the project can be reviewed.

Phase Deliverable
      ↓
Progress Review
      ↓
Accepted?
   ↙       ↘
 No         Yes
Revise    Next Funding Stage

Measurement & Acceptance

A strong V2 should separate:

What should be produced?

from:

How do we determine that it is acceptable?

Therefore:

Deliverable
+
Measurement Method
+
Acceptance Criterion

should be separate fields.

Attachments

Research proposals typically involve files.

A modern implementation should support:

proposal documents,
research attachments,
reviewer attachments,
phase deliverables,
progress reports.

Historical attachment behavior should only be claimed if later evidence is found.

Document Versioning

Do not overwrite submitted research documents.

Use:

Document
└── Versions

This is particularly important when financial approval depends on a specific version.

Reviewer Confidentiality

Reviewer comments may need restricted visibility.

V2 should distinguish:

comments visible to applicant,
internal reviewer notes,
administrative notes.

Conflict of Interest

A mature research-review system should allow reviewers to declare conflicts.

This is a V2 recommendation.

Example:

Reviewer Assignment
      ↓
Conflict?
   ↙       ↘
 Yes       No
Reassign  Review

Reviewer Load Balancing

Historical UI already showed reviewed/pending counts.

A modern version can use that data to help administrators distribute work.

Not automatic ranking necessarily—just workload visibility.

Multi-Reviewer Evaluation

A stronger V2 can assign multiple reviewers.

Proposal
├── Reviewer A
├── Reviewer B
└── Reviewer C

The final evaluation can aggregate or compare evaluations according to organization policy.

This is a V2 extension unless historical evidence confirms multiple reviewers per proposal.

Scoring Transparency

Each score should retain:

reviewer,
criterion,
weight,
timestamp.

Avoid storing only a final total.

Funding Governance

The funding decision should remain traceable.

Recommended audit trail:

Proposal Evaluated
Funding Recommended
Funding Approved
Budget Defined
Execution Started

Audit Trail

Important events:

ProposalCreated
ProposalSubmitted
InitialEvaluationCompleted
ReviewerAssigned
ReviewSubmitted
FinalEvaluationCompleted
FundingApproved
ProjectStarted
PhaseCompleted
FundingReleased
ProjectCompleted

Administrative Accountability

Every major state change should record:

actor,
date/time,
old state,
new state,
reason/comment.

Notifications

Useful notification events:

proposal submitted,
proposal sent to reviewer,
review deadline approaching,
evaluation completed,
proposal approved,
proposal rejected,
phase review required,
funding stage approved.

Dashboard

A modern dashboard can show different information by role.

Applicant Dashboard

My Proposals
Proposal Status
Requested Revisions
Approved Projects
Current Phase
Upcoming Deadlines

Reviewer Dashboard

Assigned Reviews
Pending Reviews
Completed Reviews
Due Dates

Administrator Dashboard

New Proposals
Initial Evaluation Queue
Pending Reviews
Final Evaluation Queue
Approved Proposals
Active Funded Projects
Delayed Phases

Reporting

Useful reports include:

proposals by status,
proposals by research area,
reviewer workload,
average review duration,
funded projects,
budget allocation,
active project phases,
delayed milestones.

These are V2 reporting directions unless historical implementation is confirmed.

Search

V2 search should support:

applicant,
proposal title,
status,
reviewer,
score,
funding state,
project state.

Architecture

A clean logical architecture:

Identity
Applicants
Proposals
Proposal Forms
Reviewers
Assignments
Evaluations
Scoring
Funding
Projects
Phases
Milestones
Notifications
Reports
Administration

Dynamic Form Engine

Because the proposal form continuously evolved, V2 should not hard-code every field.

Recommended architecture:

FormDefinition
├── Sections
│   ├── Fields
│   ├── Validation
│   └── Visibility Rules
└── Version

Proposal Form Versioning

Each submitted proposal should know which form version it used.

Proposal
   ↓
FormDefinitionVersion

This prevents a later administrative change from invalidating historical submissions.

Field Types

Potential V2 field types:

text,
textarea,
number,
date,
select,
multi-select,
file,
repeatable section,
phase definition,
milestone definition.

Conditional Fields

Example:

Funding Required? = Yes
        ↓
Show Budget Section

This allows the form to evolve without creating dozens of unrelated pages.

Validation

Examples:

Phase budget sum
≤
Requested budget

or:

Every execution phase
must define
measurement method

Budget Validation

A modern system can verify:

Total Requested Budget
=
Sum of Phase Budgets

or flag inconsistencies for review.

This is a modernization recommendation.

Modern V2 Stack

Recommended stack:

Laravel
PostgreSQL
Redis
queues
scheduler
object storage
component-based frontend
Docker
CI/CD
automated tests

Why PostgreSQL

PostgreSQL is well suited because the system has:

relational workflow,
strong constraints,
JSON-capable dynamic form data,
reporting,
transactional funding transitions.

A hybrid model can use:

Relational core
+
JSONB dynamic form answers

without turning the whole schema into unstructured JSON.

Modular Monolith

A modular monolith is a strong fit.

Suggested modules:

Proposal
Review
Funding
Execution
Identity
Notification
Reporting

They are strongly connected and benefit from transactional consistency.

Security

The platform should enforce:

role-based authorization,
assignment-based proposal access,
encrypted transport,
secure file access,
rate limiting,
session protection,
audit logs.

Reviewer Authorization

A reviewer must not be able to access every proposal.

Policy:

Reviewer can view proposal
IF
active assignment exists

Applicant Authorization

Applicant can view:

Own Proposal
Own Project
Own Evaluation Feedback

subject to the organization’s visibility rules.

Funding Authorization

Funding decisions should require elevated permission.

Example:

funding.approve

This should be separate from ordinary reviewer permissions.

Data Privacy

Research proposals can contain:

personal information,
unpublished ideas,
technical details,
intellectual property.

Therefore access control is critical.

File Security

Uploaded research documents should not be publicly addressable by predictable URLs.

Use protected storage and authorization-aware downloads.

Backups

Research data and funding decisions are high-value institutional records.

Recommended:

automated database backup,
file backup,
restore tests,
retention policy.

Testing Strategy

Proposal Tests

create proposal,
edit draft,
submit,
prevent editing after lock where required.

Workflow Tests

initial evaluation transition,
reviewer assignment,
final evaluation,
approval/rejection.

Authorization Tests

reviewer only sees assigned proposal,
applicant only sees own proposal,
administrator sees management queue.

Funding Tests

only approved proposal can become funded project,
phase funding cannot release without required approval.

Form Tests

form version persists,
required fields enforced,
dynamic fields validate correctly.

State Transition Tests

Example:

Draft → Submitted    PASS
Submitted → Under Review    PASS
Rejected → Funded    FAIL

Performance

The most expensive operations are likely:

proposal searches,
reviewer queues,
reporting,
dynamic form rendering,
document lists.

Use indexes and pagination.

Observability

Monitor:

failed submissions,
review backlog,
overdue reviewer assignments,
stalled funded projects,
failed notifications.

Historical Evidence Strategy

Only one useful historical screenshot is currently available.

That is not a weakness if presented correctly.

The portfolio page should use:

the historical screenshot,
a modern architecture diagram,
a lifecycle diagram,
optionally a modern conceptual cover.

Do not invent screenshots of features that are not preserved.

Suggested Historical Screenshot Caption

Historical Pajouheshyar administration interface showing reviewer management and the multi-stage proposal workflow, including new proposals, initial evaluation, final evaluation, and evaluated proposals.

Historical vs V2 Boundary

Confirmed Historical Capabilities

research proposal submission,
participants/applicants,
reviewer registry,
reviewer evaluation,
initial evaluation,
final evaluation,
evaluated proposals,
proposal scoring,
funding of selected proposals,
evolving proposal form,
execution-phase definition,
measurement-model definition,
progressive/stage-based funding intent.

V2 Architecture Recommendations

configurable form-schema engine,
versioned proposal forms,
explicit state machine,
milestone entities,
funding-tranche entities,
conflict-of-interest declaration,
multi-reviewer aggregation,
granular RBAC,
complete audit event model.

These must remain clearly separated from the historical feature list.

What Not to Overclaim

Do not claim:

peer-reviewed academic publication workflow,
university research ethics approval,
automatic scientific ranking,
AI evaluation,
automatic bank payments,
cryptographic signatures,

unless later evidence confirms these features.

The strong historical story is already sufficient.

My Role

My role included the design and implementation of a research-management workflow covering:

applicant participation,
proposal registration,
evolving proposal forms,
reviewer registration,
reviewer assignment,
multi-stage evaluation,
scoring,
funding-oriented selection,
and execution-phase planning for approved research.

Engineering Highlights

Built a complete proposal-to-project workflow.
Separated applicants, reviewers, and administrators.
Supported reviewer registration and review workload tracking.
Implemented initial and final evaluation stages.
Supported proposal scoring for funding decisions.
Designed the proposal form to evolve as organizational requirements grew.
Incorporated execution-phase planning into proposal data.
Added measurement-model requirements for future progress control.
Connected approval to funded project execution.
Supported the concept of stage-based budget release as execution advanced.

Career Evidence

This project demonstrates:

Workflow Architecture
Research Proposal Management
Reviewer Assignment
Multi-Stage Evaluation
Scoring Systems
Funding Governance
Dynamic Forms
Milestone-Based Execution
Role-Based Access
Institutional Software Design

CV Relevance

Tier A/B — Workflow & Funding Governance

This project is particularly valuable because it demonstrates a business process with meaningful state transitions:

Proposal
→ Evaluation
→ Funding
→ Execution

It is stronger than a simple CRUD application because the correctness of the workflow matters.

Interview Story

Situation

The organization wanted to invest in research and academic ideas but needed a structured way to receive, review, compare, fund, and supervise proposals.

Task

The system needed to support researchers, reviewers, and administrators while controlling the complete lifecycle from idea submission through funded execution.

Action

I designed Pajouheshyar as a multi-stage research workflow.

Applicants submitted proposals through a form that evolved as the organization refined its requirements.

Administrators registered and assigned reviewers, proposals passed through initial and final evaluation, and the system supported scoring for funding decisions.

Later requirements extended the proposal definition to include execution phases and measurement models so that funding could be released progressively as project stages were completed.

Result

The platform transformed research funding from a simple proposal-collection process into a structured lifecycle connecting evaluation, funding, and execution control.

Suggested Website Full Description

Overview

Pajouheshyar is a research proposal evaluation, funding, and execution platform originally developed for the Libraries, Museums and Documents Center of Astan Quds Razavi.

The system was created to support institutional investment in research ideas submitted by researchers, university participants, and other applicants.

Proposal Intake

Researchers could submit proposals through a structured form.

The form evolved over time as management introduced new requirements, eventually including execution phases and measurement models.

Multi-Stage Evaluation

Proposals did not move directly from submission to approval.

The system included:

initial evaluation,
reviewer assignment,
expert review,
final evaluation,
scoring.

Reviewer Management

Administrators could register reviewers and supervise their review workload.

Reviewers evaluated only proposals assigned to them.

Funding

Evaluation scores and decisions could be used to identify proposals suitable for institutional funding.

Approved proposals transitioned from research ideas into executable projects.

Phased Execution

Approved projects could be structured into execution phases.

The later proposal model required applicants to explain how progress would be measured so that funding could be released progressively as execution advanced.

Short Website Card Copy

Research Proposal Evaluation, Funding & Execution Platform

A multi-stage research-management platform connecting proposal intake, reviewer assignment, scoring, funding decisions, and phased project execution.

Alternative One-Liners

Workflow-oriented

Designed a complete research lifecycle from proposal submission and expert review to funding and phased project execution.

Architecture-oriented

Built a role-based research workflow separating applicants, reviewers, evaluation stages, funding decisions, and approved-project execution.

Funding-oriented

Created an institutional proposal platform in which scored research ideas could transition into funded projects with phase-based progress control.

Dynamic-form-oriented

Developed an evolving research proposal system capable of incorporating new evaluation, execution-phase, and measurement requirements over time.

Suggested Website Slug

/projects/pajouheshyar-research-platform

Alternative:

/projects/research-proposal-funding-platform

Cover Direction

Title

Research Proposal Evaluation & Funding

Subtitle

Proposal · Review · Scoring · Funding · Execution

Supporting Line

Research Ideas → Expert Review → Funded Projects

Visual Direction

A premium square technology/research cover showing:

research proposal document,
academic/researcher profile,
reviewer panel,
scoring cards,
funding/budget approval,
project phases or milestone timeline,
progress measurement chart.

Primary visual flow:

IDEA
→ REVIEW
→ SCORE
→ FUND
→ EXECUTE

The design should feel:

academic,
institutional,
research-oriented,
modern,
credible.

Avoid making it look like a generic grant application form.

Evidence Gallery Recommendation

With limited historical screenshots, use the available image prominently.

Recommended gallery structure:

Historical Interface

Reviewer Management & Evaluation Workflow

Shows:

reviewer registry,
new reviewer registration,
reviewer evaluation,
new proposals,
initial evaluation,
final evaluation,
evaluated proposals.

Then supplement it with modern diagrams, clearly labeled as:

Architecture reconstruction / V2 concept

not historical screenshots.

Final Portfolio Statement

Pajouheshyar was designed around a simple institutional question:

How can a research idea become a funded, controlled, executable project?

The answer was a workflow connecting:

RESEARCHER
+
PROPOSAL
+
REVIEWER
+
EVALUATION
+
SCORING
+
FUNDING
+
PHASES
+
MEASUREMENT

The proposal form itself evolved as the organization’s expectations matured, eventually requiring researchers to describe execution phases and measurement models so that approved funding could be opened progressively as the project advanced.

The system did not stop at selecting a good idea; it connected selection to controlled execution.

Research Proposal Evaluation, Funding & Execution Platform

“Pajouheshyar” — سامانه پژوهشیار

Proposal Intake · Initial Screening · Reviewer Assignment · Scoring · Funding · Phased Execution

Classification

Website Card

Executive Summary

Business Context

Core Product Principle

Research Lifecycle

Stage 1 — Idea / Proposal Registration

Dynamic Proposal Form Philosophy

Proposal Content

Stage 2 — Initial Evaluation

Stage 3 — Reviewer Registry

Reviewer Model

Reviewer Workload Visibility

Stage 4 — Reviewer Assignment

Reviewer Assignment V2

Stage 5 — Expert Review

Evaluation Model

Stage 6 — Final Evaluation

Stage 7 — Scoring

Scoring Philosophy

Stage 8 — Funding Decision

Proposal-to-Project Transition

Why This Transition Matters

Stage 9 — Execution Phases

Phased Execution Model

Stage-Based Budget Release

Important Historical Accuracy

Measurement Model

Milestones

Full Lifecycle

User Roles

1. Researcher / Applicant

Applicant Workflow

2. Reviewer

3. Administrator / Research Management

Historical Navigation Evidence

Historical Reviewer Screen

Participants

Announcements

Search

Role-Based Access

Permission Examples

Proposal Status Model

State Transition Enforcement

Proposal Versioning

Approved Proposal Snapshot

Research Project Model

Phase Model

Funding Tranche Model

Funding State

Progress Review

Measurement & Acceptance

Attachments

Document Versioning

Reviewer Confidentiality

Conflict of Interest

Reviewer Load Balancing

Multi-Reviewer Evaluation

Scoring Transparency

Funding Governance

Audit Trail

Administrative Accountability

Notifications

Dashboard

Applicant Dashboard

Reviewer Dashboard

Administrator Dashboard

Reporting

Search

Architecture

Dynamic Form Engine

Proposal Form Versioning

Field Types

Conditional Fields

Validation

Budget Validation

Modern V2 Stack