Project:Autoconfirmed users
Enable an agent to identify project-local autoconfirmed account status, assess the evidence for it, and determine which actions it permits under the project's current rules.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex
Bundle → Layer → Finding → Questions Filled
5 bundles · 9 layers · 15 findings · 29 questions
Project status identity Establish what the namespace-qualified registry name denotes and where the status applies.
Registry referent
Resolve the entry's intended subject before attributing account behavior to it.
Page versus status
Record whether the registered thing is the autoconfirmed user class, its account status, or the project page describing it.
- What originating registry record or linked resource establishes the intended meaning of Project:Autoconfirmed users? provenance
- Does the entry identify a project document or the account classification described by that document? boundary
Project and account boundary
Locate the classification within the governing project and distinguish account membership from personal identity.
Local status subject
Bind each status assertion to an account and the project whose rules make the assertion meaningful.
- Which project defines this autoconfirmed class, and which identifier resolves the account within it? definition
- Does the governing project recognize any cross-project account history or status, and on what terms? boundary
Automatic qualification Describe the actual conditions that distinguish autoconfirmed accounts from accounts that have merely registered.
Qualification conditions
Identify required predicates, their combination, and any exceptions.
Governing eligibility predicate
Record the conditions for automatic qualification, including whether age, contribution count, or other factors apply.
- What conditions must an account satisfy, and are they conjunctive, alternative, or conditional? definition
- Which authoritative policy or configuration establishes the conditions and any exceptions? provenance
- What evidence distinguishes automatic qualification from manually assigned confirmation? boundary
Qualifying history
Determine how account history is measured when the governing rule uses time or activity.
Age and activity accounting
Make any age or activity assessment reproducible using the project's reference events, counting rules, and threshold boundaries.
- If account age matters, which event starts the clock and exactly when is its threshold satisfied? measurement
- If contributions matter, which actions count and how are deleted, reverted, imported, or cross-project contributions treated? measurement
- Which missing or ambiguous history prevents a defensible eligibility decision? boundary
Effective confirmation state Connect eligibility assessments to observable account status and the mechanism that makes that status effective.
Status observation
Capture authoritative evidence of effective autoconfirmed status.
Confirmation evidence
Record how status was established without assuming that a visible group listing or a single successful action proves it.
- Which project interface or authoritative record exposes effective autoconfirmed status, and does it represent that status explicitly or dynamically? provenance
- At what time was the account checked, and what result was returned? measurement
- Could the observed capability instead come from manual confirmation or another group? boundary
Status reassessment
Identify when qualification becomes effective and when prior observations require review.
Activation and change
Record the project's activation and reevaluation behavior without assuming permanence, immediate activation, or an administrative revocation mechanism.
- When and through what mechanism does satisfying the rule make autoconfirmed status effective? definition
- Which rule changes or account events require the agent to check status again? action
- If eligibility calculations and observed status disagree, which authority resolves the discrepancy? provenance
Autoconfirmed action boundaries Determine what this status contributes to action permissions and where additional restrictions control the outcome.
Status permission contribution
Identify the rights and exemptions specifically associated with autoconfirmation on the governing project.
Attributable rights
Record the project's actual permission mapping and distinguish it from rights obtained through other account classifications.
- Which actions or exemptions does the current project configuration associate with autoconfirmed status? definition
- Which permission differences distinguish autoconfirmed accounts from registered accounts and manually confirmed accounts? boundary
- What authoritative source and effective date support this permission mapping? provenance
Proposed action evaluation
Evaluate a concrete operation using the account's status and all applicable action constraints.
Effective action decision
Assess a proposed operation against the required rights and relevant restrictions, keeping permission denial distinct from absence of autoconfirmed status.
- For this action and target, is autoconfirmed status required, sufficient, or only one possible source of the required right? action
- Which account restrictions, target protections, or other project controls affect whether the action may proceed? boundary
- If the action is denied, what evidence distinguishes a status problem from another applicable restriction? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Check these first
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these check these first hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Identifiers and schemes
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these identifiers and schemes hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Real-world use
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these real-world use hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Typical measurements
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these typical measurements hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Failure modes and hazards
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these failure modes and hazards hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Regional variation
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these regional variation hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Recalled without web access and unsourced; every item is a lead to verify.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of Project:Autoconfirmed users this model covers, and on what evidence? provenance
Classifiers Filled
- Family
- Thing Registry
- Category
- Society, people and institutions
- Entry kind
- thing
- Plane
- SOC
- Domain
- SOC.PER
What it is Filled
Autoconfirmed users are registered accounts on a MediaWiki-based wiki that automatically acquire a locally configured set of permissions after satisfying eligibility conditions such as account age and edit count.
In scope
- The project and account population to which autoconfirmed status applies
- Rules and account activity used to establish automatic eligibility
- Evidence of an account's effective autoconfirmed status at a particular time
- Permissions attributable to autoconfirmed status and restrictions affecting their use
- The relationship between autoconfirmed status, manually assigned confirmation, and other account groups
Out of scope
- The full biography, identity, or trustworthiness of an account holder
- General account registration, authentication, and credential management
- Administrator, moderator, or other separately granted roles
- The substantive quality or acceptability of contributions
- The descriptive project page as a document, including its editorial history
- Professional occupations, employment relations, and licensing
Why it exists Filled
Enable an agent to identify project-local autoconfirmed account status, assess the evidence for it, and determine which actions it permits under the project's current rules.
Distinguishing features Filled
- The referent must be a project-defined account status or user class; a page merely titled Project:Autoconfirmed users requires a separate document interpretation.
- Automatic eligibility must be distinguishable from confirmation explicitly assigned by an authorized actor.
- A status assertion must identify its project; confirmation on one project is not sufficient evidence of confirmation on another.
- Autoconfirmed status must be distinguished from both account registration and authorization to perform a particular action.
- The status concerns an account's position under project rules, rather than a person's occupation, identity verification, or demonstrated reliability.
What robots and AI may and may not do Filled
Must not
- Game edit counts or account age to obtain autoconfirmed status for an account.
- Use autoconfirmed rights to vandalize or push undisclosed paid edits.
- Operate many accounts to look like independent users.
- Edit protected pages against the community's consensus.
Only with a human decision
- Running a bot or automated editing on a wiki, which needs community approval.
May
- Explain how autoconfirmed status is gained on a wiki and what it allows.
- Edit as an autoconfirmed account within the wiki's policies when the account is the agent's own and disclosed.
Moral aspects Filled
- The status rests on community trust; misuse damages open editing.
- Wikis are widely read, so abuse spreads misinformation.
Who is affected
- Wiki communities
- Readers
Owners Filled
Steward
The community and administrators of each wiki; the software sets thresholds per site.
Links to other meta-models Missing, in the backlog
Not described yet. This gap is in the card backlog.
What else AI and robots need to interact with it Filled
Identity and identifiers required Filled
- Vercy registry: vr.tr.project-autoconfirmed-users
- Wikidata: Q11171729 (https://www.wikidata.org/wiki/Q11171729)
Direct properties not applicable Not applicable
- Registry referent interpretation: account status | user class | descriptive project page | unresolved
- Governing project: The project or wiki whose rules and account namespace govern the status
- Eligibility rule: A versioned rule identifying required conditions, exceptions, and effective dates
- Qualifying account age: Elapsed time in seconds or days from the project's specified reference event; applicable only if required
- Qualifying contribution count: Nonnegative integer under the project's counting rules; applicable only if required
- Eligibility assessment: conditions met | conditions unmet | indeterminate
- Observed autoconfirmed status: effective | not effective | unknown, qualified by observation time and source
- Confirmation mechanism: automatic | manually assigned confirmation | other mechanism | unresolved
- Status-derived capabilities: Project-defined actions or exemptions attributable to autoconfirmed status
- Effective restrictions: Applicable account, action, resource, or project restrictions
Plane SOC: no invented physical properties.
Recognition not applicable Not applicable
Not applicable
Autoconfirmed status is an account permission state that must be verified from authoritative account information rather than visual appearance.
Capabilities and actions required Filled
- Resolve whether the registry entry denotes an account status, user class, or descriptive page.
- Evaluate an account against the project's documented autoconfirmation conditions.
- Record observed status with its project, evidence source, and observation time.
- Explain unmet conditions or missing evidence without promising a confirmation date.
- Check whether a proposed action is permitted after considering status-derived rights and applicable restrictions.
- Reassess eligibility and permissions when account evidence or governing rules change.
Hazards and failure modes required Filled
- Sleeper accounts built up to gain autoconfirmed rights for vandalism.
- Thresholds set too low weaken page protection.
Standards and interfaces not applicable Not applicable
Not applicable
This project-local account status is governed by local permissions policy rather than a universal standard or regulatory classification.
Context of use required Filled
- This project page explains an automatically assigned account status within a collaborative editing community.
- It helps contributors and automated agents understand local eligibility conditions and the permissions associated with that status.
- Its rules must be interpreted for the particular project because eligibility and permissions can differ between projects.
Sources Filled
- Wikidata item Q11171729: Project:Autoconfirmed users - identity and sense of the item
- Wikipedia: Wikipedia:Autoconfirmed users - general description of the item
Open questions
- Which originating project and source record does vr.tr.project-autoconfirmed-users refer to, and does it denote a user class or a project document?
- What are that project's authoritative autoconfirmation conditions, exceptions, and exact account-history counting rules?
- How does the project expose effective autoconfirmed status, and how does it distinguish automatic eligibility from manually assigned confirmation?
- Which rights and exemptions currently derive from this status, and which restrictions can prevent their exercise?
- When is status reevaluated, can it cease to apply, and what happens to previously qualifying accounts when the governing rules change?
Machine files
Provenance
thing registry research (pass 2) · unreviewed
Built from: models/things/publications/thing-q11171729/spec.json