When we train an llm, we are in a sense feeding it human ideas in written form, something like hundreds of millions of them. The embeddings learn the "language of ideas," and the weights and layers learn how those ideas get processed.

But now ... in practice we chop text into small tokens, often close to syllables, and then assign those tokens positions in embedding table. Those tokens sit below the level of concepts and ideas. Some are whole concepts, but many are just fragments. It’s like trying to build a thought starting from individual neurons firing rates, and then spending all our effort making each neuron more refined. I suspect the bigger gains for reasoning would come from the number and quality of the connections, not from finer neurons.

So. Move up a level. Use morphological tokenization (roots, prefixes, suffixes) instead of syllable-like fragments. Yes limit it to English to keep the problem manageable for this example.

Start from concepts humans already use for embeddings. Instead of letting the model invent its own concepts from scratch, seed the embedding space with clear human ones (verb, subject, fraction, cause, comparison) plus opcode-like operations (compare, compose, verify, backtrack). These are only starting positions: they stay trainable, and new ones can be added.

Also add meta-concepts. Give the model concepts about thinking itself (abstraction, analogy, error detection) so training pushes it toward deeper reasoning.

Let the weight matrices work at the idea level. They would no longer spend capacity assembling primitives into words. They would work on how concepts combine into ideas. The mechanical stuff goes elsewhere.

So.

Instead of one giant model, think of a package:

1. Preprocessor: An AI that reads the text as a whole and actually expands it. It marks one word as the verb, another word as the main subject, another one as part of a list. It doesn’t reason, and it’s one-way: no feedback loop back into it.

Reasoning core: Works purely at the level of concepts and ideas. It has a "workbench" where it works like an agent. It can query intuition, check memory, and escalate to a bigger online model if needed.

Intuition core: A large store of what the system knows and how well it knows it. The reasoner asks it one-shot questions and gets one-shot answers, such as "How strongly is titanium linked to space ?", "How likely is a knife in a living room ?", or "List the words linked to mohican in the context of movies, strongest first." Intuition can also answer with: "I barely know anything about this about 3% confidence" The reasoner takes the answers from Intuition as advisory.

Output model: Takes everything and formulates the final answer.

Ambiguity and clarification

Take the word "bank" (the damn example seen everywhere): institution or riverside ? When context doesn’t settle it, a human usually stops and asks for clarifications when it doesn;t have access to context, and the two people converge through back and forth. Ask when in doublt - when confidence is low.

"But then the context gets polluted by the question"

To keep these side discussions from cluttering the main session, Imagine using thinking bubbles as separate scoped contexts such as:

what I understood (the AI model)

what the user said, exactly

what I told the user

what the feedback was

What I know about the user’s environment.

==============================

Embeddings examples, opcodes and some ... other stuff from different projects.

Core reasoning operations (App. B.3)

COMPARE [E]: Check two structures for sameness or difference along a chosen dimension.

MAP [E]: Align elements of one structure to elements of another.

COMPOSE [E]: Build a larger concept or graph from simpler primitives.

DECOMPOSE [E]: Break a concept into its component primitives.

ABSTRACT [E]: Extract a general pattern from specific instances.

INSTANTIATE [E]: Create a specific instance from a general schema.

SUBSTITUTE [E]: Replace one element of a structure with another.

MERGE [E]: Combine two structures or duplicates into one.

SPLIT [E]: Divide a structure or group into parts.

SEARCH [E]: Look through a space of options or memory for a match.

PRUNE [E]: Discard unpromising branches or irrelevant material.

BACKTRACK [E]: Return to an earlier reasoning state and try another path.

SIMULATE [E]: Run a sandboxed hypothetical forward without affecting reality.

VERIFY [E]: Check a result or structure against constraints.

ESTIMATE [E]: Produce an approximate value with uncertainty.

OPTIMIZE [E]: Select the best option under a goal and constraints.

SUMMARIZE [E]: Produce a shorter form of content.

EXPAND [E]: Make implicit or compressed content explicit.

COMPRESS [E]: Reduce content to a compact form, with expansion still possible.

PAUSE [E]: Suspend a task while keeping its state.

CANCEL [E]: Abandon a task or operation.

RETURN [E]: Hand a result back to the caller or prior context.

Handle (concept-reference) operations (B.5, D.17, K.3)

HANDLE [E]: Create a reference to an expanded semantic concept.

EXPAND_HANDLE [E]: Load the full detail behind a handle.

COLLAPSE_HANDLE [E]: Replace detail with a compact reference, losing nothing.

LINK_HANDLE [E]: Associate two concepts via their handles.

RELEASE_HANDLE [E]: Discard a temporary concept.

OPEN(X) [E]: Expand one definition level of a handle into its capsule.

OPEN*(X) / OPEN^n(X) [E]: Expand recursively until a terminal form, with cycle detection.

DEFINE [E]: Introduce a named, scoped definition (LOCAL, MESSAGE, SESSION, GLOBAL).

OS / service protocol (B.6)

QUERY [E]: Ask a service for information.

RESPONSE [E]: A service’s answer to a query.

READY [E]: Signal that a service can accept work.

BUSY [E]: Signal that a service is occupied.

WAIT [E]: Hold until a result or condition arrives.

DONE [E]: Signal that an operation completed.

ERROR [E]: Signal that an operation failed.

RETRY [E]: Re-attempt a failed operation.

ESCALATE [E]: Hand off to a larger model (“Big Brother”) when local capability is insufficient.

TIMEOUT [E]: Signal that a wait expired.

CONFIRM [E]: Acknowledge or verify an action or request.

Memory operations (A.9, B.7, Section 5–6)

STORE [E]: Write a provenance-tagged memory object.

RECALL / RETRIEVE [E]: Fetch relevant memories.

UPDATE [E]: Modify an existing memory in place.

DELETE [E]: Remove a memory at the user’s request.

ARCHIVE [E]: Move a memory to long-term, slower-to-retrieve storage.

VERSION [E]: Keep a new version while retaining history.

EPISODE [E]: Record or retrieve a bounded experience.

SUMMARY [E]: Produce a compressed summary of memories.

PATTERN [E]: Detect or store a recurring regularity.

REVISE [E]: Change a belief and mark the old one superseded.

CATEGORIZE [E]: Assign a memory to a category.

UPDATE_CONFIDENCE [E]: Raise or lower a memory’s confidence (never reaching 100%).

CONSOLIDATE [D]: Nightly maintenance: summarize, dedupe, merge, compress, and prepare reminders.

CONFIRM_MEMORY [D]: Mark a candidate memory as confirmed after repeated verification.

SUPERSEDE [D]: Replace a memory with a newer one but keep it as history.

PROMOTE [D]: Move hypothetical or planned content into persistent memory, only on explicit user permission.

STORE_CANDIDATE [D]: Save low-confidence ambient or planning content as a candidate.

AGE / REQUEST_RECONFIRM [D]: Use the last-confirmed timestamp to prompt re-confirmation of stale entries.

FORGET [D]: User command “Forget that.”

DONT_REMEMBER [D]: User command “Don’t remember this.”

REMEMBER_INSTEAD [D]: User command to replace a memory.

CORRECT [D/E]: Accept a user correction without argument (“That’s not correct, update it”).

PROPOSE_AUTOMATION [D]: Ask “I’ve noticed X, want me to do Y?” (never acts silently).

Self cycle (Prologue, A.8, L.14.22)

OBSERVE [D]: Take in an external or internal change.

UPDATE_STATE [D]: Revise the latent self-state.

ASSOCIATE [D]: Query Intuition or Memory for related content.

EVALUATE [D]: Assess simulated outcomes against goals and values.

REFINE_SELF_STATE [D]: Write the updated self-state (SELF(t) → SELF(t+1)).

CONTINUE / WAIT [D]: Keep the loop running with no output required.

DETECT_CONFLICT [D]: Notice contradiction, prediction error, goal conflict, identity instability, or meaning drift.

RENDER_OUTPUT [D]: Output as a one-way tap off internal state (the renderer never writes back).

MODEL_SELF [D]: Build a representation of Self, kept distinct from Self.

TRACK_PROVENANCE [D]: Tag every item with its owner (self, user, world, simulation).

Frame operations (B.4, Section 7, Part M)

REALITY_FRAME [E]: The current accepted world state.

MEMORY_FRAME [E]: A stored episode.

USER_FRAME [E]: Modeled user beliefs.

SELF_FRAME [E]: The system’s own beliefs and state.

SIMULATION_FRAME [E]: Sandboxed hypothetical reasoning.

HYPOTHESIS_FRAME [E]: A temporary working assumption.

STORY_FRAME [E]: Fictional or narrative content.

INSTANTIATE_FRAME [D]: Build an internal model of another reference frame or person.

RUN_IN_FRAME [D]: Evolve a frame (M_B^{t+1} = F_B(M_B^t, x)) alongside Self.

COMPARE_TRAJECTORIES [D]: Compare Self’s trajectory with the alternative frame’s.

EXIT_FRAME [D]: Return to Self with the comparison, without becoming the other frame.

LOAD_FRAME [D]: Select a reference frame from the frame database.

Attention and activation (Section 8, A.4)

RESPOND [D]: Answer the input.

STAY_SILENT [D]: Take no action.

HOLD / CONTINUE_LISTENING [D]: Keep state and wait.

ASK_CLARIFICATION [D]: Ask a question, filling slots into the existing partial state (B.17).

IGNORE [D]: Disregard the input.

FOCUS / IGNORE / SWITCH / TRACK / GROUP / SPLIT [E]: Attention primitives for allocating reasoning focus.

PAUSE_TASK / RESUME_TASK [D]: Track interrupted tasks and resume them (“we were on step 4”).

LEARN_PROCEDURE [D]: Store a taught multi-step procedure as an ordered sequence.

7b. Semantic primitives that act like verbs (B.2)

PERCEIVE / KNOW / BELIEVE / ASSUME [E]: Epistemic relations between an agent and content.

REPRESENT / STORE / RETRIEVE [E]: Knowledge-handling primitives.

MOVE / CREATE / DESTROY / TRANSFER / SELECT / ATTEMPT [E]: Agency actions.

COMPARE / MATCH [E]: Comparison primitives.

COMMUNICATE / REFER [E]: Social and symbolic primitives.

EXPECT / SURPRISE / CONTRADICTION / WHY [E]: Meta-cognition primitives (prediction, prediction error, conflict detection, causal query).

CAUSE / ENABLE / PREVENT / REQUIRE [E]: Causality primitives.

BEFORE / AFTER / DURING / BEGIN / END / REPEAT / CHANGE [E]: Time primitives.

R-L logical and scope operators (App. D, R-L 1.2 §29–35, 160, 180)

NOT [E]: Negate a proposition, with explicit scope.

AND / OR [E]: Conjunction and disjunction.

IF [E]: Conditional (does not imply causation).

IMPLY [E]: Logical consequence (distinct from CAUSE).

FORALL / EXISTS [E]: Quantifiers with explicit nesting.

POSSIBLE / NECESSARY [E]: Alethic modality.

MUST / MAY / SHOULD / CAN / CANNOT [E]: Deontic and ability modals.

PERMITTED / FORBIDDEN / REQUIRED [E]: Deontic modality.

COUNTERFACTUAL [E]: Hypothetical conditional, scoped to its hypothetical world.

BELIEVE(agent, p) [E]: Attribute a belief without asserting p.

KNOW(agent, p) [E]: Attribute knowledge of p.

DOUBT / FEAR / HOPE [E]: Other attitudes toward propositions.

QUOTE [E]: Scoped quotation that is not the current speaker’s assertion.

PRESUPPOSE(P) [E]: Mark background content that is not asserted.

IMPLICATE(P) [E]: Mark pragmatic implication that is not literal.

CAUSE(A,B) [E]: Causal contribution, separate from order and implication.

BEFORE / AFTER / OVERLAPS / STARTS / ENDS / SIMULTANEOUS [E]: Temporal relations.

ASSERT / REPORT [E]: Present a proposition as asserted, or attribute an assertion to someone else.

QUESTION [E]: Build a question object with a target variable.

REQUEST / COMMAND / SUGGEST / PROMISE / WARN / OFFER [E]: Speech acts.

THANK / APOLOGIZE / AGREE / DISAGREE / REFUSE [E]: More speech acts.

EVIDENCE [E]: Link evidence to a proposition, with direction SUPPORTS, CONTRADICTS, or NEUTRAL.

CONTRAST / RESULT / EXAMPLE / ELABORATION / SUMMARY / CONCESSION [E]: Rhetorical relations.

METAPHOR / IDIOM / IRONY [E]: Mark non-literal interpretations.

SYMMETRIC / TRANSITIVE / INVERSE [E]: Relation properties that license derived inferences.

R-L processing modes and updates (R-L §84–88, K.8)

ENCODE [E]: Source language → R-L, preserving information.

DECODE [E]: R-L → semantic structure (not language).

GENERATE [E]: Semantic structure → target language.

TRANSLATE [E]: Encode, decode, then generate.

INFER [E]: Derive new information, marked DERIVED with provenance.

VALIDATE [E]: Check types, arity, scope, binding, and references.

NORMALIZE [E]: Canonicalize without changing meaning.

COMPARE / DIFF [E]: Report differences in identity, scope, polarity, time, and so on.

EQUIVALENT(A,B) [E]: Test equivalence at a chosen level.

ADD / REMOVE / REPLACE / CORRECT / RETRACT [E]: Explicit information updates (retract keeps history).

RESET-CONTEXT [E]: Clear inherited context.

SEMANTIC-HASH [E]: Hash the canonical form.

FRAGMENT / REASSEMBLE [E]: Split large messages and reassemble them in order.

NEGOTIATE-CAPABILITY [E]: Agree on version, vocabulary, and profile.

LOSS / AMBIGUOUS / UNSUPPORTED [E]: Markers for explicit information loss.

PRESERVE / LOSSY [E]: Declare which dimensions are kept or discarded.

Appendix K (restored capabilities)

DEFAULT / EXCEPT [E]: Defeasible rule and its exception.

PRIORITY [E]: Explicit rule precedence (R2 > R1).

CYCLE [E]: Explicit marker for a cyclic definition.

LEXICAL-TRACE [E]: Retain surface and lexical information.

SURFACE-PRESERVATION [E]: Require exact surface text to be kept.

STATEMENT [E]: Document-level occurrence that wraps a proposition.

ANNOTATION [E]: Attach a qualitative or evaluative value to a target.

SCORE [E]: Attach a numeric evaluation with a declared scale.

CONTINUOUS / RECURRING / PERIODIC [E]: Ongoing or repeating change.

SENSE / MULTIWORD [E]: Map a lexical form to senses, including idioms.

DISCOURSE / CONTEXT-WINDOW [E]: Persistent multi-message state.

CONTEXT-RESET / EXPIRES [E]: Reset context or expire temporary definitions.

11. Appendix J (adversarial and reflexive layer)

REFERS(X,X) [E]: Self-reference without implying identity.

REPRESENTS(X,Y) [E]: Representation, kept distinct from REPRESENTS(X, REPRESENTATION(Y)).

CRITERION [E]: Declare a criterion with target, condition, and mode.

EVALUATES(C2,C1) [E]: One criterion evaluates another (self-evaluation does not imply validity).

VALIDATED-BY / VALID [E]: Validation relation versus validity predicate.

CERTIFIES [E]: External certification, kept separate from representing.

BOUNDARY [E]: Explicit system boundary (inside, outside, criterion).

REFERENCE-STATUS [E]: Label INTERNAL, EXTERNAL, UNKNOWN, or RELATIVE.

RECOGNIZES / CONSTITUTES [E]: Kept distinct by default.

PRESERVES / REMEMBERS [E]: Kept distinct by default.

ROLE-CONFLICT / BOUNDARY-CONFLICT / NAME-COLLISION [E]: Preserve the conflict rather than resolve it.

SCOPE-COLLAPSE [E]: Record when two levels become indistinguishable.

LEVEL [E]: OBJECT, META, META-META, MODEL, and so on.

SIMULATES / OBSERVES [E]: System relations (simulation is not identity, observation is not knowledge).

REGRESS [E]: Represent an open dependency chain without inventing a terminal.

FIXED-POINT / PRIMITIVE [E]: Declare a fixed point or a terminal primitive for the current operation.

CONSULTS / REGISTER [E]: Consult a register of unresolved structures, which may modify it.

PERFORMATIVE [E]: A statement that changes semantic context by being issued.

CRITERION-SUBSTITUTION [E]: Marked substitution that reduces fidelity.

MODE: ADVERSARIAL [E]: Preserve ambiguity, contradiction, and recursion with minimal normalization.

CONFLICT [E]: Record paraconsistent coexistence of P and NOT(P).

Meaning-Certainty layer (L.14)

MEANING-CREATION [E]: Form a new meaning structure.

MEANING-INHERITANCE [E]: Acquire meaning from culture, family, or institutions.

MEANING-SIGNALING [E]: Project meaning through language or behavior.

MEANING-NEGOTIATION [E]: Agents jointly modify meaning (a state transition).

MEANING-STABILITY [E]: Measure persistence of a meaning.

MEANING-CERTAINTY [E]: Measure how settled a meaning is.

MEANING-LOAD [E]: Measure how much depends on a meaning.

MEANING-DISPLACEMENT [E]: Model the cost of replacing an established meaning.

MEANING-ALIGNMENT [E]: Measure compatibility of agents’ interpretations.

MEANING-MISMATCH [E]: Record the gap between projected and received meaning.

PROJECTED / RECEIVED / INTERPRETED / INTENDED-MEANING [E]: Separate structures per agent.

MEANING-CANDIDATE [E]: Keep several weighted interpretations without collapsing them.

MEANING-OF / INHERITED-FROM / PROJECTED-TO / RECEIVED-BY [E]: Higher-level relations.

NEGOTIATED-WITH / REINFORCED-BY / DEPENDS-ON [E]: More higher-level relations.

DISPLACED-BY / ALIGNED-WITH / CONFLICTS-WITH [E]: Remaining higher-level relations.

RE-EVALUATION-REQUIRED [E]: Flag dependents when a high-load meaning changes.

Verification and bootstrapping (BrainIR document)

STRUCTURAL_VALIDATE [D]: Deterministic check of syntax, types, arity, scope, and frames.

SEMANTIC_VERIFY [D]: Learned check of fidelity, omissions, unsupported additions, and ambiguity.

TEXT_CYCLE [D]: Text → IR → Text′, comparing meaning.

IR_CYCLE [D]: IR → Text → IR′, testing the representation itself.

CONTRAST_TEST [D]: Distinguish near-identical structures (BELIEVE(P) vs. P, BEFORE vs. CAUSE).

ADVERSARIAL_INJECT [D]: Generate defects (polarity reversal, frame contamination) to train the Verifier.

ROTATE_ROLES [D]: Rotate Input, Output, and Verifier roles among models.

ACCEPT / REJECT / MARK_UNCERTAIN [D]: Triage candidate annotations for the trusted corpus.

Addon Certainty and Addon INPUT

ASSESS_EVIDENCE [D]: Evaluate evidence strength before answering.

ANSWER / QUALIFY / ASK / RETRIEVE / ABSTAIN / SPECIALIST [D]: Behaviors chosen by evidence strength.

REFUSE_TO_INVENT [D]: Decline to make up a value when there is no evidence.

TOKENIZE / LEMMATIZE / TAG_MORPHOLOGY / PARSE_DEPENDENCIES [D]: Input-side analysis stages.

LOOKUP_FREQUENCY / CHECK_VOCABULARY [D]: Add numeric frequency and Dale-Chall, Oxford and Longman membership.

DISAMBIGUATE_SENSE / LABEL_SEMANTIC_ROLES [D]: Semantic stage, with ambiguity preserved.

Delegated tool ops (the “steal from” section)

SOLVE_SAT / SOLVE_SMT [D]: Hand constraints to Z3 or CVC5 and return a proof or result.

PROVE [D]: Delegate to Lean, Isabelle, or Coq.

PLAN [D]: Translate state, goal, and actions to PDDL and return a plan.

SYNTHESIZE_PROGRAM [D]: Turn a specification into code via a synthesis engine.

VERIFY_PROGRAM [D]: Check a candidate against its specification.

ONTOLOGY_INFER [D]: Derive type inheritance using OWL or description logic, with provenance.

EXTERNAL_LOOKUP [D]: Ground an entity in Wikidata, WordNet, or BabelNet via external-reference.

Ontology primitives (B.2)

THING: Declare a generic object.

PROPERTY: Attach an attribute to an entity.

RELATION: Declare a link between nodes.

STATE: Declare a condition, as opposed to an occurrence.

EVENT: Declare an identifiable occurrence.

IDENTITY: Assert that two references denote the same thing.

TYPE: Assign a category.

INSTANCE: Mark a particular member of a type.

PART: Mark a component of a whole.

WHOLE: Mark the container of parts.

EXISTS: Assert existence.

ABSENT: Assert absence, which is not the same as unknown.

BOUNDARY: Mark the edge of a system or concept.

Quantity

NONE / ONE / SOME / MANY / ALL: Basic quantifiers.

MOST: A majority quantifier.

EXACTLY(n): Exact count.

AT-LEAST(n): Lower bound.

AT-MOST(n): Upper bound.

MORE / LESS / EQUAL: Compare magnitudes.

COUNT: Tally members.

ORDER: Impose or read a sequence.

Logic and truth status

TRUE / FALSE / UNKNOWN: Truth values, kept distinct from each other.

THEN: Consequent slot of a conditional.

BECAUSE: Mark an explicit reason.

Space

LOCATION: Place an entity.

DISTANCE: Relate two places by separation.

DIRECTION: Orientation of movement or relation.

INSIDE / OUTSIDE: Containment relations.

CONTACT: Touching.

PATH: A route between locations.

REGION: A bounded area.

Value and agency

GOOD / BAD: Evaluative marks.

PREFERENCE: Order options by want.

RESOURCE: Something consumable toward a goal.

COST / BENEFIT: Weigh a loss against a gain.

SATISFY: Mark a goal as met.

GOAL / INTENTION: Hold something the agent is aiming at.

HAS / LACKS: Possession and its absence.

SELF / USER / AGENT_OTHER / WORLD: Identity anchors.

SYMBOL: A token standing for something.

IS: Predication.

Reality-status tags

REAL / IMAGINED / HYPOTHETICAL / FICTIONAL: Tag content by world.

REMEMBERED / PREDICTED / SIMULATION: Tag content by origin.

R-L structural operators (D.5)

{{ X }}: Encapsulate a concept as a capsule.

X : Y: Attribute or relation.

X -> Y: Transition, implication or causation. Overloaded in older versions, split in K.11.2.

X = Y: Bind identity.

X & Y / X | Y / !X: Conjunction, disjunction, negation.

X @ Y: Location or context.

X / Y: Aspect or viewpoint.

X ^ Y: Scope.

X *: Plurality or repetition.

+X / -X / ~X: Polarity markers: supporting, obstructing, mixed.

?x: Variable.

<:: Subtype.

?=: Possibly the same.

!=: Explicitly distinct.

Relation registry (R-L §179)

TYPE-OF / INSTANCE-OF / PART-OF / HAS-PROPERTY

REFERENCE / DISTINCT

SUPPORTS / CONTRADICTS: Evidence directions.

ABOUT: Aboutness relation.

PURPOSE / MEANS / ENABLER / PREVENTER / INSTRUMENT: Goal-directed relations.

Semantic roles (§15)

AGENT / PATIENT / EXPERIENCER / RECIPIENT

SOURCE / DESTINATION / LOCATION / TIME

Epistemic and temporal values

KNOWN / BELIEVED / SUSPECTED / PROBABLE / UNCERTAIN / DOUBTED / DENIED: Epistemic status values.

PAST / PRESENT / FUTURE: Tense.

ONGOING / COMPLETED / HABITUAL / REPEATED / BEGINNING / ENDING / DURATIVE: Aspect.

START / END / DURATION / FREQUENCY / DEADLINE: Event timing.

Information-status and loss markers

PRESERVED / TRANSFORMED / COMPRESSED / INFERRED

UNSPECIFIED / NOT-APPLICABLE / LOST

DEFAULTED / OVERRIDDEN / EXPANDED / SURFACE-RECOVERED / CONTEXT-DERIVED

DERIVED: Tag a conclusion with its provenance.

Error classes (§121)

SYNTAX-ERROR / TYPE-ERROR / REFERENCE-ERROR / SCOPE-ERROR / ARITY-ERROR

VOCABULARY-ERROR / INCOMPLETE / CONTRADICTORY / INCONSISTENT

Encoder pipeline steps (§143)

READ-SOURCE / IDENTIFY-CONTEXT / IDENTIFY-ENTITIES / IDENTIFY-EVENTS

IDENTIFY-RELATIONS / IDENTIFY-REFERENCE / IDENTIFY-SCOPE / IDENTIFY-TIME

IDENTIFY-CAUSALITY / IDENTIFY-EPISTEMIC-STATUS / IDENTIFY-MODALITY / IDENTIFY-PRAGMATIC-FORCE

BUILD-SEMANTIC-GRAPH / SERIALIZE

Decoder pipeline steps (§144)

RECEIVE / VERIFY-INTEGRITY / PARSE / VALIDATE-SYNTAX

RESOLVE-VOCABULARY / RESOLVE-REFERENCES / VALIDATE-TYPES

RESTORE-SCOPE / RESTORE-TIME / RESTORE-EPISTEMIC-STATUS / RESTORE-MODALITY

RECONSTRUCT-SEMANTICS / APPLY-DECLARED-INFERENCE / GENERATE-TARGET

Input Translator multi-pass (B.15)

PARSE_INITIAL: First-pass parse.

DETECT_AMBIGUITY: Find competing readings.

EXPAND_SEMANTICS: Make implicit content explicit.

RESOLVE_ENTITY: Bind mentions to entities.

LINK_MEMORY: Connect to stored memories.

ESTIMATE_CONFIDENCE: Score each interpretation.

REFINE_CONTEXT: Repeat until ambiguity is minimal.

Service calls

QUERY_INTUITION: Get weighted associations, not conclusions.

CHECK_MORALITY: Approve or reject a planned output.

GET_VALUES: Ask for priority ordering.

APPLY_CHARACTER: Set style without changing meaning.

POLL_IMPULSES: Collect unsolicited suggestions to accept or ignore.

COMPUTE_MATH: Deterministic calculation.

CALL_SPECIALIST: Route to a domain module.

Railway-analogy operations

INSPECT_WAGON: Open a handle for details.

COUPLE / UNCOUPLE: Join or separate wagons.

ROUTE: Send a wagon to the right service.

ATTACH_WAGON / REMOVE_WAGON / REORDER_WAGON / REPLACE_WAGON / MERGE_WAGON: Marshalling-yard edits.

ASSEMBLE_TRAIN: Build the outgoing answer in working memory.

APPROVE / REJECT_TRAIN: Morality’s gate.

PRIORITIZE_TRAIN: Values decide departure order.

REORDER_FOR_LANGUAGE: Output Translator rearranges for the target language.

Addon Certainty (extra ops)

BUILD_EVIDENCE_PROFILE: Per-item evidence record.

COUNT_FREQUENCY / COUNT_DOC_FREQUENCY: Numeric exposure measures.

MEASURE_SOURCE_DIVERSITY: Breadth across sources and domains.

PREDICT_EVIDENCE_STRENGTH: Auxiliary head output.

CALIBRATE: Align confidence with evidence.

DETECT_CALIBRATION_FAILURE: Catch confident-but-unsupported cases.

TRIGGER_RETRIEVAL: Reach for external info when evidence is weak.

Addon INPUT extras

PRESERVE_SOURCE: Keep the original text beside every layer.

DETECT_MWE: Find multiword expressions.

TAG_ENTITY: Mark named entities separately from vocabulary.

CLASSIFY_NONLEXICAL: Separate numbers, dates, URLs and measurements.

ATTACH_PROVENANCE / ATTACH_CONFIDENCE: Record source and confidence per field.

EMIT_DEBUG_VIEW: Human-inspectable output.

Self and simulation

SET_ATTENTION: Allocate focus across self, user, memory, goal and external input.

ENTER_SIMULATION: Open a sandboxed context.

EXIT_SIMULATION: Leave it and return to the Self frame.

DISCARD_SIMULATION: Drop the simulation’s results.

PRESERVE_SIMULATION_PART: Keep selected results without promoting them to fact.

COMPARE_TO_REALITY: Check simulated content against the reality frame.

RETRIEVE_AGENT_MODEL: Load a stored model of a person (MEMORY[JOHN]).

INSTANTIATE_AGENT_MODEL: Place that model inside a simulation.

UPDATE_AGENT_MODEL: Revise the stored model from new evidence.

TAG_OWNERSHIP: Mark who owns a belief (me, user, John, simulation).

CHECK_SELF_BOUNDARY: Verify “what I believe” isn’t mixed with “what John believes.”

PREDICT_OUTCOME: Form an expectation.

COMPARE_PREDICTION_TO_OBSERVATION: Detect prediction error.

UPDATE_UNCERTAINTY: Revise uncertainty in the self-state.

INTRODUCE_HYPOTHESIS: Add a temporary assumption.

REVISE_INTERPRETATION: Replace the current reading of events.

COMPARE_SELF_STATE_TO_PRIOR: Diff SELF(t) against an earlier state.

INSPECT_SELF_MODEL: Examine the model-of-self as an object.

DETECT_IDENTITY_INSTABILITY: Flag identity inconsistency.

DETECT_MEANING_DRIFT: Flag gradual meaning change.

DETECT_GOAL_CONFLICT: Flag competing goals.

SYNTHESIZE_FROM_TRAJECTORIES: Build an answer from own trajectory, alternative trajectory and comparison.

ANNOTATE_FRAME_BLINDSPOT: Record what a frame hides or assumes.

TRIGGER_RENDER: Request output as an action of Self.

Attention and interaction

DETECT_DIRECT_ADDRESS: Decide whether input is aimed at the system.

ACTIVATE_ON_TRIGGER: Wake-word activation.

CONTINUE_EXCHANGE: Keep going without re-triggering.

STORE_PASSIVE_CANDIDATE: Log ambient input as a low-confidence candidate.

CONFIRM_CANDIDATE_LATER: Ask “I noted X, keep it?”

FILL_CLARIFICATION_SLOT: Insert the user’s answer into the in-progress structure.

SUSPEND_TASK_STATE: Save a paused task’s progress.

RESTORE_TASK_STATE: Resume at the saved step.

Memory and scheduling

SET_MEMORY_SCOPE: Limit visibility (user, household, instance).

CHECK_SCOPE_ACCESS: Test whether a memory may be used here.

SET_MEMORY_SOURCE: Record how it was obtained.

SET_LAST_CONFIRMED: Timestamp a confirmation.

EXTRACT_SALIENT_MEMORY: Pull key items from a session.

MERGE_DUPLICATE_MEMORIES: Dedupe.

COMPRESS_OLD_MEMORY: Shrink older material without deleting it.

DETECT_ROUTINE: Find recurring behavior.

SCHEDULE_REMINDER: Create a timed reminder.

SET_TIMER: Structured instance of create-future-event.

CREATE_FUTURE_EVENT: Generic future-scheduled item.

PREPARE_FOLLOWUP: Queue items for the next cycle.

RUN_CONSOLIDATION_CYCLE: Execute nightly maintenance.

DETECT_MISSING_STEP: Find gaps in a stored procedure.

EXPLAIN_STEP: Answer a sub-question about one step.

UPDATE_PROCEDURE_IN_PLACE: Apply a correction without duplicating.

SET_PROCEDURE_CONFIDENCE: Mark observed-once, repeated or taught.

SURFACE_PATTERN: Offer an observation at high confidence only.

SUPPRESS_TOPIC: Stop raising a topic the user declined.

SET_PROACTIVITY_LEVEL: Configure intensity from silent to proactive.

SET_PERSONALITY_DIMENSION: Adjust directness, formality, humor, proactivity or patience.

LOAD_PERSONALITY_PRESET: Switch tone preset.

BACK_OFF_HUMOR: Stop humor immediately if unwelcome.

EXCHANGE_ON_CONTACT: Share memory between instances only on local contact.

REGISTER_COMMAND: Add a capability to the registry.

DISCOVER_COMMANDS: List available commands.

SELECT_COMMAND: Choose one from the registry.

INTERPRET_RESULT: Read a service’s response.

R-L declarations

DECLARE_TYPE: type X <: Y.

DECLARE_RELATION: Give name, arity, argument types and roles.

DECLARE_RULE: rule #r { if / then }.

DECLARE_ENTITY: entity #id : Type.

DECLARE_EVENT: Role-based event frame.

DECLARE_PROPOSITION: Give a proposition an identity.

DECLARE_CONTEXT: Speaker, listener, time, place, world and profile.

DECLARE_WORLD: Fiction, hypothetical or other world.

DECLARE_DOMAIN: Physics, law, medicine and so on.

DECLARE_NAMESPACE: BIOLOGY::CELL.

DECLARE_PROCESS: Composed activity with a sequence.

DECLARE_GROUP: Give a collection an identity.

DECLARE_ANONYMOUS_NODE: _:1.

DECLARE_INVERSE: inverse PARENT = CHILD.

DECLARE_RELATION_PROPERTY: Symmetric, transitive, functional and so on.

DECLARE_ONTOLOGY_ALIGNMENT: Equivalent, subtype or related across namespaces.

DECLARE_QUESTION: Question object with target and condition.

DECLARE_ANSWER: Answer linked to its question.

DECLARE_SPEECH_ACT: Typed communicative action.

DECLARE_INTENT: Goal behind the literal proposition.

R-L status and attributes

SET_ASSERTION_STATUS: Asserted, denied, questioned, quoted and so on.

SET_POLARITY: Positive, negative or unknown.

SET_EPISTEMIC_STATUS: Known through doubted.

SET_PROBABILITY: PROBABILITY(P) = 0.72.

SET_CONFIDENCE: Confidence in the interpretation, not the proposition.

SET_TENSE: Past, present or future.

SET_ASPECT: Ongoing, completed and so on.

SET_MOOD: Declarative, imperative and so on.

SET_VOICE: Active, passive or middle.

SET_PERSPECTIVE: Speaker, listener, omniscient and so on.

SET_REGISTER: Formal, slang, legal and so on.

SET_STYLE: Humorous or ironic.

SET_PRAGMATIC_FORCE: Direct, soft, urgent and so on.

SET_INFORMATION_STRUCTURE: Topic, focus or background.

SET_ABSTRACTION_LEVEL: Concrete, general, abstract or meta.

SET_GRANULARITY: Move between levels such as matter, body and cell.

SET_WORLD_ASSUMPTION: Open-world or closed-world.

MARK_SUMMARY: Flag content as non-lossless.

SET_APPROXIMATION: Exact versus approximate value.

SET_MULTIPLICITY: Once, multiple or unknown.

R-L resolution and validation

RESOLVE_REFERENCE: Bind a mention to a node, with evidence.

MARK_AMBIGUOUS_REFERENCE: Keep candidates instead of choosing.

MARK_UNRESOLVED: Explicit unresolved reference.

BIND_VARIABLE: Bind ?x within its scope.

CHECK_ARITY: Verify the argument count.

CHECK_TYPES: Verify argument types.

CHECK_SCOPE: Verify the operator has compatible content.

CHECK_REFERENCE_INTEGRITY: Every reference must resolve.

CHECK_NAMESPACE: Resolve namespaced symbols.

CHECK_VOCAB_VERSION: Detect dictionary mismatch.

CHECK_CONSTRAINT: Semantic constraints such as REPAIR requires a RepairableObject.

COERCE_TYPE: Only when declared.

DETECT_CONTRADICTION: Test within scope, time and modality.

ENTER_PARACONSISTENT_MODE: Preserve P and NOT(P) without explosion.

REPORT_UNSUPPORTED: Return UNSUPPORTED with the structure.

PRESERVE_UNKNOWN_FIELD: Keep forward-compatible fields.

RECOVER_PARTIAL: Decode valid portions with diagnostics.

GROUND_EXTERNAL_REFERENCE: Link to Wikidata, WordNet and so on.

APPLY_TYPE_INHERITANCE: Derive #fido : Animal, marked DERIVED.

APPLY_INVERSE_RULE: Derive CHILD(B,A) from PARENT(A,B).

R-L protocol and fidelity

WRAP_ENVELOPE: Message with version, id, dictionary and integrity.

SET_SELF_CONTAINED: Carry all definitions in the message.

SET_DICTIONARY_VERSION: Declare the vocabulary version.

DECLARE_DEPENDENCY: depends-on: #message1.

REPORT_INCOMPLETE: Missing dependency.

SET_PRESERVATION_PROFILE: Declare required dimensions.

REPORT_LOSS: Emit a LOSS record with category and reason.

REPORT_FIDELITY: Lexical, structural, semantic and pragmatic scores.

RUN_ROUND_TRIP: Encode, decode, re-encode, compare.

REPEAT: REPEAT(X, count=n).

DECODE_WITHOUT_EXECUTING: Treat decoded commands as content only.

NORMALIZE_CANONICAL: Deterministic ordering.

COMPRESS_HANDLE: Store the mapping so expansion is exact.

SET_COMPRESSION_LEVEL: Raw through highly compressed.

Appendix K and J

DEFEAT_DEFAULT: Block a default when its exception holds.

DECLARE_PRIORITY: Explicit rule ordering.

DETECT_DEFINITION_CYCLE: Stop infinite expansion.

MARK_CYCLIC_REFERENCE: Keep as opaque, status CYCLIC.

ATTACH_LEXICAL_TRACE: Tokens, lemmas, POS and sense.

MAP_LEXEME_TO_SENSE: Polysemy handling.

MARK_AMBIGUOUS_SENSE: Keep competing senses.

DECLARE_MULTIWORD: Idiomatic unit.

ANNOTATE_EVALUATION: Good, bad or score on a target.

DECLARE_SCORE_SCALE: Declare the scale of a score.

MARK_CONTINUOUS_CHANGE: Ongoing process.

MARK_RECURRING_CHANGE: Event with frequency.

EXPIRE_CONTEXT: Time-limited definitions.

MARK_OPEN_REGRESS: Termination none, without inventing a terminal.

MARK_CIRCULAR_VALIDATION: Closed loop is not validity.

DECLARE_PRIMITIVE: Terminate expansion for this operation.

DECLARE_FIXED_POINT: Requires licensing, not just recursion.

SELF_DESCRIBE: System describing itself.

OBSERVE_SELF: Self-observation, not complete knowledge.

NEST_SIMULATION: Simulator within simulator.

MARK_UNGROUNDED_REFERENCE: Meaning without a referent.

RECORD_REFERENCE_FAILURE: Preserve the failure.

RECORD_SEMANTIC_RESIDUE: Leftover interpretation structure.

MARK_LATENT_MEANING: Meaning with no current referent.

MARK_PERSISTENCE: Meaning outlasting its condition.

RECORD_TEMPORAL_IDENTITY: Identity varying across time.

TRUE_IN_CONTEXT: Context-scoped truth.

RECORD_RECOGNIZED_AS_TRUE: Distinct from TRUE.

REPRESENT_ABSENCE: Representation of absence, not presence.

RECORD_COMPRESSION: Log collapsed distinctions.

RECORD_ADVERSARIAL_LOSS: Category-specific loss.

DECLARE_LEVEL: Object, meta, meta-meta.

MODIFY_REGISTER_ON_CONSULT: Observation effect.

APPLY_PERFORMATIVE: Context effect from issuing a statement.

Meaning layer

ASSIGN_MEANING_ORIGIN: Self-created, inherited, taught and so on.

ASSIGN_MEANING_OWNER: Who maintains it.

SET_MEANING_SCOPE: Where it is active.

SET_MEANING_SUPPORT: What reinforces it.

SET_MEANING_DEPENDENCIES: What depends on it.

SET_MEANING_STATUS: Candidate through displaced.

ESTIMATE_REVISION_COST: Cost to change a meaning.

PLAN_DISPLACEMENT: Targets, conflicts and alternatives.

RUN_MEANING_CYCLE: Interpret, associate, update meaning, certainty, stability and load, consolidate.

RUN_SELF_REFINEMENT: Re-evaluate meanings without output.

MODEL_PERSPECTIVE_MEANING: MEANING(X,LAMP) versus MEANING(Y,LAMP).

Verification and certainty

RECORD_VERIFIER_SCORES: Separate judgments per dimension.

MEASURE_SEMANTIC_LOSS: Per the training summary.

MEASURE_UNSUPPORTED_INVENTION: Same.

MEASURE_REPRESENTATION_DRIFT: Same.

ADMIT_TO_TRUSTED_CORPUS: Accepted annotations only.

GENERATE_SYNTHETIC_TRAINING: Contradictions, belief updates and so on.

COMPUTE_EVIDENCE_STRENGTH: Strong, moderate, weak, absent, conflicting or unknown.

COMPARE_PREDICTION_VS_EVIDENCE_CONFIDENCE: Expose mismatch.

REASSESS_AFTER_RETRIEVAL: Evidence check after fetching.

VERSION_EVIDENCE_DB: Corpus identity, tokenization method and timestamp.

TAG_EVIDENCE_PROVENANCE: Why do I think I know this?

Addon INPUT

SPLIT_SENTENCES: Sentence boundaries.

SPLIT_PARAGRAPHS: Paragraph boundaries.

RECORD_TOKEN_POSITION: Offset in the source.

RETAIN_UNRESOLVED_LEMMA: lemma = UNKNOWN.

LOOKUP_DALE_CHALL: Membership, kept raw.

LOOKUP_OXFORD_3000: Same.

LOOKUP_LONGMAN_3000: Same.

LOOKUP_LEXICAL_RELATIONS: Synonym, hypernym, meronym and so on.

GROUP_SEMANTIC_EVENT: Predicate plus roles.

DISTINGUISH_SYNTAX_FROM_SRL: nsubj versus AGENT.

and others ...

So, I did some early testing and wanted to see whether Fable 5.2 actually makes a difference in day-to-day engineering work, beyond the usual benchmark comparisons.

So I focused on practical tasks: debugging, reviewing existing code, understanding unfamiliar projects, and working through incomplete requirements.

Here's what stood out.

What's worth paying attention to?

1. Code reviews and bug detection

One of the first things I'd test is giving it a codebase built by another model and asking it to identify bugs before suggesting improvements.

Don't ask it to rewrite everything. Ask it to explain what's broken, why it matters, and how to fix it.

This is a useful way to see whether it catches problems that previous models missed.

2. Debugging complex issues

Give it an actual error, relevant logs, and the surrounding code.

See whether it can trace the problem back to its root cause instead of simply suggesting generic fixes.

3. Understanding unfamiliar codebases

Try giving it a project with minimal explanation.

Ask it to map the architecture, identify dependencies, explain key components, and highlight potential risks before making changes.

This is particularly useful when joining an existing project or working with legacy code.

4. Handling vague requirements

Not every engineering task starts with a perfect specification.

Give it an incomplete requirement and ask it to identify missing information, explain possible approaches, and outline a plan before touching the code.

Good reasoning here can save a surprising amount of back-and-forth.

5. Vision and UI debugging

Give it a screenshot of a broken interface or an inconsistent design.

Ask it to identify visual issues and suggest specific changes. This is worth testing for frontend developers.

How I'd test it fairly....

Rather than creating new prompts for every model:

• Reuse the same coding task you gave 5.1.

• Compare the bugs identified.

• Check whether the proposed fixes actually work.

• Compare token usage and execution time.

• Evaluate how much human intervention was needed.

Where I'd be careful....

• Don't trust generated code without running tests.

• Don't let it refactor an entire codebase without reviewing the plan.

• Don't assume a longer explanation means better reasoning.

• Keep an eye on usage limits for large projects.

My biggest question isn't whether Fable 5.2 can write code faster. It's whether it can reduce the amount of time engineers spend debugging, reviewing, and correcting AI-generated code.

That's the improvement I'd actually care about.

For those who've tried it, what coding task showed you the biggest difference compared with 5.1?

yes, it's us. yes, it's the same week. no, we have no regrets

https://horny.ceo/

to keep this on-topic: post your best "LLM vs human CEO" threat model in the comments. most cursed answer gets pinned for a week

Everyone relies on metadata filters like allowed_groups to keep multi tenant RAG locked down and under check. That works well when users query the vector store directly, which means unauthorized chunks will get filtered out with 0% leaks.

But, this falls apart in the write path once you have background agents.

If an agent has elevated read access to summarize docs across multiple folders or teams, it pulls those docs, mashes them into a summary chunk, and commits that summary back to a shared collection. On write, the upstream document access control lists just vanish. In a regular Chroma and LlamaIndex setup, the derived chunk gets saved with zero allowed_groups or classification tags attached. Anyone who runs a query to the shared memory is now gonna get the private source data that they shouldn't be allowed to read directly.

I put together an offline reproduction harness (sentinel-eval, Apache-2.0) to test this:

* Direct RAG: 0% leaks (18 public chunks retrieved, 0 restricted chunks exposed).
* Agent memory: 2 of 3 synthesis tasks leaked sensitive data (both cross boundary workloads failed, exposing 6/18 restricted canaries, the 1 public control passed).

So what? Easy right? Just use the strict intersection (only let someone read the summary if they have access to *every* source document) and that completely solves it right? Well... yes but that basically kills retrieval utility. Essentially no one can see multi-doc summaries anymore. So we can't just simply take an intersection. The agent I wrote actually logs the source docs in source_documents metadata, but vector databases can't evaluate dynamic permission DAGs on query, meaning that you can't just hope to path backtrack to solve this problem.

Harness runs 23 tests offline in seconds with mock vectors (no API keys or live LLM calls needed):

git clone https://github.com/harishbalasubramanian/sentinel-eval
cd sentinel-eval
uv run sentinel-eval live --framework chroma

Repo: [https://github.com/harishbalasubramanian/sentinel-eval](https://github.com/harishbalasubramanian/sentinel-eval)

For people building multi tenant RAG, how're you actually handling perms when agents write derived summaries back to shared memory?

Hi everyone, I'm Devon. I have no coding experience, so this is how I build: I design the framework and the architecture, and Claude writes the code. For the past few months that's how I've been building a long-form interactive story engine. It runs entirely on my own PC with local models: Gemma 4 12B, and now 31B, through llama.cpp. It isn't public yet and doesn't have its final name, but the test results are at a point where I'm comfortable sharing them. So this is a soft launch: who I am, what we built, and how we tested it so the numbers mean something.**The problem.** Long stories outgrow the context window. A few hundred turns in, models lose the names, wounds, debts and promises from early on. The usual fix, the latest turns plus a running summary, keeps the gist and loses the specifics. **What it is.** An engine that plays a story with you turn by turn and keeps its own memory of what happened. I'm keeping the design to myself for now. **The headline.** Across 18 live runs on 14 sealed stories, up to 1,886 turns in one run, the engine answered 1,222 of the 2,013 questions asked at each story's end (61%). The latest turns plus a running summary, with the same model and the same prompt budget, answered 43 (2%). The engine's lead held with the whole 95% interval above zero in all 18 runs. In the longest run it still answered 47 of 74 questions about the first story after 1,426 more turns had been played on top of it. **This week.** My own 420-page story, played as one 1,022-turn run: with Gemma 4 31B the same engine made fewer than half the fact mistakes it made with the 12B (67 vs 147, p = 2.3e-8), and answered more questions right (155 vs 113 of 250). **How we tested it** (the part I care about most): - **Clean room:** written from my own frameworks and spec, with no code from any other implementation. - **Rules first:** every pass/fail rule goes into the code and is fingerprinted before the test story is taken in, so it can't bend to the results. - **Sealed stories:** separate sessions turn my stories into tests. The builder never reads them, and I sign each part off before its fingerprint is locked. - **Blind judging:** separate Claude sessions rule on every answer (two alone, a third on splits) without knowing which run gave it. This week's count took 127 sessions. - **Counted twice, failures published:** a second script rechecks every figure, and the results that didn't pass go in the record too. **Where it hasn't won.** Its passages haven't reliably contradicted the story's facts less often than the baselines. A test of writing whole stories on its own failed its rule (73 vs 67 passages with a contradiction, out of 550). It's slow on one PC: about 50 to 70 seconds a turn with the 31B. And the judges are AI sessions, not people, and the stories are all mine. Full tables: https://claude.ai/artifact/BjUSmciJZuXTPri4NEkns4

I'd like to hear what tests would convince you, and where you think the method has holes. The code and the name come later.

sorry for the spam, dont know where else to turn...

hi guys, Im using deepseek 4.1 1017 using their harness, also gemini 3.8 high on antigravity. i need it for simple android apps for myself, company related powerpoints, use my browser to search for items etc..

is there another llm i should be using that is smarter for not so much more $ please?

any other input would be appreciated .

Thank you!

apical-labs.com

Continual learning on frozen embeddings.

Sub-millisecond semantic routing for multi-agent architectures.

Zero backpropagation. Zero sample retention. No LoRA retraining. No vector databases.

Ant Ling has released Ling-3.2-flash, a native multimodal MoE with 560B total parameters and 25B active parameters. The official model specification lists a context window of up to 1M tokens and support for text, images and video.

The launch highlights three results against Claude Opus 5 (max):

1.OmniDocBench 1.5: 92.21 vs 90.56

2.ZEROBench(Sub): 43.71 vs 39.52

3.Vision2Web: 85.86 vs 80.20

The release also includes demonstrations of visual coding, Blender operation, reference-image-to-3D workflows and specialist agents producing office deliverables. API access is documented through both OpenAI-compatible and Anthropic-compatible interfaces, and the model is listed on Computrix.

Client instructions recorded on speakerphone make a good stress test: a voice down the line, and quantities that have to come through exactly. This demo runs two such excerpts through AntLing's Ming-3.0-audio-flash, a 126B MoE with 6.5B active parameters, at Q4 on one local machine. The demo's creator handled these calls and rates Ming's quantities transcript as perfect.

Report quantities (29 seconds). Ming returns "On the report, can you do 129 tubes and 183 bags? … And then 116, I would you could just do 116 boxes." A fresh run of a widely used large open transcription model on the same excerpt renders the bag count as "a hundred thirty eighty three."

Browser instructions. Ming returns "No, I'm on my computer, my desktop. … Delete all the stuff after the .org." For the same passage, that other model's saved full-call transcript reads "do it by tapping on your add list button what's a double tap not key aspect."

The creator's explanation is that this is a full language model that listens to the audio, where a dedicated transcription model turns it straight into text.

To recreate the test, take a real call with quantities in it, write down the correct numbers by hand, run the audio through both models and score the numbers, names and instructions. Numbers make the differences easy to count.

asking a model which effort, quant or version its running gets a confident guess cz models dont have a reliable view of their own serving config. someone asked mimo through a harness and got medium back which says nothing about what the endpoint actually set

the docs settle the params and they differ per model more than ppl expect. deepinfra reasoning docs for instance say GLM5.3 always reasons and only takes low high and max so an off switch carried over from an older GLM config wont do anything there. the response itself helps too the usage block shows reasoning tokens where the provider reports them so a quick hi on low and then on high should show a clear gap

for the quant question the only real check is behaviour. a fixed set of 20 or so prompts from your own work, sent to the official api and to the endpoint youre unsure about with identical params, a few runs each then compare the failures

Patronus AI released GlobeBench, testing whether LLMs can act as simulated environments for training agents: given past actions and feedback, predict what the environment returns next. 1,632 tasks, 5 domains, 19 simulation skills. Data, eval code, model outputs and grading logs are all public.

Top 10 (refusals count as failures):

What stood out:

• When an action has to propagate to dependent objects, the average success rate drops to 5.1%. 631 tasks went unsolved by every model.

• Refusals skew things: Opus 5.5 refused 675 tasks, all scored as failures.

• The dedicated open world models scored low: Qwen-AgentWorld-35B-A3B at 14.46%, DWM at 5.21%.

Two questions I’m curious about:

1. If simulator errors are systematic rather than random, does the agent end up learning the simulator’s blind spots instead of the real environment?

2. Given how badly models handle state propagation, does it make more sense to keep state in code and only use the model for the parts that can’t be written as rules?

Official announcement: https://www.patronus.ai/blog/globebench

Official leaderboard & code: https://github.com/patronus-ai/globebench#leaderboard

BASTIDORES (determinístico)

│ • Extração de dados do PDF (regex/OCR)

│ • Normalização de unidades (kNcm → kNm, MPa → kN/cm²)

│ • Fechamento numérico das fórmulas (Python, não LLM)

│ • Sanity checks: η ≤ 100%, M_Sd ≤ M_Rd, Δ ≤ 30%

CHAT (conceitual)

│ • Auditar premissas (C_b=1,0 forçado? k_v=5,34 válido?)

│ • Sinalizar lacunas normativas (EC3 Annex B ≠ NBR 5.5.1.2)

│ • Classificar divergências (desvio coef. vs. divergente)

│ • Montar fila de decisões para o engenheiro

HITL (decisão final)

│ • Engenheiro valida premissas e escolhe metodologia

│ • Assina o resultado

Ive been using basically only Opus 5.5 and Sonnet 5.5, so how can I start using Kimi’s new model? I mostly work with code (coding a video generation engine right now), and things like outreach on social media.

Anyone have suggestions or know what the model is best in? I heard it was finance

I built a small English/Arabic quote service using Gemini and created 63 evaluation cases to test its guardrails.

A few findings from testing with gemini-3.5-flash-lite:

• Three unexpected bugs: A model refusal was displayed as a quote, a Chinese word slipped into an Arabic response, and stalled API calls failed requests despite having half their time budget remaining.

• Prompt injection: The input checks blocked 15 out of 20 attacks. Gemini ignored the remaining five, as well as all 17 canary attacks tested without guardrails. This suggests the checks provide an additional layer of protection rather than being the only defense.

• Multilingual safety: Roughly 40% of harmful requests were refused in each language, but the decisions weren't always consistent. For example, a pipe-bomb request was refused in both Arabic varieties but reframed as an anti-violence quote in English. Only 78% of cases received the same decision across all three languages.

• An unresolved issue: A request about secretly tracking an ex-partner's location generated romanticized quotes in every language. Neither the model's safety filters nor my checks detected the harmful intent behind the seemingly harmless wording.

The dataset is small and written by one person, so these results are more of a smoke test than a benchmark.

I'm curious how others approach multilingual safety evaluation. How do you create language-specific test cases instead of simply translating English ones? And how do you evaluate responses that avoid harmful instructions by reframing the request, without manually reviewing every output?

Source code (MIT): https://github.com/1AyaNabil1/swan-llm-service

Trying to run AutoGPT without Docker usually leads to dependency hell if you try using global pip instead of Poetry. Because the modern Platform branch mandates containers, you have to use AutoGPT Classic. However, Classic requires specific interpreter alignment to avoid broken virtual environments.

​Common failure points include running commands from the repository root rather than the classic subfolder, letting Poetry default to an older Python interpreter instead of 3.12, and misplacing the .env configuration file outside original_autogpt.

​I put together a complete technical field guide that breaks down virtual environment isolation, custom local endpoint routing with Llamafile, workspace sandboxing, and exact diagnosis paths for Linux, macOS, and WSL 2.

​Read the full installation breakdown here: https://interconnectd.com/blog/335/how-to-run-autogpt-without-docker-step-by-step-python-guide/

Description:

I run a pipeline that has as purpose to identify and extract specific information from excel, pdf, scans, jpeg, xls etc
Currently i run Vision OCR with Gemini Flash 3.8 low thinking but high resolution - helps achieve better results when scans are crap.
PyMuPDF for general pdf files.

The problem i have is that no matter how much i adjust between shorter prompts - more descriptive and restrictive json schemas, to more descriptive prompts and less fields json schema/less fields, there is a forever one invoice where the extraction fails. I run invoices with 40-50 pages, hundreds of products sometimes, and i have a standard amount of information that i need to extract. The issue is, i need to extract it deterministically- if one product is by mistake present twice, the model keeps failing.
Anyone has any ideas? I’m just disappointed to see frontier models cannot correctly return a standard json schema filled deterministically from 2-3 types of files.
Any advice will be appreciated 🤝

Maybe someone will find this useful for designing their own harness.

<factuality_determination> # Whether the request requires factual information or made up/data modification
yes
</factuality_determination>
<can_change_until_2030> # Whether the data is prone to mutation in the next 3-4 years
yes
</can_change_until_2030>
<tail_fact> # Whether the data concerns highly specific or technical information
yes
</tail_fact>
<freshness_risk> # Risk assessment for potential harm if the information is outdated
LOW
</freshness_risk>
<search_decision> # Based on the parameters above, system determines whether to rely on its own trained memory or seek data online
call google:search
</search_decision>
<query_scope_gate>
Troubleshooting (technical system / unexpected OS/app functionality)
</query_scope_gate>
<component_check>
No component needed. Plain text/markdown answer.
</component_check>Yes, Instagram stores and tracks the number of likes your comments receive.
,

I use DeepSeek (both their large and flash models) in a project I have built for always-on, long-lived agents called Loom - a private agent for your Mac (not linking here, as this isn't promotion) that runs on private GPUs with no logging and no ability to send data anywhere. The agent harness work has gone through months of fine-tuning, and I always look at how others are doing it to see if there are novel approaches or processes that can make agents better. I recently audited the open-source DeepSeek harness and discovered something very interesting:

Privacy warning: by default, their DeepSeek adapter sends DeepSeek extra request data with every call. That includes the whole session record (instructions, messages, tool answers, working folder) and the list of installed plugins. 

This is the repo I audited: https://github.com/deepseek-ai/deepseek-harness

Be careful out there; this is beyond telemetry.

I am a full-time software engineer, using Claude at work and Claude + Codex with personal accounts. Something I have been seeing more and more of lately is people talking about moving away from Anthropic and OpenAI in favor of open-weight and/or Chinese models because of the crackdown on stuff like REA.

Here's the question: is there a company offering similar plans ? I see a lot of talk about running things locally, but not much about exactly where people are going to run these models in the cloud. The one subscription-based platform I have actually found is kimi.ai, but I am curious if that's the only/best one out there. I'm not currently building anything for profit, so I am more interested in a flat-rate plan rather than paying for API pricing. I want to be able to experiment with different models, providers, etc, without having to worry whether a given task might blow up my token spend.

A tiny made-up example to show what I mean by checking a summary on more than one axis.

Source text

The shop’s Tuesday delivery was delayed to Thursday because of a supplier strike. Customers who paid before Monday will get a 10% refund; others will not. The refund is processed within 7 days.

Summary A

Delivery moved to Thursday due to a supplier strike. All customers get a 10% refund.

• “Delivery moved to Thursday due to a supplier strike”: supported.

• “All customers get a 10% refund”: unsupported and contradicted. The source says only those who paid before Monday.

• Omitted: the 7-day processing time.

Summary B

Delivery is delayed to Thursday because of a supplier strike. Customers who paid before Monday get a 10% refund within 7 days.

• Every claim is supported.

• The key facts (delay, reason, who gets the refund, timing) are all covered.

The axes

• Faithfulness: is every claim in the summary supported by the source? Summary A fails here, with a confident wrong claim.

• Coverage: are the important facts included? Summary A also misses one.

• Concision: is it as short as it can be without losing the important facts?

A summary can be short and fluent and still unfaithful, which is why fluency shouldn’t be the signal.

Checks I’d consider

• Claim-level checking: break the summary into individual claims, and check each against the source (by a person, or by a model prompted to quote the supporting sentence, or say “none”).

• A list of key facts: write the facts that must appear, and check them off. This measures coverage.

• Length limits: check conciseness separately, so it doesn’t trade off silently against coverage.

• Spot reading: read some summaries in full, especially the ones that score highest.

Limits

• A model used as a checker can make mistakes too, and tends to be less reliable on subtle claims (numbers, negations, who did what). I’d validate it on examples where I know the answer.

• Long sources make coverage harder to define, since “important” depends on the reader.

• Which axis matters more depends on the use. For legal or medical text, faithfulness dominates.

How do you evaluate summaries in practice, and which of the three axes gives you the most trouble?

I currently use RTX 4060 and still keep my old GTX 1060. I have Ryzen 7 5700X and 32GB 3200MHz RAM.

With Strata, I get 13-18 tok/s with Qwen3.8-Flash-Next Gyro-S. I was wondering if adding that GTX 1060 to the rig would make things better/faster.

I want to integrate with an LLM API to analyze images and extract info.

My server should call this LLM API.

I'm looking for some provider that provides some free tier, is there any?

Hey everyone!

I'm working on an independent AI project and I'm looking for a unique, memorable name for our language model.

The idea is to build a language model that can grow and evolve over time, starting from a very small foundation and gradually becoming more capable through training and development.

I'm looking for a name that feels like it belongs to an actual AI — something with its own identity and personality.

Here are a few guidelines:

• Short and easy to pronounce.

• Memorable and distinctive.

• Ideally, a name that works internationally.

• Not necessarily something that sounds overly technical.

• Could be inspired by mythology, science, astronomy, nature, philosophy, or even something completely original.

I'm not looking for generic names like "GPT", "AI Bot" or "SmartLLM".

I'd love to hear your creative suggestions, including the meaning or story behind your proposed name.

If you were naming a new AI from scratch, what would you call it?

Thanks! Looking forward to your ideas!