Skip to content
Aftergraph Knowledge Plane

Community

Aftergraph’s public community surface is designed for work that is not yet canonical implementation truth: research reproduction, contradictory prior art, architecture critique, questions, early proposals, roadmap input and RFC formation.

Discussion is not authority. Specifications, benchmark results, release claims and governance decisions remain owned by their canonical repository and exact source version.

Start here

Section titled “Start here”
  • Organization Discussions — the public deliberation surface.
  • Public roadmap — gate-driven public priorities rather than ceremonial dates.
  • RFC process — how cross-repository or normative proposals become bounded implementation work.
  • Contributing — contribution and evidence expectations.
  • Security — security reports do not belong in public Discussions.

The routing rule

Section titled “The routing rule”
Discussion
  -> evidence / prior art
  -> owner + scope decision
  -> Issue or RFC in owning repository
  -> implementation
  -> tests / conformance / migration evidence
  -> versioned decision or release

Use a Discussion while the problem, evidence, owner or design is still uncertain. Use an Issue when the work is concrete, bounded and clearly owned. Use a pull request for the actual repository change with verification evidence.

Research and reproduction

Section titled “Research and reproduction”

Aftergraph explicitly welcomes evidence that falsifies or narrows its claims.

MISSION-Bench Reproduction Registry

Section titled “MISSION-Bench Reproduction Registry”

Report exact source version, workload and failure mode, runtime/model/provider where relevant, environment, sample size, exclusions, method, metrics, raw artifacts, deviations and limitations. A negative reproduction is a useful result.

SPEC-001 Mission Contract: Request for Implementations

Section titled “SPEC-001 Mission Contract: Request for Implementations”

Independent implementations and semantic deviations matter more than another in-tree adapter. Contributions should make it possible to distinguish implementation agreement from genuinely independent reproduction.

Prior Art Challenge

Section titled “Prior Art Challenge”

Bring papers, standards, patents, source code, release history or observable product behavior that materially overlaps an Aftergraph mechanism or claim. Preferred outcome: narrow the novelty boundary before the terminology becomes attached to anyone’s ego.

Architecture and RFCs

Section titled “Architecture and RFCs”

Aftergraph Architecture RFC

Section titled “Aftergraph Architecture RFC”

Challenge repository ownership, control-plane boundaries, AIE/runtime separation, compatibility and the cost of the abstraction.

RFC Intake

Section titled “RFC Intake”

Start an [RFC] Ideas discussion when a proposal changes public contracts, compatibility, cross-repository behavior, normative semantics, governance or a long-lived primitive.

A serious RFC should expose:

  1. problem and scope;
  2. evidence;
  3. prior art and simpler alternatives;
  4. proposed semantics;
  5. compatibility and migration;
  6. authority/security impact;
  7. token, latency, compute and human-attention cost where material;
  8. verification or conformance plan;
  9. falsifiers.

Roadmap

Section titled “Roadmap”

Aftergraph Public Roadmap: Evidence Before Dates

Section titled “Aftergraph Public Roadmap: Evidence Before Dates”

Current public priorities are coordinated through evidence and gates. A repository’s own release state remains authoritative. Roadmap wording must not silently upgrade a research result, prototype or internal validation into adoption or production readiness.

Product critique

Section titled “Product critique”

Sentinel: What Must a SHIP Verdict Prove?

Section titled “Sentinel: What Must a SHIP Verdict Prove?”

The open question is what evidence a code-review system must observe before a verdict can be bound to an exact code state. Counterexamples and cases where exact-HEAD verification is insufficient are particularly useful.

Active GitHub categories

Section titled “Active GitHub categories”

The organization currently routes work through GitHub’s active categories such as General, Ideas, Q&A, Show and tell and Announcements. Additional structured forms exist in Aftergraph/.github for research reproduction, specifications/RFCs, prior art and integrations, but a form becomes active only when its matching Discussion category exists.

The absence of extra category chrome is not a reason to block a useful reproduction or critique. Use the closest active category and state the contribution type in the title.

Evidence discipline

Section titled “Evidence discipline”

Keep these classes distinct:

  • deterministic/in-tree tests;
  • controlled simulations;
  • live model or provider runs;
  • cross-runtime conformance;
  • independent implementation;
  • independent external reproduction;
  • observed adoption.

None automatically implies another. The Knowledge Plane renders and routes source-owned information; it does not own or upgrade the underlying claim.

Was this page helpful?