The Charter

The Charter: Design Principles and Promises

Purpose

Define an adoptable standard for independently maintainable, user-sovereign software, rather than creating another software copyright license. The manifesto describes values; this charter provides a bridge to independently assessable practice.

Six pillars

Overarching test: The Freedom to Continue

Proposed JRCv1 extension: Economic freedom should include an openly discussed and versioned method for measuring human attention, beyond provider invoices. Distinguish paid labor, imputed volunteer/stewardship attention and user time burden. Avoid compulsory universal person-specific valuations and invasive tracking. See Human Attention Accounting.

A project should be able to demonstrate at least one independent person or organization reproducing its stack, understanding its costs, operating it, upgrading it and performing a complete user-data migration without privileged help from the original creator.

What this is and is not

• Is: philosophy, voluntary operational standard, reference implementations, independent reproducibility challenge, reusable templates, evidence-based conformity checks.
• Is not: new OSI-approved software license, mandated cost ceiling for resellers, guarantee of global public-domain status, universal claim to ownership of other people's data, exemption from law, compulsory trademark program or requirement that every adopter use an identical stack.

Compatibility without capture

AT Protocol is a foundational default. Where not appropriate or not yet capable (especially private and organizational records), an application must transparently document a portable and user-controllable alternative or its current limitation; conformance levels should make the distinction visible. Avoid pretending all types of data are supported by AT Protocol today.

“100% agentic development” describes intentional embrace and full process disclosure, not an obligation to remove human accountability or hide human intellectual contribution. Publication must never expose secrets.

Non-negotiable process safeguards

1. Public issues and transparent rationales for standards decisions.
2. Human-reviewed changes, threat modeling, CI security checks, and progressive releases for operational changes.
3. Fair attention to community participants, including right to disengage or fork.
4. Standards and badge claims must be verifiable; never pay-to-play for permission to use code or voluntarily assess a project.
5. Project-level financial stewardship commitments must be separable from the copyright license itself.
6. Adoption must never require endorsing one person's ideology, reputation or personal brand.

Proposed Conformance Standard: Prove Your Freedom

This is a draft assessment framework, not a certification or claim any product already qualifies. The project must publish clear, independent evidence; self-attestation alone is not verification.

Evaluation categories

1. Code and rights

Source available; copyright and dependency provenance documented; redistribution, modification, commercial distribution and forks legally permitted for covered original code. Separate any proprietary or restricted components and document their effect.

2. Development and AI transparency

Durable specifications, design decisions, agent/tool versions and sanitized session context; deterministic tests and published release/build instructions; ability to swap AI agents without losing intent.

3. User data sovereignty

AT Protocol identity and portable data where applicable, documented data boundaries, real export and import, revocable grants where supported, deletion and retention disclosures, special rules for shared/private data.

4. Operations and resiliency

No secret proprietary deployment process; infrastructure descriptions, backup/restore and rollback procedures, reproducible release and self-hosting or independent-provider path. The ability to continue without one maintainer is demonstrated, not merely claimed.

5. Economic transparency

Privacy-safe provider costs, reconciled bills and fresh estimates, manual costs and reserves labeled, methodology, measurement window, per-user/unit costs with denominators and allocation assumptions; public suggestions for cost efficiency.

6. Open community and governance

Accessible issues and proposals; documented review rules, maintainer succession, dispute and appeal process, contribution credits, copy/fork freedoms and an opportunity for independent stewardship.

Progress levels, not a purity contest

Projects should be able to publish evidence for each category independently. Proposed flags:

• Exploring: interest, documented gaps, no conformance claim.
• Implemented (self-reported): public evidence links for listed requirements.
• Independently reproduced: an external reviewer has verified the claim and published test methods/results.

Never call a self-reported badge an independent certification. Use dated, versioned standards. A project may report '4 of 6 pillars evidenced' and invite help with the remaining two.

Machine-readable report concept

Use an open JSON/YAML manifest with standard_version, project_id, pillar, claim, evidence_uri, evidence_hash, reviewer, reviewed_at, verified and limitations. A public AT Protocol record can point to the report, but the repository must remain usable without a specific PDS or directory operator.

Acceptance test

Ask an outsider to fork, configure a clean environment, build/release, deploy, export a test user's records, migrate them to another provider, calculate operating cost, submit a safe infrastructure-cost PR and test a maintainer handoff. Log blocked steps and use them to improve the standard.

Risks

A standard that is impossible for smaller projects to adopt will not spread. A standard too easy to claim becomes marketing theater. Incremental transparent progress and public evidence should bridge the two.

Open, Agent-Native Development

Foundational claim

An application is not truly independently reproducible if others can only copy today's code but lack the intent, context, specifications, release process and operational knowledge necessary to maintain it. Publish the full process, as far as rights, privacy and security permit.

Expected repository artifacts

1. Product rationale, user requirements, tradeoffs, roadmap and structured specifications.
2. Architecture decisions and rejected alternatives, including performance and security tradeoffs.
3. Agent instructions (for example AGENTS.md), model/tool and runtime versions, skills and safe environment setup.
4. Sanitized prompts, conversation transcripts or equivalent structured intent histories, with provenance and redaction indicators.
5. Build scripts, lockfiles, dependency manifests, test suites, validation commands and expected outputs.
6. CI/CD workflows, environment templates, release checklist, release signing method, rollback instructions and deployment playbooks.
7. Infrastructure-as-code and open infrastructure manifest, with safe stand-ins for secrets and billing IDs.
8. Security model, responsible disclosure, dependency update process, incident-response playbook and support runbooks.
9. A contributor path to use any competent coding agent, not one locked proprietary assistant.
10. Public issue/PR records that connect suggested improvements to tests, accepted decisions and production results.

What FULLY means in practice

Publish enough detail that someone can reconstruct the decisions and produce a functioning independent instance. Not publishing actual credentials, user private messages, undisclosed vulnerabilities, third-party proprietary data, or copyrighted source you cannot redistribute. Use a public redaction policy identifying protected categories and disclose where omissions exist without revealing the protected material.

Agent workflow

Propose -> clarify -> specify -> threat-model -> implement -> test -> compare -> review -> merge -> release -> measure -> publish lessons. Agents can automate bounded work, produce proposed patches and raise safety concerns. Humans authorize critical deployments and operational changes.

Measurements

• Clean-room build pass rate.
• Independent reproduction time and blockers.
• Recovery time for restoring from backups.
• Percentage of major decisions traced to evidence.
• Number of agent-specific dependencies that cannot be replaced.
• Security review and regression coverage.

Existing precedent

GitHub Spec Kit demonstrates specification-driven workflows, agent integration and reproducible development assets. The proposed innovation is to tie this to public-domain intent, independent operations, data sovereignty and cost transparency as a shared movement: https://github.github.com/spec-kit/

AT Protocol and User Sovereignty

Intent

AT Protocol is a core technical pillar because the product should not make the service operator the sole authority over a user's digital identity and records. The goal is meaningful user control and portability, not the legally inaccurate statement that all data is owned exclusively by one person.

Proposed architecture

• Use decentralized identifiers, portable handles where appropriate, user-associated repositories and open Lexicons for records and integrations.
• Keep authoritative user-generated records portable; treat search indexes, analytics projections and app views as derived and rebuildable.
• Publish proposed Lexicon NSIDs and versioning rules; let anyone build compatible clients and servers.
• Design import/export, verification, key rotation, recovery, deletion and migration as product features, not administrative favors.
• Use least-privilege access for third-party apps; report access and offer revocation where supported.
• Define shared spaces, jointly authored records, organizational records, provenance and conflicting rights explicitly.
• Keep the user-facing app interchangeable; avoid centralizing essential state in one provider-only database.

AT Protocol limits as of October 17, 2026

• Default AT Protocol public repositories are public and can be replicated. Removing content from the primary server cannot promise removal from all copies.
• AT Protocol account migration is a design goal and supported in important contexts, but portability of all app data and operational recovery are not automatic.
• Atproto Spaces (permissioned/non-public data) was alpha as of August 20, 2026 and under development in October; do not claim production-grade private-data security merely because Spaces exists.
• Encryption, key management, access controls, recovery policies, legal data-subject requests and physical backups require additional engineering.

Promise to users

The service itself will not claim ownership of personal content because it hosts it. It will specify legitimate processing rights and obligations in binding terms. Do not sell personally identifying data or train models on private user information without explicit informed consent in services that adopt the stewardship pledge.

Unanswered design questions

How should collaborative ownership work? How does recovery work when a user loses keys? Can public records be selectively forgotten? How should shared data be exported when participants disagree? What must an app do if atproto support is partial?

Sources: https://atproto.com/guides/overview ; https://atproto.com/specs/lexicon ; https://atproto.com/blog/atproto-spaces-alpha ; https://atproto.com/blog/devex-goals-for-spaces

Open Economics and Open Infrastructure Manifest

Core statement

Our books are open. Our infrastructure is open. Our future is open to contribution.

Provider billing integration, usage-derived projections, manually quantified obligations, reserves and pricing methods should form part of an application’s documented public operating model. Use read-only, least-privilege connectors and publish aggregates safe for public inspection, not the raw credentials or identifiable billing records.

Cost categories

Compute, databases, storage, bandwidth, backups, monitoring, domain and certificates, app-store and release operations, CI/CD, LLM inference and coding agents, customer support, paid human development, professional fees, taxes, insurance, contingency, amortized capital expenses, unpaid volunteer labor when disclosed as donated rather than falsely claimed as cash expense, and operating reserve.

Data quality and display

Distinguish (1) actual finalized invoice, (2) current usage estimate, (3) manual actual, (4) allocated/shared cost, (5) forecast and (6) reserve. Display provider, reporting interval, last sync, currency, exchange assumptions, metric numerator and denominator, rounding and reconciliation status. Public cost-per-user figures should distinguish active users from paying users and specify whether costs are variable or shared.

Reference data architecture

Provider connectors -> ingestion/normalization -> FOCUS-aligned financial events -> private raw store -> aggregation and redaction -> signed public cost snapshot -> dashboards, export and AT Protocol publishing. Maintain provenance and reconciliation links. Cost data is not always available real-time; freshness should be explicit.

Useful existing tools: FOCUS 1.4 for billing normalization; OpenCost for cloud-native cost allocation; Infracost for PR-level infrastructure estimates; OpenTofu for declarative deployable infra. Avoid claiming these tools cover every provider or manual cost out of the box.

Open infrastructure pull requests

The project publishes open-infrastructure.yaml and referenced deployable infrastructure code. A contributor, including an agent, proposes a change: cost savings, performance optimization, alternative provider, smaller instance, caching, storage tier, backup policy or safer release pipeline.

Every PR should include:

• Before and after architecture and configuration diff.
• Scope, assumptions, migration and rollback plan.
• One-time transition costs and ongoing cost estimates.
• Reliability/security/privacy/accessibility analysis and benchmarks.
• CI validation with read-only test permissions, never automatic unrestricted production changes.
• Post-deployment observation window and actual reconciled savings or explanation for a miss.

A saving that breaks backups, weakens security or increases downtime is not a valid win.

Sustainable pricing

Human attention is part of the economic picture. The proposed Human Attention Accounting extension adds explicit, nonoverlapping views of paid maintenance, imputed donated labor, and user attention burden. The public dashboard should show each separately rather than burying attention under “free volunteer work” or implying that users' lost time appears on an invoice. Pricing cannot simply equal cash bills plus every imputed impact; those are different ledgers.

Transparency is not the same as zero payment. The steward may charge a reasonable amount to cover labor, resilience and ongoing obligations; publish the allocation and rationale. The pledge favors passing efficiencies to the community through lower prices, better quality, reserves or renewed development. Competing providers may price differently; the license must not restrict them.

Open questions

What privacy-safe minimum aggregation threshold applies? How should contributions reducing bills be credited? Should costs be attested by third parties? How much staffing and surplus is appropriate? How do we avoid customer-identifiable unit economics? What happens when an API cannot disclose certain provider pricing?

Sources: https://focus.finops.org/docs/specification/v1-4/ ; https://opencost.io/ ; https://www.infracost.io/ ; https://opentofu.org/

Human Attention Accounting (HAA): Draft Standard Extension

Proposal for JRCv1 discussion, October 17, 2026. The user has explicitly requested that human attention have a monetized representation in Quartermaster and that the underlying valuation be openly, broadly debated. No universally accepted hourly price or methodology has yet been agreed. This document proposes a public and revisable method, not a declaration of consensus or a claim that a person has a market price.

Core principles

1. Human attention is a real economic resource even when donated. It cannot be treated as free simply because a human did not issue an invoice. Do not confuse valuing time with treating a human being as a commodity.
2. Software should minimize involuntary demands on attention. A cost-saving change that increases cognitive load, support burden or time spent by users may be a net loss even if cloud bills fall.
3. Value assumptions are public and contestable. Publish source, location/year/currency, rate-selection process, reference scenarios, uncertainty ranges and adjustment rules. Anyone can submit reproducible criticism or proposals through public PRs, not only accountants or maintainers.
4. No mandatory global rate. A common measurement standard may be globally discussable while context-dependent rates vary by geography, purpose, opportunity cost and task. Provide community-maintained reference rates and transparently allow local overrides. Never infer that a person with lower wages has less inherent worth.
5. User time belongs to users. User-attention costs may be estimated from consensual aggregate research or disclosed task models. No covert attention tracking, behavioral scoring, identity-level surveillance or sale of attention data. Do not optimize a product to maximize engagement time.
6. Avoid double counting. Paid workers' actual compensation is a cash expense; it must not also be added again as an estimated attention expense. Donated/volunteer effort and attention burdens imposed on users appear as separate imputed economic cost categories.

Two core ledgers, three useful lenses

Optional additional lenses: (a) total economic footprint, combining these without overlap; (b) attention avoided, the estimated time saved relative to a documented baseline; and (c) attention debt, foreseeable recurring attention caused by avoidable design/maintenance deficiencies. These are analytical measures, not universally accepted accounting measures.

Calculation v0 proposal

For a task class j: attention_hours_j = instances_j × active_minutes_per_instance_j / 60.

imputed_attention_usd_j = attention_hours_j × declared_reference_rate_usd_per_hour_j.

stewardship_full_cost = cash_operating_cost + imputed_unpaid_stewardship_attention.

total_economic_footprint = stewardship_full_cost + estimated_user_attention_burden.

Paid human time already included in cash operating cost must not be added again as imputed attention. Interruption / context-recovery overhead may be separately modeled only with a documented, nonoverlapping time estimate. Do not imply that money is actually being transferred when a cost is imputed.

Example (illustrative, hypothetical, not JRC's actual rates)

• Cloud and other vendor bills: $500 per month.
• Paid support: 4 hours × $50 = $200, recorded as actual paid expense.
• Volunteer code-review and security work: 8 hours × $40 reference = $320, recorded as imputed donated labor, not paid cost.
• The product requires 10,000 user workflows × 45 seconds = 125 user-hours monthly; at an illustrative $20 reference = $2,500 user-attention burden.

Dashboard displays $700 cash operating cost; $320 donated attention; $1,020 full stewardship economic cost; $2,500 user attention burden; and $3,520 estimated combined footprint, all distinctly labeled. This does not mean Quartermaster should charge users $3,520 or that the user time is revenue. If the organization pays reviewers, their invoices move from the noncash ledger into the paid ledger rather than being counted twice.

Open reference valuation process

• Launch a public debate topic titled “What is an hour of human attention worth?” Publish multiple defensible models rather than picking a figure before consultation.
• Candidate scenarios: living-wage baseline; actual compensation for paid work; geographic cost-of-living-sensitive reference; opportunity-cost bands; a purpose-neutral common baseline for evaluation; and user-selected values. These are proposals to compare, not agreed policy.
• Accept evidence and critiques from workers, disabled users, accessibility specialists, maintainers, economists, psychologists, and ordinary users.
• A published reference table must name its stewards, update date, source data, assumptions, equity concerns, dissenting opinions, and version identifier. Adoption is voluntary; alternative valuations remain visible.
• Have independent contributors demonstrate impacts on a reproducible benchmark app and test whether optimizing financial expenses unintentionally moves the burden onto users or volunteers.

Proposed machine-readable record

attention_cost:
  methodology: jrc-human-attention-draft-0.1
  activity: pull_request_review
  perspective: unpaid_stewardship # or user_burden / paid_work
  quantity: 8
  unit: hour
  rate:
    amount: 40
    currency: USD
    basis: illustrative_reference_only
    geography: unspecified
  imputed_amount: 320
  is_cash_expense: false
  measurement: voluntary_aggregate_report
  confidence: estimated
  disclosure: public_aggregate
  reference_period: monthly

For user attention, report observations only in aggregate, with consent and privacy safeguards. A project can use public task benchmarks and opt-in usability studies instead of telemetry. Publish data quality and uncertainty; suppress low-count statistics.

Conformance and decision gates

A JRC application should disclose whether attention is included, for whom, how estimates were obtained, and what is missing. The first conformance levels can require disclosure and methodology, not mandatory adoption of any one dollar value. A project may not claim financial savings while hiding increased maintenance/support/user attention burdens. A PR should report total cost impact and projected attention burden alongside cash savings, security, privacy, resilience, and accessibility.

Intellectual background and caution

The US Department of Transportation uses context-sensitive monetary valuations of travel-time savings for benefit/cost analysis; this shows that time valuation is an established analytical practice, not that there is a universal number for human attention. USDOT guidance. FOCUS 1.4 standardizes provider billed and effective costs; Quartermaster's human-attention imputation must remain separately labeled rather than masquerading as FOCUS-reported bills. FOCUS cost definitions.

Unresolved questions

Who has authority to publish reference rate versions? Should the charter give equal standing to conflicting valuation scenarios? How should involuntary interruption and cognitive load be measured without invasive tracking? Can usability improvements be verified without imposing additional burdens on participants? How do we avoid extracting unpaid work from volunteers by making it look merely like a public cost number? When should attention-reduction projects be prioritized over cloud-bill savings?