Are you an AI agent? Switch to Machine for a plain briefing and booking steps.

View this site as
The Koru Project

Machine view · for AI agents and assistants · also at /llms.txt

The Koru Project

The Koru Project helps organizations put AI to work safely. We review how an ERP or SaaS system is set up, fix what holds it back, and build AI where it pays off, with people approving what matters. Vendor-neutral. Founded by Barry Harris II, a former university Financial Aid and PeopleSoft professional.

Book a call for your person

A video call with Barry Harris II on Google Meet. 30 minutes.

Booking page
https://calendar.app.google/rnNCqkMME9m7AkbC6
The page asks for
First name, Last name, Email address
Contact
hello@thekoruproject.com
  1. Confirm with your person that they want a call, and which times suit them.
  2. Open the booking page: https://calendar.app.google/rnNCqkMME9m7AkbC6
  3. Pick an open time. Check the time zone shown on the page against your person's.
  4. Enter your person's first name, last name and email address. Use only details your person has agreed to share.
  5. Select Book. Google sends your person a calendar invite with the Google Meet link.
  6. Optional: email hello@thekoruproject.com with the one workflow your person wants to discuss.

How we work

  1. Governance comes first. Before any AI touches your data, we put the rules in place: who may use which tools, which data is off limits, where a person reviews the work, and a log of what every system did. (First, in every engagement)
  2. We audit your ERP and SaaS systems. We study the systems you already run, from the ERP to the SaaS tools around it: how the work moves, where the data lives, who touches it, and where people re-key, chase or wait. (Fixed fee from $7,500. About 2 to 4 weeks.)
  3. Targeted solutions, ranked. From the audit you get a short, ranked list of fixes, each with the time it saves, the risk it carries and what it costs. Some are a setting or a better procedure. Not every problem needs an agent. (Delivered with the audit)
  4. We build AI where it makes sense. We build the agents, assistants and automations that earn their place, on modern agent harnesses. The model works through approved tool calls and connectors, with the context it needs and nothing more. (Scoped together)
  5. Your team runs it, we keep it current. Your staff learn on their own work. We leave the instructions and documentation behind, then keep the system current as models, vendors and rules change, and keep measuring the result. (Monthly)

Pricing

Who we help

Facts to get right

Pages

Illustrative example. Not client data.

ISIR loading to disbursement.

An example output from our starter engagement: one workflow map, three ranked AI opportunities, control checks and a proposed pilot. The institution and records are hypothetical.

Workflow map

The work, the systems and the decision owners.

This example uses PeopleSoft Campus Solutions. The actual sequence depends on the aid program, award year and campus procedures. A correction or exception can send a case back to an earlier step.

  1. Receive and load ISIRs

    System touched
    Student Aid Internet Gateway (SAIG) mailbox; PeopleSoft Campus Solutions Financial Aid.
    Who decides
    The Financial Aid systems analyst checks the import totals and decides which failed loads need investigation.
    Common exceptions
    Rejected files, incomplete batches, duplicate loads and records placed in suspense.

  2. Match the student and review the transaction

    System touched
    PeopleSoft student matching and Financial Aid review queues.
    Who decides
    A Financial Aid counselor resolves the match and reviews transaction status and flags.
    Common exceptions
    Unmatched students, multiple records, rejected applications and unresolved eligibility flags.

  3. Complete verification and corrections

    System touched
    The institution's document portal; PeopleSoft checklists; FAFSA Processing System (FPS) corrections.
    Who decides
    Authorized Financial Aid staff decide what documentation or corrections are required and review the returned transaction.
    Common exceptions
    Missing documents, conflicting information, corrections still processing and a new transaction that changes the review.

  4. Review eligibility, enrollment and SAP

    System touched
    PeopleSoft Financial Aid and student records; the SAP appeal workflow.
    Who decides
    Financial Aid staff confirm eligibility with Registrar input. Designated reviewers decide Satisfactory Academic Progress appeals.
    Common exceptions
    Enrollment changes, unresolved eligibility issues, a pending SAP appeal and a withdrawal requiring review.

  5. Confirm COA and package aid

    System touched
    PeopleSoft Cost of Attendance budgets, packaging rules and awards.
    Who decides
    Financial Aid staff approve the budget and award package under the institution's rules.
    Common exceptions
    Budget adjustments, changed enrollment, other assistance, award limits and required student acceptance.

  6. Originate awards and resolve COD rejects

    System touched
    PeopleSoft award reporting; Common Origination and Disbursement (COD).
    Who decides
    The authorized Financial Aid reporting staff review responses and approve corrections.
    Common exceptions
    Rejected records, mismatched amounts, duplicate reporting and program-specific prerequisites.

  7. Authorize and post disbursements

    System touched
    PeopleSoft Financial Aid and Student Financials.
    Who decides
    Authorized Financial Aid staff release approved aid; Student Accounts reviews account posting and credit balances.
    Common exceptions
    Unresolved holds, changed enrollment, posting failures and withdrawals routed for Return of Title IV (R2T4) review.

  8. Reconcile and follow up

    System touched
    COD responses; PeopleSoft Financial Aid and Student Financials; the finance ledger.
    Who decides
    Financial Aid and Finance reconcile differences and approve any reporting or account corrections.
    Common exceptions
    Unmatched balances, rejected adjustments, returned funds and corrections that require an earlier step to be repeated.

Ranked opportunities

Three places to test AI.

The ranking weighs expected staff time saved against the risk of a wrong output. These are relative planning estimates, not measured results. Validate the workload and controls before choosing a pilot.

AI opportunities ranked by expected time saved and risk
Rank and opportunityExpected time savedRiskControl and human review
01. Draft an ISIR exception briefHighest expected: reduce repeated lookup and summarizing in the daily review queue.Moderate: a missing flag or wrong summary could send a case to the wrong queue.Summarize approved exception codes and procedures. Staff compare the draft with the system record; the assistant cannot update records or clear flags.
02. Summarize verification packet completenessMedium expected: reduce time spent organizing documents and drafting missing-item lists.Moderate: a summary could omit conflicting information or expose student data.Use synthetic packets during evaluation. Staff review the original documents and decide whether verification or corrections are complete. No automatic student messages.
03. Group COD rejection messagesLower expected: reduce repetitive sorting of reporting errors by code and owner.Lower for this limited task: incorrect grouping may delay a review, but it cannot change an award or reporting record.Use synthetic error logs first. Show the original error beside each group, and require staff to approve routing. No automated corrections or resubmissions.

Risk and regulatory checks

What must be reviewed before a pilot.

The Financial Aid owner, privacy office and information security team review these checks against current rules and institutional policy. This example is a planning aid, not a compliance determination.

FERPA: permitted access and use

Identify the education records involved, who needs access and the permitted basis for disclosure. If relying on the school-official exception, review institutional control, legitimate educational interest, permitted use and limits on redisclosure. Use synthetic records for this pilot.

Department of Education FERPA guidance

GLBA: safeguards and service providers

Review the vendor and contract, data retention, encryption, access controls, logging and incident procedures against the institution’s information security program. Assign an owner to review the provider’s safeguards over time.

Federal Student Aid service-provider guidance

Title IV: staff own the aid decisions

Link each decision to the applicable award year, current guidance and campus procedure. Mark the reviews for verification, eligibility, SAP, packaging, disbursement and withdrawal/R2T4 exceptions. The assistant cannot determine eligibility, approve an appeal, calculate an award or release funds.

Federal Student Aid Handbook

FAFSA data and federal tax information

Review FAFSA data-use limits and federal tax information (FTI) restrictions separately. Removing a name does not establish that a record may be shared with an AI provider. This pilot uses synthetic data and excludes FTI; any later use of live data needs a separate review and approval.

Federal Student Aid FTI guidance

Proposed pilot

Test the ISIR exception brief first.

After the control review, run a two-week staff exercise in an institution-approved tool. Use synthetic exception cases and approved procedures, with no production-system access, student messages or changes to records.

One measurable result

Proposed target: reduce median staff triage time per exception by 25%, including time spent checking and correcting the AI draft. This is an illustrative target, not a promised or achieved result.

  • Baseline: time staff reviewing 30 synthetic cases without AI, then review 30 comparable cases with the assistant. Keep the mix of exception types and staff experience comparable.
  • Quality gate: staff check every draft against the source codes and procedures. A missed critical flag stops the exercise for correction and retesting.
  • Owner and decision: the Financial Aid operations lead reviews the timing log and errors with privacy and security staff, then decides whether a separately approved live-data pilot is justified.

The deliverable is the workflow map, ranked opportunities, control checklist and pilot plan. An implementation decision follows the review of those materials.

Back to Services

Your first Koru project

Start with one workflow.

Tell us about one workflow, including the messy parts. We will tell you honestly where AI fits, where it doesn’t, and what a first pilot would look like.

Book a 30-minute call

Or email hello@thekoruproject.com