Admin Bud-E

English

Deutsch

English

Deutsch

Appearance

Budgets, Allowance & Common Pool ​

This page explains how Admin Bud-E's three-tier credit system works: Allowance, Common Pool, and Personal Credits.

The Three Credit Types ​

When a user makes a request, Admin Bud-E checks credit sources in this order:

1. Allowance (periodic, individual)
   ↓ (if depleted)
2. Common Pool (shared, project-wide)
   ↓ (if depleted or disabled)
3. Personal Credits (individual, permanent)
   ↓ (if depleted)
❌ Request rejected (insufficient credits)

1. Allowance ​

Allowance is a periodic credit grant that refreshes automatically.

Key Characteristics ​

  • Individual: Each user gets their own allowance
  • Periodic: Refreshes daily, weekly, or monthly
  • Fixed Amount: Same for all users in a project
  • Use-it-or-lose-it: Unused allowance doesn't carry over (goes to common pool if enabled)

Configuration ​

Set at the Project level:

  • Allowance Amount: Credits per user per period (e.g., 100)
  • Interval: Daily, Weekly, or Monthly

Example: Daily Allowance ​

Project: Grade 5 Students Allowance: 50 credits/day

Timeline:

  • Monday 00:00: Alice receives 50 allowance credits
  • Monday 10:00: Alice spends 30 → 20 remaining
  • Monday 18:00: Alice spends 15 → 5 remaining
  • Tuesday 00:00: Allowance resets
    • Unused 5 credits → moved to common pool (if enabled) or forfeited
    • Alice receives fresh 50 allowance credits

When to Use Allowance ​

Best for:

  • Students (fair distribution)
  • Regular, predictable usage
  • Teaching environments (homework, assignments)
  • Preventing overconsumption

Benefits:

  • Encourages daily/weekly usage
  • Prevents hoarding
  • Simple to explain ("You get X credits per day")
  • Automatic administration

2. Common Pool ​

Common Pool is a shared credit balance available to all members of a project.

Key Characteristics ​

  • Shared: All project members draw from the same pool
  • Flexible: No per-user limits
  • Replenished by: Unused allowance (if enabled) or manual refills
  • Order: Used only after allowance is depleted

Configuration ​

Set at the Project level:

  • Enable Common Pool: Yes/No toggle
  • Common Pool Balance: Starting/current credit amount

Example: Common Pool with Allowance ​

Project: Teachers (10 members) Allowance: 200 credits/week Common Pool: 5,000 credits

Usage Pattern:

Week 1:

  • Alice (typical user): Uses 150 of 200 allowance → 50 goes to common pool
  • Bob (heavy user): Uses all 200 allowance + 300 from common pool
  • End of week: Common pool replenished by 8 × 50 (other users' unused allowance)

Result:

  • Typical users stay within allowance
  • Heavy users can exceed via common pool
  • System balances fairness and flexibility

When to Use Common Pool ​

Best for:

  • Small teams (trust-based)
  • Variable usage patterns
  • Teacher/staff accounts
  • Research groups

Not ideal for:

  • Large student groups (risk of tragedy of the commons)
  • Strict per-user quotas required
  • Unequal power dynamics

3. Personal Credits ​

Personal Credits are individual, non-refreshing credits assigned directly to a user.

Key Characteristics ​

  • Individual: Specific to one user
  • Permanent: Don't expire (unless manually removed)
  • No refresh: Don't replenish automatically
  • Last resort: Used only after allowance and common pool

Configuration ​

Set at the User level:

  1. Navigate to Users
  2. Edit user
  3. Set Personal Credits amount

Example: Personal Credits ​

Scenario: Special project requiring extra resources

User: Dr. Smith Allowance: 200/week (from Teachers project) Personal Credits: 5,000 (granted for research project)

Usage:

  1. Week 1: Uses 200 from allowance
  2. Week 2: Uses 200 from allowance + 500 from personal credits
  3. Week 3: Uses 200 from allowance + 1,000 from personal credits
  4. After 5 weeks: Personal credits depleted, back to allowance only

When to Use Personal Credits ​

Best for:

  • One-time grants
  • Compensation for issues
  • Special projects
  • VIP users
  • Testing

Administration:

  • Manual only (no automatic refresh)
  • Grant as needed
  • Track externally if auditing required

Complete Example: All Three Tiers ​

Scenario: Mid-size school deployment

Project: Teachers (20 users) ​

Configuration:

  • Allowance: 300 credits/week
  • Common Pool: 20,000 credits (enabled)
  • Personal Credits: Varies per user

User: Alice (Typical Teacher) ​

Week 1:

  • Start: 300 allowance + access to 20,000 common pool + 500 personal
  • Monday-Thursday: Uses 250 from allowance
  • Friday: Uses 50 from allowance
  • Total used: 300 from allowance
  • Weekend: Allowance resets, no unused to return

Week 2:

  • Start: 300 allowance + 20,000 common pool + 500 personal
  • Monday-Wednesday: Uses 300 from allowance
  • Thursday: Needs 150 more for grading
    • 150 drawn from common pool
    • Common pool now 19,850
  • Total used: 300 allowance + 150 common pool
  • Personal credits: Untouched (500 remaining)

User: Bob (Heavy User) ​

Week 1:

  • Start: 300 allowance + 20,000 common pool + 0 personal
  • Usage: 300 allowance + 1,000 common pool
  • Total: 1,300 credits (well above allowance)

Week 2:

  • Start: 300 allowance + 18,850 common pool + 0 personal
  • Usage: 300 allowance + 800 common pool
  • Total: 1,100 credits

Admin Action (Week 3):

  • Admin notices Bob's heavy usage
  • Grants 5,000 personal credits to Bob
  • Bob now has a buffer without impacting common pool

Budget Planning ​

Calculate Required Budget ​

Formula:

Total Budget = (Users × Allowance × Periods) + Common Pool + Buffer

Example: Grade 6 (100 students), 1 month

Allowance: 50 credits/day
Days: 30
Common Pool: 10,000 credits
Buffer: 20%

Calculation:
  Allowance pool = 100 users × 50 × 30 = 150,000
  Common pool = 10,000
  Subtotal = 160,000
  Buffer (20%) = 32,000
  Total Budget = 192,000 credits

Buffer Recommendations ​

Add buffer for:

  • Peak periods (exams, projects): +30%
  • Unexpected usage (new features): +20%
  • Growth (new users mid-period): +10%

Conservative approach: Add 30-50% buffer initially, reduce after observing actual usage.

Cost Controls ​

Hard Caps ​

Per-User Daily Cap:

  • Set allowance to maximum daily usage
  • Disable common pool
  • No personal credits
  • Result: User cannot exceed allowance

Project-Wide Cap:

  • Set total project budget
  • Monitor common pool
  • Refill manually only after review
  • Result: Project cannot exceed budget

Soft Caps ​

Allowance + Small Common Pool:

  • Allowance covers typical usage
  • Small common pool for occasional overages
  • Result: Most users capped, flexibility for peaks

No Caps (Trust-Based) ​

Large Common Pool Only:

  • No allowance
  • Large common pool
  • All users draw as needed
  • Result: Maximum flexibility, requires trust

Settlement Mechanics ​

Settlement collects unused allowance and moves it to the common pool.

When Settlement Happens ​

Automatic:

  • At the start of each allowance period (daily/weekly/monthly refresh)

Manual ("Settle Now"):

  • Click button in Projects page
  • Forces immediate settlement
  • Useful for month-end, term-end, or before changing settings

Settlement Process ​

  1. For each user:

    • Calculate unused allowance
    • Move unused allowance → common pool
    • Grant fresh allowance

  2. Example:

    • 10 users, 100 allowance each
    • 6 users have 20 unused (total 120)
    • 4 users fully depleted (0 unused)
    • Common pool gains 120 credits
    • All 10 users receive fresh 100 allowance

INFO

Settlement only affects users with unused allowance. Personal credits are never settled.

Monitoring & Reports ​

Check Current Balances ​

  1. Navigate to Users
  2. View columns:
    • Allowance: Current period's remaining allowance
    • Personal Credits: Permanent balance
    • Effective Credits: Allowance + Personal + (Common Pool share)

Project Budget Health ​

  1. Navigate to Projects
  2. View:
    • Common Pool Balance: Current shared credits
    • Total Budget: Original allocation
    • Utilization: Percentage used

Usage Reports ​

  1. Navigate to Usage
  2. Filter by Project
  3. View:
    • Credits consumed per user
    • Allowance vs. pool vs. personal usage
    • Trends over time

See Usage Reports for detailed reporting.

Best Practices ​

1. Start with Allowance Only ​

For first deployment:

  • Enable allowance
  • Disable common pool
  • Observe usage patterns
  • Add common pool later if needed

Rationale: Simplest to explain, prevents overconsumption.

2. Add Common Pool for Flexibility ​

After 2-4 weeks:

  • Analyze usage data
  • Identify users who regularly hit limits
  • Enable common pool with 20-30% of allowance budget

Rationale: Balances fairness and flexibility.

3. Use Personal Credits Sparingly ​

Personal credits should be:

  • Exceptions, not the rule
  • Tracked manually
  • Reserved for special cases

Rationale: Keeps administration simple, prevents inequality.

4. Communicate Clearly ​

Explain to users:

  • Allowance: "You get X credits per day/week"
  • Common Pool: "If you run out, there's a shared pool"
  • Personal Credits: "Special grants for projects"

Avoid jargon. Use concrete examples.

5. Monitor and Adjust ​

Review monthly:

  • Are users hitting limits?
  • Is common pool depleting too fast?
  • Are allowances going unused?

Adjust settings based on data, not complaints.

Troubleshooting ​

Issue: Common Pool Depletes in Days ​

Symptoms: Pool drops from 10,000 to 0 in 3 days.

Possible Causes:

  1. Allowance too low (users depend on pool)
  2. A few heavy users draining pool
  3. Pricing too high (costs more than expected)

Solutions:

  1. Increase allowance
  2. Identify heavy users, grant personal credits
  3. Review and adjust pricing
  4. Add more budget to common pool
  5. Monitor usage reports to identify patterns

Issue: Allowance Mostly Unused ​

Symptoms: 80% of users have unused allowance at settlement.

Possible Causes:

  1. Allowance too high
  2. Users not aware of the system
  3. Pricing too low (credits undervalued)

Solutions:

  1. Reduce allowance to match actual usage
  2. Communicate system benefits
  3. Review pricing (may need adjustment)
  4. Shorten interval (monthly → weekly)

Issue: Users Confused by System ​

Symptoms: Many support requests about credits.

Possible Causes:

  1. Explanation unclear
  2. Too many tiers active
  3. Unexpected behavior (settlement, depletion)

Solutions:

  1. Simplify configuration (allowance only initially)
  2. Create user guide with examples
  3. Add balance display in frontend
  4. Send periodic balance emails/notifications

Next Steps ​

Admin Bud-E / Bud-E / School Bud-E are developed by LAION e. V. (non-profit). Useful links: Hosted frontend · Middleware repo · Frontend repo · LAION blog