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.
recalled by Codex without web access - no source was read
Researched by: Codex
Purpose and description
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.
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.
It can be 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..
Distinguishing features
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.
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
- 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
Characteristics
- Registry referent interpretation
- account status | user class | descriptive project page | unresolved Prevents a namespace-qualified page title from being silently treated as a social role.
- Governing project
- The project or wiki whose rules and account namespace govern the status Eligibility and permissions require a specific project context.
- Eligibility rule
- A versioned rule identifying required conditions, exceptions, and effective dates Allows an agent to evaluate eligibility without assuming universal thresholds.
- Qualifying account age
- Elapsed time in seconds or days from the project's specified reference event; applicable only if required An age condition cannot be evaluated without its reference event and boundary convention.
- Qualifying contribution count
- Nonnegative integer under the project's counting rules; applicable only if required A displayed total may differ from the activity counted for eligibility.
- Eligibility assessment
- conditions met | conditions unmet | indeterminate Separates a rule-based assessment from observed effective status.
- Observed autoconfirmed status
- effective | not effective | unknown, qualified by observation time and source Supports decisions grounded in current account state.
- Confirmation mechanism
- automatic | manually assigned confirmation | other mechanism | unresolved Similar permissions do not establish that an account is autoconfirmed.
- Status-derived capabilities
- Project-defined actions or exemptions attributable to autoconfirmed status Connects the classification to decisions an agent can make.
- Effective restrictions
- Applicable account, action, resource, or project restrictions Status alone may be insufficient to authorize an action.
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 5 bundles · 9 layers · 15 findings · 29 questions.
Project status identity Establish what the namespace-qualified registry name denotes and where the status applies.
The registry provides no definition, and the Project prefix makes confusion between a descriptive page and its subject especially consequential.
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.
An agent needs an explicit project-specific eligibility rule rather than assumed age or activity thresholds.
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.
Meeting apparent conditions and observing effective permissions are different evidence claims that an agent must reconcile.
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.
The practical value of the classification is its effect on permitted actions, while the classification alone cannot establish every authorization.
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.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
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.
- The source wiki and intended referent are unspecified; first check whether this registry entry represents a Wikimedia project page or the account status it describes.
- No particular eligibility threshold or permission set is asserted because these depend on local configuration.
- This is a platform access status, not an occupation, professional qualification, or licence.
- 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.
- MediaWiki user-group identifier - autoconfirmed - An automatically determined group membership rather than a personal identifier.
- MediaWiki page title - Project:Autoconfirmed users - The supplied label has the form of a project-namespace page title; it may identify a page explaining the status rather than the status itself.
- 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.
- Automatically granting additional editing permissions to accounts that meet a wiki's eligibility conditions.
- Controlling access to actions such as editing semiprotected pages where local configuration permits it.
- Reducing manual administration of routine account permission changes.
- 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.
- Account age - Eligibility threshold varies by wiki. - time
- Account edit count - Eligibility threshold varies by wiki. - edits
- 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.
- Treating automatic eligibility as proof of identity, expertise, or trustworthiness.
- Assuming that eligibility thresholds or permissions are identical across wikis.
- Accounts accumulating qualifying edits without demonstrating constructive participation.
- Confusing a documentation page with the user group it describes.
- 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.
- Variation is primarily between wiki projects and their local configurations rather than between geographic jurisdictions.
- 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.
- Registered users - Registration establishes an account; autoconfirmed status additionally requires satisfaction of automatic eligibility conditions.
- Confirmed users - On projects distinguishing these groups, confirmed status is assigned explicitly, whereas autoconfirmed status is determined automatically.
- Administrators - Administrators hold separately assigned administrative permissions; autoconfirmed status does not establish administrator authority.
- Project documentation page - A documentation page explains a status or policy; the status is an account classification with associated permissions.
- 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
What the second pass must settle
- 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?