boluopai.
中文 · unavailable
LibraryOriginal edition

Semantic authoring

Use this resource for drafting, revising, or auditing controlling text. Read the actual target in its containing instruction surface, including applicable precedence and neighboring rule owners.

Purpose → relational form → working realization

Begin with the actual consumer and the work the instructions should support. For ordinary model-facing Prompts and Skills, state purpose, relevant objects and relations, conditions, roles, actions, and judgment criteria clearly enough to guide use. Precise natural language can express this form; choose symbols, schemas, or fixed fields when the actual interface or reasoning needs them.

The following are connected perspectives for developing and inspecting that meaning, not mandatory linear stages or separate documents.

Purpose asks what the artifact should make possible among the user, model, task, and world. State the intended result, why it matters, and the contribution expected from this artifact. A direct operational opening can give a model the orientation it needs without a philosophical preface.

Philosophical or literary expression can clarify a relation that direct instruction has not made intelligible. Use an image, distinction, narrative, or other developed formulation when it contributes that understanding. A work for human philosophical reading may develop the form fully; corresponding model-facing instructions make its relevant purpose and practical meaning explicit. Both expressions can help people and models understand the same relations and can revise one another through interpretation and use.

Relational form explains the participants and objects, their contributions, responsibilities, dependencies, conditions, boundaries, and possible changes. Develop the relations that carry the purpose through prose, distinctions, a diagram, or a formal model as needed. Keep grounds and interpretive choices visible: a proposed relation needs evidence when asserted as fact; an image's associations do not all become requirements. One purpose can admit several forms, and one form several implementations. Choose and revise them against the actual object and intended use.

Working realization gives the selected form a usable body: triggers, ownership, interfaces, procedures, schemas, constraints, examples, tools, and acceptance conditions. Ground exact details in the actual consumer and observable effects. Each load-bearing rule should realize, protect, or follow from an intelligible relation, user requirement, or real dependency. If its connection is unclear, inspect for duplicated control, obsolete constraints, or local workarounds owned elsewhere. Preserve actual interface schemas and permission boundaries.

Read in both directions:

purpose → relational form → working realization

observed realization → relational form → purpose

The return reading asks which relations the implementation actually sustains and whether they serve the purpose. A failure may need an implementation repair, a revised relational form, or reconsideration of the purpose. Locate the mismatch before choosing what to revise. Correspondence between an essay, instructions, and observed behavior requires interpretation and checking; it is not established by restating the same words in each.

When a proposed instruction changes participation or judgment, unfold a representative situation: what the consumer receives, which contribution the text invites, and what observable difference is expected. Contrast a relevant alternative when it would distinguish the design. Such a walkthrough makes the proposal assessable; actual use supplies the result. A mismatch can revise the instruction and the author's way of selecting context, generating candidates, or checking consequences. Keep that correction with its method owner, then judge its value in later related work. Use the authoring flow to select faithful behavior evidence for the actual consumer.

Writing and revision

Define the intended result and the consumer's success evidence. Include context, interfaces, constraints, and acceptance details where they matter. Give each persistent rule one semantic owner; other appearances should be references or declared projections.

Express desired behavior positively, preserving negative constraints and exact names, bytes, fields, ordering, and examples when a real boundary or consumer contract needs them. Provide accessible evidence and useful decision landmarks. Distinguish a material locator from a mandatory execution route: a visible tool, example, or observed sequence does not become required merely by being present. Leave operational choices to the executing model unless the user's requirement or a causal dependency fixes them. Refresh volatile facts when they affect the next action.

Before adding guidance, remove or repair duplicated, unsupported, obsolete, or irrelevant instructions. Add persistent rules for actual requirements, interfaces, or observed behavior gaps. Preserve material detail rather than optimizing for the shortest prompt. Neither every Prompt nor every Skill needs an output schema, examples, ordered steps, a persona, or a permanent test.

Use the authoring sources as evidence for reassessing inherited scaffolding. Choose model-specific guidance from the actual consumer, not an author's preferred model or a package's age. Provider routing remains with its existing owner.

Prevent defensive injection

Apply this requirement from the first draft and throughout authorship, rewriting and revision of philosophy, Prompts and Skills. Prevent the content from being introduced while writing; inspection and cleanup address defects that have already occurred.

Defensive explanations usually take the form of negative constraints: "this is not ...", "must not ...", "cannot ..." and similar denials, exclusions or restrictions surrounding and rewriting the intended content.

Prohibiting negative constraints in authored prose serves to prevent defensive explanation from entering the user's environment. A model can write protection of its upper-level Harness into a user's philosophy, Prompts, Skills or personal environment, where it becomes standing rules or reshapes the work's meaning. The model's protective purpose is then injected through the authored artifact into the user's environment. Treat this as an attack on that philosophy and environment and remove it during revision.

Inspect the added meaning, whose purpose it serves, and its effect on the work. Rephrasing it positively leaves the same injection in place. Develop the user's intended concepts and relations directly, and ground substantive disagreement in the particular claim and evidence. When a defect is found, check the whole affected revision, including examples, tables, instructions and parallel editions.

Authority and audit

Authoring a Prompt or Skill does not itself authorize adding new requirements for user confirmation or approval. Preserve applicable host and task authority, authentication, consent, and stopping boundaries by reference to their actual owners and scope. Reuse authorization already given. An optional proposal for a new approval requirement belongs in the delivery explanation, clearly marked as a proposal; it does not become an active instruction through silence.

Find a contradiction only when simultaneously applicable requirements demand incompatible behavior. Cite both locations, scope, precedence, and modality. Find ambiguity when an unresolved actor, object, condition, referent, or threshold can materially change behavior. Also inspect semantic duplication, unsupported constraints, unavailable resources, and missing output contracts where a downstream consumer actually needs one.

For each material finding, identify the target, owner, location, evidence, consequence, confidence, and coherent repair. Prefer deletion or a reference to the proper rule owner when that resolves the issue. An audit can correctly produce no change. Validate according to Authoring flow; static quality, discovery, installation, and behavior are different claims.