Chapter 37: Public services model

Metadata tags on services

The rule of law defines a set of metadata tags that can be applied to services. A formal review process ensures they’re correct. This creates order, prevents gaming, and gives the water filling algorithm a stable foundation to operate on.

Tags create the “semantic structure” of the entire funding system. Tags are more than labels. They define:

domains of public services
categories for proxies
boundaries for delegation caps
groupings for dashboards and analytics
thematic clusters for voters
the structure of the water filling algorithm

By having the rule of law define the tag set, you ensure:

stability
predictability
resistance to manipulation
clarity for voters
clarity for proxies
clarity for auditors

This is the opposite of a free for all tagging system, which would quickly devolve into chaos.

Constitutional review of tags is essential Your idea that every initiative must undergo a formal constitutional review to verify its tags is exactly right. This prevents:

mis tagging to attract more funding
hiding controversial initiatives under benign tags
creating new tags to bypass caps
tag inflation
tag dilution
tag confusion

It also ensures that:

proxies know what domain they’re scoring
voters know what they’re delegating
the water filling algorithm groups services correctly
domain based caps (if used) are enforceable

This is the kind of structural safeguard that keeps the system clean for decades.

Tags are the backbone of domain based delegation Earlier, we talked about the idea of limiting how much tax a person can delegate to a single proxy. Tags make this far more elegant. Instead of a single global cap, you can have domain specific delegation caps:

“You may delegate up to 80% of your health tax to a health proxy.”
“You may delegate up to 60% of your infrastructure tax to an infrastructure proxy.”
“You may delegate up to 90% of your arts tax to an arts proxy.”

This prevents any one proxy from becoming a “super representative” while still allowing deep trust in domain experts. Tags make this possible.

Tags keep the water filling algorithm stable The water filling algorithm works best when:

initiatives are grouped into coherent domains
voters can focus on the domains they care about
proxies can specialize
sparsity is preserved
noise is minimized

Tags help achieve all of this. They ensure that:

voters don’t see irrelevant initiatives
proxies don’t score outside their expertise
the algorithm fills each domain in a meaningful order
cross domain interference is minimized

This is a huge win for stability.

Tags help enforce competence checks Your idea of requiring a voter to pass a small quiz before assigning a non zero score is strengthened by tags. Why? Because the quiz can be domain specific, initiative specific, and tag specific.

A voter who wants to score a “health” initiative must understand the basics of that initiative’s domain. Tags make the quiz system scalable and fair.

Tags reduce the risk of manipulation Without tags, a malicious initiative could hide under a misleading category, attract votes from uninformed voters, confuse proxies, or distort funding flows.

With tags:

mis tagging is caught in constitutional review
proxies only operate within their domain
voters see clear categories
dashboards can highlight anomalies
domain based caps prevent concentration

Tags are a structural anti corruption tool.

Tags are the constitutional “grammar” of the tax choice system. They define meaning, structure, boundaries, and legitimacy. By requiring:

a fixed tag set defined by law
constitutional review of tag correctness
competence checks tied to tags
proxies specialized by tags
optional delegation caps per tag domain

you create a system that is:

stable
transparent
hard to manipulate
easy to navigate
mathematically elegant
socially scalable

Predicates on services

Tags can be regarded as unary predicates on the public services. A unary predicate p(X) is simply a truth valued property of an object. In this system the object is a service or initiative, the predicate is a tag, and the truth value is whether the service belongs to that domain.

So a service S might satisfy:

health(S)
emergency(S)
infrastructure(S)

and not satisfy others.

This gives a clean, declarative ontology of public services.

Unary predicates are the right level of expressiveness. They are:

simple
composable
non hierarchical (unless you choose to add hierarchy)
easy to audit
easy to reason about
easy to use in algorithms

They avoid the complexity of:

multi-valued attributes
fuzzy categories
arbitrary metadata
user generated tags (which always devolve into chaos)

Unary predicates give you a crisp, constitutional vocabulary.

Constitutional review of tags is essential. Because tags are predicates, mis tagging is equivalent to:

asserting a false property
placing an object in the wrong domain
misleading voters
bypassing domain based caps
confusing proxies
distorting the water filling algorithm

A constitutional review ensures:

predicates are applied correctly
no initiative claims false properties
no initiative hides under benign tags
the ontology remains stable
the system remains predictable

This is exactly what a type checker does in a programming language.

Unary predicates support the water filling algorithm The water filling algorithm relies on:

grouping services into coherent domains
sparse scoring
domain specific funding pools
predictable ordering

Unary predicates give you:

clean domain membership
no overlaps unless explicitly allowed
no ambiguity
no fuzzy categories

This makes the algorithm stable and interpretable.

Unary predicates support competence checks Because each tag corresponds to a domain, you can require:

domain specific reading
domain specific quizzes
domain specific competence

This ensures that non zero scores are:

informed
meaningful
sparse
resistant to manipulation

Unary predicates make the competence system scalable.

Unary predicates support proxy delegation and caps If proxies specialize by tag:

a health proxy scores only health(S) services
a sports proxy scores only sports(S) services
a science proxy scores only science(S) services

This allows:

domain specific delegation
domain specific caps
domain specific expertise
domain specific trust networks

Unary predicates give you the clean boundaries needed for this.

By treating tags as unary predicates, you’ve effectively built a typed, declarative political system. This gives VoTa:

clarity
auditability
resistance to manipulation
algorithmic stability
scalable delegation
meaningful competence checks
clean domain boundaries
predictable funding behaviour

It’s a rare example of political design that benefits directly from formal logic.

Other predicates

Consider the predicate budget(Service, Period, Amount) which is true if the budget of the given Service in the given Period has the given Amount. This opens up a whole world of expressive, query friendly structure inside VoTa. It gives a typed, logic driven public finance system, and predicates like this are what make it powerful for advanced users while still staying clean and constitutional for everyone else.

budget(Service, Period, Amount) is a natural ternary predicate. If tags are unary predicates like:

health(Service)
sports(Service)
emergency(Service)

then budget(Service, Period, Amount) is a predicate that attaches quantitative structure to the service. It expresses:

what the service is
when the funding applies
how much it needs

This is the backbone of the water filling algorithm, because the algorithm needs:

a target amount
a time window
a list of services

Predicates give you a clean, declarative way to express all of that.

Predicates make the system queryable and auditable Advanced users, such as analysts, journalists, auditors, proxies, and civic groups, can write queries like:

budget(S, 2027, A) ∧ health(S)
budget(S, P, A) ∧ sports(S) ∧ A > 10M
¬emergency(S) ∧ budget(S, 2028, A)
budget(S, P, A) ∧ infrastructure(S) ∧ (A < 1M)

This is incredibly powerful because it means:

the entire public finance system is machine readable
dashboards can be built automatically
proxies can specialize
voters can explore funding flows
anomalies can be detected algorithmically

This is essentially giving the public a public SQL for governance.

Predicates integrate beautifully with your tagging system Tags are unary predicates. Budget is a relational predicate. Together, they form a typed ontology of public services. For example: sports(S) ∧ budget(S, 2028, 12M) is a complete description of a funding requirement. This makes:

competence quizzes easier
proxy specialization clearer
domain based delegation caps enforceable
constitutional review more rigorous
the water filling algorithm more predictable

It’s a clean, formal structure.

Predicates support the water filling algorithm mathematically The water filling algorithm needs:

a list of services
their budgets
their scores
their tags
their time periods

Predicates give you:

budget(S, P, A) → the “height” of the bucket
score(User, S) → the “pressure” pushing water into the bucket
Tag(S) → the domain grouping
Period(P) → the time window for allocation

This is exactly the kind of structure that makes greedy algorithms stable and interpretable.

Predicates help prevent manipulation Because predicates are formal and reviewed constitutionally:

you can’t lie about a budget
you can’t hide a service under the wrong tag
you can’t create fake periods
you can’t inflate amounts without scrutiny
you can’t bypass domain based caps
you can’t mislead proxies or voters

Predicates act like a type system that prevents malformed or deceptive initiatives.

Predicates make indirect tax choice more powerful When a proxy delegates scores, they can write rules like:

“For all S where health(S), score +2.”
“For all S where budget(S, 2028, A) ∧ A > 5M, score +1.”
“For all S where sports(S) ∧ Period = 2027, score 0.”

This lets proxies:

express principled positions
automate consistent scoring
maintain transparency
build trust
scale their influence responsibly

Predicates make proxies programmable in a good way.

By treating tags and budgets as predicates, we get a logic based governance system where every initiative is a typed, queryable object. This gives VoTa:

clarity
auditability
resistance to manipulation
algorithmic stability
expressive power for advanced users
clean interfaces for ordinary users
strong foundations for proxies
predictable behaviour for the water filling algorithm

It’s one of the most elegant ways to structure a democratic funding system.

Domain type for a service in Predica


type Currency = Integer;

enum PublicServiceTag
{
    medical,
    pharmaceuticals,
    research,
    science,
    sports,
    infrastructure,
    social_media,
    public_transport,
    roads,
    foreign_aid,
    parks,
    recreation,
    fisheries,
    manufacturing,
    finance,
    defence,
    communications,
    antiterrorism,
    home_security,
    central_bank,
    judiciary,
    police,
    security,
    prisons,
    portals,
    taxation
}

value Date
{
    Integer Year;
    Integer Month;
    Integer Day;
}

value TimePeriod
{
    Date Start;
    Date End;

    constraints 
    {
        Start ≤ End;
    }    
}

entity Budget
{
    TimePeriod period;
    Currency amount; 
}

entity TaxAllocation
{
    TimePeriod period;
    Currency amount; 
}

enum RevenueSource { income_tax, gst, carbon_levy, ... }

entity FundingFlow 
{
    TimePeriod period;
    RevenueSource source;
    Currency amount;
}

entity Initiative 
{
    Integer id;
    String title;
    TimePeriod active;
    PublicService service*;   // services affected
    key {id};
    
    constraints 
    {
        satisfies_NDP(this);
        satisfies_property_rights(this);
        satisfies_no_discretion(this);
    }
}

entity Metric 
{
    PublicService service;
    String name;
    Real value;
    TimePeriod period;
}

enum Attribute
{
    race, sex, religion, ethnicity, political_affiliation
}

entity EligibilityRule 
{
    PublicService service;
    Attribute attribute;   // e.g. age, income, citizenship
    Range allowed;

    constraints 
    {
        // The NDP is almost tailor‑made for constraints. It forbids laws or services that 
        // discriminate based on personal characteristics.
        attribute ∉ {race, sex, religion, ethnicity, political_affiliation};
    }
}

entity Decision 
{
    PublicService service;
    Rule rule;
    Input input;
    Output output;

    constraints 
    {
        // No discretionary authority
        // No decision may reference a person as the cause
        not exists Person p where this.made_by = p;
    }
}

constraints 
{
    // If a rule applies to one person with attributes A,
    // it must apply to all persons with attributes A.
    ∀p1, p2: Person.
        p1.attributes = p2.attributes →
        rule_applies(p1) = rule_applies(p2);
}

// Property rights and the NAP
constraints 
{
    // No entity may alter another's property without consent
    not exists Action a where
        a.target_property.owner ≠ a.actor
        and not a.has_consent;
}


entity PublicService
{
    Integer id;
    String name;
    
    // Alternative to tags using strings or an enum
    //Boolean health;
    //Boolean sports;
    PublicServiceTag tag*;

    Budget budget*;
    TaxAllocation allocation*;

    Initiative initiative* where each.service = this;

    FundingFlow funding* where each.service = this;

    key {id};

    constraints 
    { 
        name ≠ "";
        no_overlap(period) where each in this.budget;

        // Enforces fiscal discipline as a constitutional rule.
        allocation.amount.Σsum ≤ budget.amount.Σsum;
    }
}

entity ServiceBudget 
{
    PublicService S;
    Currency amount;
    Date start;
    Date end;
} 

entity System
{
    PublicService services*;
    Initiative initiative*;
}

Example queries

All services tagged “infrastructure” with their current budget: s.public_service[tag=infrastructure].budget[period.Start.Year=2026].Amount

PreviousChapter 36: Child care NextChapter 38: Failure