Independent stewardship and citable specification releases.

Current status and licensing

This document concerns Astra Science Network only. Independent council governance, a legal wrapper, and scholarly indexing are proposals, not established arrangements. Confirm existing rights holders, operating responsibilities, and contributor permissions before any governance or asset change.

Application source remains private. The portable data schema alone has a separately adopted MIT license; no project-wide software or documentation license is adopted by this governance strategy. Select appropriate terms only after a rights and dependency review and an explicit decision by the authorized rights holders. Existing third-party material retains its own applicable license.

Confirm repository publication, copyright holders, contributor grants, trademarks, contracts and data-controller responsibilities. This release does not relicense existing work or provision paid legal, registry, hosting or indexing services.

MILESTONE 1

Independent steering without institutional capture.

Structural architecture

Use three separated functions: a technical steering council decides specification changes; a legal entity holds assets and contracts; an independent conduct/appeal process handles procedural disputes. A non-profit board can decline unlawful actions, but should not silently rewrite technical RFC outcomes. Publish the escalation boundary in both charter and legal agreements.

Proposed seven-seat council

• Three independent-contributor seats, two academic/library seats, one implementation/operator seat, and one public-interest/research-infrastructure seat.
• One vote per person. Institutions nominate candidates for their designated seats; contributions and elections determine appointment. Membership fees, donations and company size buy no votes.
• No more than two seats share an employer or controlling organization. Disclose employment, contracts, funding and material dependencies. Seat-class labels alone do not establish independence.
• Two-year staggered terms, maximum two consecutive terms, published vacancies and a documented recall process.
• A voter roll based on a published contribution window: for example, three substantive accepted contributions over 180 days, including review, documentation, implementation, accessibility or community work. Criteria require community ratification and an appeal route. Do not make commit counts the electorate.

Voting, RFCs and conflicts

• Ordinary decisions: seek consensus during a minimum 14-day public review; otherwise require at least four affirmative votes and a five-member non-conflicted quorum, including two independent-contributor and one academic/library member.
• Protected decisions—charter changes, licensing policy, asset transfer or dissolution—require six affirmative votes, a 30-day notice period, a published rationale and any legally required member/board approvals.
• Record votes, dissent, conflicts, recusals and response to material objections. Recused members do not vote on affected matters. If quorum fails, use pre-elected eligible alternates or defer; the founder gets no unilateral override.
• RFC lifecycle: draft → public review → requested changes → accepted/rejected/deferred → implementation → conformance review. Every decision targets a frozen RFC revision.
• A small, independently selected appeal panel reviews procedure, conflicts and exclusion; it does not declare scientific truth. Time-bound appeals and publish redacted outcomes where privacy requires.
• Security emergencies permit a documented, narrow response for up to 72 hours before council review. Emergency powers cannot change licensing, voting rights or permanent control.

Legal wrapper options

Choose jurisdiction after confirming participants, funders, banking, staffing and legal obligations. Formation costs and professional review require separate authorization; no entity is created by this document.

Asset and rights transfer

Prepare an inventory for domains/DNS, trademarks, repositories, package namespaces, signing keys, CI, hosting, storage, contracts and funds. Identify legal ownership and technical administrators separately. Establish institutional accounts, at least two authorized maintainers, hardware-backed MFA where available, and tested recovery. Never share a founder password as a transfer mechanism.

Application source remains private; broader project-wide licensing is not adopted by this strategy. The separately published Portable Decision Record schema has a schema-only MIT license, which does not license the application or research data. Inventory copyright ownership, contributor permissions and dependency obligations before proposing software or documentation terms. Record selected licenses and SPDX identifiers only after authorized adoption. Existing third-party content keeps its license. A charter cannot relicense contributors’ work without sufficient rights. Patent and trademark policies require separate decisions.

Transfer service control in reversible stages. Preserve production data and consent boundaries; governance membership does not grant access to private researcher records. Review controller/processor obligations and notify affected users where required.

Implementation timeline

1. Weeks 0–2: evidence and continuity. Verify steward/rights, inventory assets and backups, publish a proposed charter and risk register. Freeze only irreversible governance changes, not routine site maintenance.
2. Weeks 3–6: public ratification. Consult contributors and institutions, resolve eligibility appeals, publish the voter roll and select an interim council with a maximum 90-day mandate. This timetable is a target, not a claim of participants or consent.
3. Weeks 7–12: legal and administrative preparation. Evaluate sponsor/entity options, obtain authorized legal review, settle IP/patent/conduct policies, and document operational responsibilities. Extend this phase if legal or funding requirements are unmet.
4. Following quarter: staged transfer. Run two RFC decision cycles, test recovery, transfer low-risk assets first, rehearse DNS/repository rollback and then transfer production administration under approved agreements.
5. Six-month review. Publish concentration, participation, RFC latency, appeal outcomes, operating costs and transfer exceptions. Hold the first regular staggered election once eligibility is established.

Risk mitigation

• Capture: employer/funding disclosures, affiliation caps, staggered elections, protected votes and funding-independent technical decisions.
• Sybil or hostile elections: meaningful contribution history, deduplication with privacy safeguards, published eligibility challenges, independently checked vote counts and no token-weighted ballots.
• Bureaucratic bloat: one standing technical council, time-limited task groups, annual policy review and reporting on decision latency. Add committees only for demonstrated workload.
• Succession failure: documented access inventory, multiple administrators, recovery drills and contractual exit terms. Do not remove existing access before successor recovery succeeds.
• Ideological exclusion: published evidence/behavior criteria, recorded minority positions and an appeal path. Separate conduct enforcement from disagreement about a scientific claim.

MILESTONE 2

Release useful scholarly objects, then earn indexing.

Structural architecture

Do not mint a DOI for every commit or tracking click. Curate substantive, consented release objects: a specification version, evidence schema, assessed mapping collection, technical review or correction report. Routine activity belongs in provenance, not an artificial publication count.

Accepted RFC / assessed contribution
→ rights and attribution check
→ frozen release + canonical manifest + artifact digests
→ metadata validation + duplicate detection
→ one eligible registrar/repository adapter
→ idempotent deposit + reconciliation
→ DOI resolution and metadata verification
→ public landing page + version relations
→ OpenAlex observation and index-coverage dashboard

Citable fragment model

SpecificationRelease:
  release_id, version, repository_url, commit_sha,
  title, abstract, creators[{name, orcid, consent_ref}],
  contributors[{role, scope}], rights, issued_at,
  artifacts[{path, media_type, digest}], related_identifiers,
  doi:null, registrar:null, registration_state

MetadataFragment:
  fragment_id, parent_release_id, stable_anchor,
  schema_path, change_summary, authorship_refs,
  supporting_review_ids, previous_fragment_id, digest

DepositJob:
  release_digest, provider, idempotency_key,
  submitted_at, external_id, state, last_error, attempts

Fragments resolve inside a frozen parent release, for example /spec/releases/1.2/#claim-schema. Mint separate identifiers only when a fragment is independently meaningful and meets repository/registrar criteria. A hash is a content identifier, not a DOI or evidence of academic impact.

Provider adapters

• DataCite: use an eligible member/client or repository deposit route. Map current supported resource types, creators with name identifiers, title, publisher/repository, year, version, rights, descriptions and related identifiers. Validate against the selected schema version before submission.
• Crossref: use an eligible membership/sponsoring arrangement and an appropriate supported deposit/content type. Reviews or reports require their relevant metadata and relationship rules. Do not route arbitrary schema changes to an unsupported type.
• One registrar per object: select Crossref or DataCite rather than creating duplicate DOIs for the same release. Keep a unique release-digest/deposit mapping; reconcile uncertain responses before retrying.
• OpenAlex: query its supported API to observe whether a DOI/work and its relationships are represented. Follow current correction/submission channels where available; do not invent a universal push-to-index endpoint. Index appearance is asynchronous and not guaranteed.
• Public discovery: serve stable landing pages, structured scholarly metadata, sitemap entries and citation exports; offer OAI-PMH or other harvesting interfaces only if there is a documented consumer requirement. Metadata exposure alone is not index acceptance.

Implement adapters behind the existing Worker control plane with versioned JSON Schema/Ajv validation and a durable job store. Use the authorized repository/registrar’s supported credentials server-side. Suggested states: prepared → submitted → registered → resolution_verified → observed_in_index, with failed/needs_reconciliation branches. Indexing status is separate from registration status. No credentials or external deposits are activated in version 129.

Non-disruptive rollout timeline

1. Weeks 0–2: inventory candidate objects and rights; select an institutional repository partner; define preservation, correction and withdrawal policies.
2. Weeks 3–4: implement metadata generation and offline validation. Publish sample citation packages without invented DOI strings. Reconcile creators, affiliations, ORCID control and consent.
3. Weeks 5–8, contingent on authorization: validate deposit behavior in the selected provider’s test environment; check duplicate prevention, retries, metadata updates and redirects. Register a small consented release only after service terms and costs are approved.
4. Following months: observe DOI resolution and OpenAlex coverage, investigate missing/incorrect records, and publish coverage timestamps. Do not attach a guaranteed index-ingestion deadline.
5. After a sustained publication record: evaluate eligibility and submit a documented case through current Scopus/Web of Science selection channels where an eligible content venue exists. Expect assessment cycles outside ASTRA’s control.

Scopus, Web of Science and university adoption

These are selective indexing systems, not general write APIs into which ASTRA can insert every artifact. Their APIs mainly provide licensed access to indexed content; API access does not grant publication selection. Check current policies for the relevant venue/content type before applying.

Work with an academic library and eligible repository or publication venue. Demonstrate transparent governance, research ethics, meaningful review, persistent identifiers, metadata quality, regularity, preservation and correction handling. If standalone schema fragments are ineligible, keep them accessible through parent releases and repository discovery rather than misclassifying them.

Co-design contribution dossiers with actual promotion committees. Cite released artifacts and show corroborated use, corrections, replication contributions and review scope. Tenure recognition and h-index changes cannot be guaranteed by a DOI or an ASTRA metric; record institution-specific written acceptance and observed outcomes separately.

Risk mitigation

• Index rejection: validate types and eligibility before depositing; publish rejection/coverage status accurately; maintain repository discovery regardless of index outcomes.
• Citation spam: release thresholds, duplicate detection, no reward for raw activity volume, and separation of assessed artifacts from telemetry.
• Metadata drift: pin schema versions, keep immutable deposit inputs, append corrections and monitor landing-page resolution.
• License/credit disputes: rights checks, consent, attribution appeals and version-preserving withdrawal notices. No third-party relicensing.
• Cost and vendor dependence: provider-neutral exports, qualified repository partners, documented migration/redirect commitments and approval before any fees or recurring service.

Milestone completion evidence

This is not a claim that the project has only two remaining adoption obstacles. Security, researcher usefulness, real pilot evidence and sustainable operation retain their separate gates.

Version 128 adoption architecture → · Research workspace →